But also, that kind of power needs a degree of restraint. You can do those things, but that means that it's on your team to prevent that one bored dev or that one guy who's just joined from a company who did things a different way from their instictive needs to add in new frameworks without a damn good reason.
Both are reasonable answers. It makes people happy to work on their 3-D printers. They love tinkering with them, like printing new braces, holders, parts, etc. The love tuning them. They love finding the perfect filament storage system. That's the hobby. The 3-D printer itself.
I was buying a 3-D printer to make parts. When I realized that I didn't want another hobby, a whole bunch of printer options fell off the table. I wound up choosing a printer that would pretty much work acceptably, once assembled. I have printed stuff with the printer, but I guessed right. At no time do I ever look at the printer as anything more than a tool to get something else done.
From my perspective, it feels like a lot of the JavaScript community falls into the former category. Their JavaScript environment is beautifully incomplete. It must be perfected. They tinker with the works to get the perfect packaging and build process. Bits and parts are changed out, re-worked, or re-written. I think the fact the language invites edge-cases also gives plenty of fodder for new ideas.
I'm a tool user, and that's what I liked about straight-up rails. It did a good job, was faster to develop on than enterprise Java, and the end-product was understandable. Rails and Ruby weren't my projects. The application I was working on was my project.
But the idea of a 3D printer is totally different. It's for people who need to learn just enough about 3D printers in order to use them to do other things. The idealized owner of a printer does not care how printers work besides picking one that's suitable for a job. If you spend a lot of time thinking about the design of your printer, something's wrong. A framework should, for most regular work, be as much like a printer as possible.
There's a reason it didn't really get the popularity the other frameworks got.
Basically, if Ember.js used abstractions that were better for, say, extremely complex applications, it was dead in the water, because most applications make their library decisions when they are small and relatively straightforward. The market for javascript top-to-bottom rewrites of extremely complex apps (where something with those more complicated abstractions shine) wasn't really large enough for it to become dominant.
I also found it difficult to reason with, even though I'm an experienced Rails developer used to spooky action at a distance in the framework. Something about troubleshooting on the frontend really made it more difficult.
Circa 2010 those people who were so successful with Ruby had come to the conclusion that they couldn't sell RoR apps anymore so instead they were struggling with Angular -- not to do anything they couldn't with do Rails but rather they though customers demanded applications that looked like Angular applications.
React was a big hit because it was an "Angular" which people could actually deliver working applications with. Its strength I think it is that it addressed certain concerns but left other ones unaddressed such as the theory of async comm. If there is a simple mapping between the state of the application and the state that is represented in the React tree life is great but I look back at the applications I was writing in 2006 and it still looks like a regression.
What I like about it is that I can draw absolutely anything I can imagine with it, even 3-d virtual worlds
Vue has a model which is closer to my mental model of web forms with first-class lists but I can see how to get into "you can't get here from there" situations.
I see the problem React solving is "how to compose an application out of components" and compared to WPF, JavaFX, and such, it's dramatically simpler, it's like a missing chapter out of Graham's On Lisp
Edit: and yes, as you said, it came from Facebook, so it wasn't just a solo developer's grad project; it had a large amount of support right out of the gate.
I am not a UI developer and just needed to understand/debug something, it was not easy at all.
Seems like wycats is interested renewing his Ember work as of late.
I recall evaluating Ember right around the time they switched from their last pretelease of I think 1.0 and suddenly all the documentation was either gone or out of date and not applicable. I ended up going with AngularJS (1.23 maybe?) and didn't look back until I went to work somewhere that used ember exclusively. It was far less pleasant to use than anything else I had been using up to that point except maybe Backbone.
There's been a few additions to the JS core APIs like webgpu and a few others, but all of them have been extremely niche. There's not much that's been added since 2016 or so that you couldn't pick up in a heartbeat, so it really boils down to the frameworks themselves. Ember lost to AngularJS, then Angular and React.
React could be introduced only where it was needed, but Emberjs really wanted to be everywhere and in control of everything.
Compare this to the Ruby ecosystem, where every framework (including Rails) uses Rack, which means that all the frameworks compose together, if that's how you'd like to modularize your monolith. Or the other ecosystem known for its preference for libraries over frameworks, Go, where everything is standardized around http.Handler, so whatever you pick is basically guaranteed to compose.
And it's not just the lack of good overall frameworks, it's the general lack of good defaults for libraries in Node-land. Among the most popular ORMs/query builders over the years there are some surprising omissions, with Knex not supporting connection pinning or Prism not doing database joins by default for a long time.
Everyone who works with the web is forced to use it, each coming in with their own opinions of how things should be done.. thus we have the fragmentation
Ruby grew in a large part due to Rails, so everyone that's in—and stayed in—that community has been self selected to share similar ideas of how to build web apps
The problems people solve with JS are different from the ones solved with Rails. Which is why the frameworks look different.
But it doesn’t. Rails is not just a full-stack framework. It’s the entire ecosystem of gems that magically just work together. What JS has is like the Temu version of Rails.
And it’s not like I’m not familiar with JS/Node, it’s the ecosystem I’ve spent the most time over the last 15 years. I’ve just seen so much wasted engineering effort in that time. Not sure what the exact multiplier is, but gut feeling says you’d typically need at least 2x the amount of engineers when using Node over Rails.
> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day.
https://github.blog/engineering/building-github-with-ruby-an...
this is a common problem in any complex codebase that has a culture of using third party dependencies to solve small problems. you see this conversation all the time with modern frontend development and the resulting dependency tree you get with npm etc....
... even ten years ago, it felt pretty dated. Has Rails grown some framework-supported tooling for web apps yet, or is that the utility we're talking about?
> Then again reinventing wheels is the JS way of life.
There's some truth to this. The underlying notion is "how much computation do you do server-side vs. client-side," and because browsers don't run every possible language, the shortest path to client-side behavior is in JS. So there's a lot of wheel-reinvention in that sense.
(I do see the notion of writing the code once to run in either context wax and wane. boardgame.io is a JavaScript framework for writing turn-based stateful games; it uses a specific authorship pattern to run the core behavior library both server and client-side, so clients can responsively predict what will happen while the server steps through the rules and updates the game state).
Rails is amazing compared to NextJS or Express + React for me. Getting a lot more done. Writing a lot less code. The Rails ecosystem is great for doing a SaaS + modern content site/app.
I was away from Rails with full stack JS since before the pandemic.
I don’t think that much has changed with Rails since like Rails 4 or 5.
Maybe this is a recency bias, but for my own work or any work where I can dictate or influence the tech stack of a modern web app, I’m sticking with Rails/Laravel and React or Svelte when modern frontend/views are needed.
I don’t think Rails or Laravel should even focus on views that much any more in Ruby/PHP.
I get the best of all worlds now and I don’t hate JS any more. In fact I have sort of fallen in love with React as well now that it is only doing what it should do and I want to learn Svelte.