41–50 of 288 posts
Earlier quoted context omitted.
Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework. There's a reason it didn't really get the popularity the other frameworks got.
What was the reason?
I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.
Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework. There's a reason it didn't really get the popularity the other frameworks got.
I think there is a much-better-than-merely-non-zero chance that the rise of coding agents will also mean a rails renaissance. All of the complexity identified in the article really gets in the way of LLMs.
I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.
Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework. There's a reason it didn't really get the popularity the other frameworks got.
Seems like wycats is interested renewing his Ember work as of late.
Am I the only one who still thinks any kind of build process does not belong in web development? If I'm making a typical website, all I'm using is a few PHP files, a single CSS file and maybe some JavaScript. There are no build steps. No minification. No compilation. No frameworks. I just can't understand even using Rails for web dev.
I've been writing Rails code since 2007. There's a reason the stack has gotten more complicated with time, and virtually no team has ever done it right by this definition. The trouble with an omakase framework is not just that you have to agree to the initial set of choices but that you have to agree with every subsequent choice that's made, and you have to pull your entire dev team along for the ride. It's a very po…
If this is what you remember, then you remember a very broken setup. Even an “ancient” Capistrano deployment system is better than that.
Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again. In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).
Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend separation introduces. I learned this the hard way through years of over-architecting 1-2 person projects as a freelancer. Nowadays, it's just Django with a little bit of Tailwind on top.
In most industries, your clients won't care if the software relies on an ultra scalable architecture split in microservices or a monolith + PostgreSQL.
I've been writing Rails code since 2007. There's a reason the stack has gotten more complicated with time, and virtually no team has ever done it right by this definition. The trouble with an omakase framework is not just that you have to agree to the initial set of choices but that you have to agree with every subsequent choice that's made, and you have to pull your entire dev team along for the ride. It's a very po…
Could you elaborate? Doesn't sound like a big deal.
The whole "web dev tooling fatigue" is so real.
It was real over a decade ago. This is sheer stupidity and selfishness of bringing hobbies into their jobs. If it makes Front-End devs feel better, the "DevOps" world isn't much better.