Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Totally agree.

We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack.

It's rock-solid, performant, dead-simple and extremely productive to work with.

Why're we throwing away years of learning to build unstable, complex and inaccessible applications?



>Why're we throwing away years of learning to build unstable, complex and inaccessible applications?

1. Smart people seek out difficult problems.

2. Difficult problems drive the creation of complex, niche tools, that bear cultural associations with the smart people who made and use them.

3. People who want to be smart seek out complex, niche tools.


I think you're somewhat right, but it's not the whole story. There's another pipeline that goes something like:

1. Technical software problems are more fun than difficult product problems

2. Programmers would rather solve fun problems

3. Programmers end up creating technically elaborate machines to solve simple (buy annoying) product problems


As an ex-member of a team who used react, redux, typescript, observables, epics, thunks, custom hoome-grown validation libraries, websockets and elixir deployed in two different microservices to build a... signup wizard... I can confirm this.

I proposed to build it in Rails (which we already had, but was the "old monolith we're migrating away from") and I almost get crucified.


That's a story I'm familiar with, but I am not actually aware of any (major, commonly used) tools that were created out of boredom. I only see instances of people using existing tools when they are not necessary out of boredom.


I think it might be simpler?

The more complex products are the only ones that typically have any documentation or up to date learning resources.

You want to learn how to build a thing and this is the only thing that really exists, is up to date, and works.

It may not be the right tool, but for someone new it's impossible to tell what the right tool is and people online are stereotypically obtuse and about anything tool related.


lmao yeah pretty much. I'm moving from a low code shop to Node/Vue because I can't keep people. They all want to pad their resume, so I'm going to build at 2x the cost just so I can keep the projects going.


The level of Node/Vue isn't padding your resume in this industry, it's having a resume. Padding your resume would be... I don't know, Elm?


Smart and YOUNG, seek and try to conquer complexity, pushing open The Gate of Truth. Only to be completely consumed and burned by it.

There are abundance of smart people. Wisdom, has and possibly always will be in short supply.


> Smart and YOUNG

I'm 21 :-)


> > Smart and YOUNG

> I'm 21 :-)

No problem, you'll be young in a few years.


I think this is a midwit[0] take.

Low: simple good

Mid: optimized good

High: simple good

0: https://knowyourmeme.com/memes/iq-bell-curve-midwit


Same experience here, in our case with Laravel. The project started as a Next.js SPA and after we needed to add authentication, translations and background jobs things became so crazy and so "custom" that we ditched it and in almost 2 weeks had everything built in a much more robust way with Laravel and Livewire + Alpine.


Because the majority of developers will gravitate towards tools that will give them the best employment opportunity, not necessarily the best tools for the job.

TL;DR Resume Driven Development


What approach did you take with real-time collaboration and interactivity? Is that part still rendered client-side?


One could argue rails is just doing a decent job of hiding a monstrous amount of unnecessary complexity from you for basic CRUD stuff. It’s good at this… until it isn’t. In the the whole ORM abstraction (not just in rails) is questionable.

The way most of us would handle authorization in something like rails is a leaky abstraction, especially when we’re usually backing onto postgresql which has very mature roles and permissions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: