I keep thinking the same thing almost every day at work… “this is a CRUD app, who let it become this overly complex monster (multiple next apps)”. Then I remember why;

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

― Edsger Wybe Dijkstra

I worked with Rails and prefer this. Rails is more complex it's just easier to use but harder to understand with all that dynamic magic.

This quote really made my day and embodies my approach to software engineering. Thanks for this.

Eh. Perhaps you're looking through rose colored glasses on the days of Rails dominance? I've worked at multiple companies using Rails and not one was simple. Especially when you have 100+ engineers working on different aspects of a massive product. Anecdotal but Rails has a ton of magic to make things work but its only simple if you're product is a super basic CRUD app

I don't think 100s of engineers working on a massive next.js application would be any easier. At scale everything is complex.

Of course. I didn't say Next.js solves the complexity of building a massive product, no framework will prevent complexity at scale. That's my point since this thread seems to put Rails on a pedestal like it was the main thing making products built with Rails simpler compared to other frameworks in other languages when in reality, the product requirements are most likely pretty simple

No downvote - it definitely is crazy complex, or at least intimidating for anyone from the 'before times' of Rails (myself included). Everything is taken over by engineers and so is now over-engineered and feels totally geared towards developers developers developers and a weird obsession with performance.

And all the new features including server side rendering give me whiplash

Over-engineering is not exclusive to the JS world. It's just in the spotlight nowadays. Rails also just hides its magic well because of Ruby and most experienced devs are already used to the Rails magic so its simpler compared to the new stuff like Next.js.

I understand your point, but having worked with Rails and now working on a React + Flask app, Next.js is the closest thing to Rails we have so far.

And, having worked on a Rails + React app a few years back, I can safely say that is about as complext as a Next.js full-stack app.

I do love Rails and I still think the React + Something on Backend environment is still not there yet (at least not like Rails 4 and 5, which were the ones I used), but Next.js is getting there.

When you factor stuff like Redwook.js and possible Remix.js when it gets open-sourced, for me it gets pretty clear that the trend now is to try to make the Rails of the JS world.

And I would love that. Honestly, people complain about Node and JS, but working in Python/Flask can be just as frustrating. Issue for me is more lack of conventions than language.

I was looking for a mention of Redwood JS - I assume your post has a typo in it.

It's not 1.0 yet but from what I have played with it's the backend (PostgreSQL with Prisma, graphql, services) + frontend (react with data retrieval components (Cells)). That sounds buzz wordy but in practice it works nicely.

But why do we need a new rails? That's what I don't get. Just because we want to use JavaScript?

Simply because Rails is not designed to solve frontend problem where complex user interactions and client side state are included, not to mention partial rendering and transition. Rails is a backend framework after all, spitting a HTML is all it can do in terms of a frontend part. Just don’t know why you think you can solve all the modern frontend user interaction with a backend framework like rails and Django,,,,,,,,,,,,,,

Github, Hey, and so many others are examples of Rails applications with complex interactions. Server templates and partials rendering doesn't mean "I reload the page on every click and can't write any javascript because I only do ruby". You have tools for doing dynamic html too, just not your usual redux/rxjs/thunk/observable/typesafeactions stuff.

Agree that Django is a backend framework, but Rails is not, you can certainly do frontend in Rails. Just not SPAs, but you need a more open mindset for understanding how it is intended to be used.

Of course, if you are building Google Docs or Maps then you're probably better with a SPA framework. But not for 90% of applications out there which are just CRUD apps.

Because React is now a standard in the frontend I guess, so people are looking for a way to get that Django/Rails fullstack experience but with React instead of templating language and because it's extra work to write a django/node/rails api and a decoupled JS framework frontend.

Meanwhile everyone is also trying to have a decoupled infrastructure and going with microservices. It's an endless loop I guess.

No I had the exact same thought. Are we just re-inventing simple server side templating but with incredible new levels of complexity and obfuscation?

Because in 21st century, not everyone likes a website with a lower-bar rendering experience… SPA or hybrid rendering is just plain better, but I get the point where time is limited for human being, so if modern frontend is hard to grasp for you, perfectly to stick with old tech. Pretty safe.

> SPA or hybrid rendering is just plain better,

It is not for your end users, just for the developers building it because it has a better dev experience. As a proof of this try most sites out there which are built as an SPA vs the ones built with more traditional approaches.

Also, building SPAs is incredibly more difficult and time consuming, that's why most of them work like shit.

I'm so done with CRUD work, it sucked the soul out of me