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.
I really appreciate the power of JS's openness to writing entire new platforms. It's a great thing that everybody gets a chance to reinvent the wheels. It's great that many of these platforms actually just all more or less work if you use several of them at once. So extensible! So hackable! And you can host the entirety of them locally, so your whole site can be built in a permanently unchanging way? Wonderful!
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.
When I bought a 3-D printer years ago, I had an important insight. I was either buying a printer as a project, or I was buying a printer to help with other projects.
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.
Yep, 100%, that's a great example. I have a friend who LOVES tinkering with his 3-D printer. He built a CoreXY from scratch to his own spec, he hacks about in the firmware, he experiments with new slicing algorithms, but to my knowledge he's never actually printed a 3D part for any purpose except calibration and for making 3D printers. The printer is the hobby. Its ability to make stuff is both entirely the point and also entirely unimportant.
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.
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 wonder how much of that is "The JS universe just moves too damn quickly!" vs "Nobody wants Ember".
Seems like wycats is interested renewing his Ember work as of late.
The JS universe moved quickly for about two years. The most popular frameworks at this point have been around since that time, with a few oddball upstarts. They've undergone some big changes, but are at the core the same concepts.
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.
My reasoning for not using ember was it’s steep learning curve and easier libs(angular 1, backbone, react) to work with at the time(~2012 to 2014). Honestly, react wasn’t very big during this period, it was Angular that truly dominated.
What was the reason?
I’d guess that it’s because React came around and it was from Facebook so it got a lot of adoption? Maybe there’s some other reason, the comment you responded to seems to imply something anyway
The way I remember it around 2006 there were a few up and coming web development shops in my town that had their practice centered around Rails. That last half of the decade I was working on advanced RIAs like knowledge graph editors and decision support tools using systems like GWT and Silverlight that were not Javascript but had the same async comm challenges.
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
https://aframe.io/
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
I wasn't deeply involved in the Ember.js ecosystem as a user or maintainer, but the impression I got was that, for frontend purposes, clearer abstractions and simpler code was much more critical than "batteries included" frameworks like Rails.
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.
Javascript ajax was getting out of hand. Everyone wanted SPAs but managing the state of each button was becoming extremely unwieldy. Thousands of jQuery/js lines, the submit button wouldn't toggle to enabled once disabled...stuff like that. React came along and had prop state per element on a page (as they rebranded it, components), which helped immensely in this department.
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.
IMO it's that frontend wasn't really a separate discipline at the time. Ember came out of Sproutcore, which was a framework created by some Apple MobileMe developers. They were building something that was very much an application development framework for single page apps before the term 'SPA' even existed. And I think people doing front end just weren't ready for that level of complexity yet. Most web developers were self taught and didn't have experience with UI frameworks and "real programming". At the time, doing frontend largely meant using jQuery to do ad hoc DOM manipulation and AJAX requests. Angular and then React came out and only tried to solve a subset of the problem that Ember was trying to solve, so they were easier for people to get started with. Then as time went on, it turned out that everyone did actually need solutions for everything else, but by then React had won.
There's definitely a number of reasons, but I vividly remember _struggling_ with Ember data at the time. The framework itself was already complicated and the data management story felt immature and rigid in addition to complex. That definitely pushed me towards and a number of others towards backbone and eventually React.
I think it adopts some ruby conventions (one I discovered is the name in singular vs plural can mean different things like a collection and an item of a collection). I think there are a lot of conventions like this - you have to know.
I am not a UI developer and just needed to understand/debug something, it was not easy at all.
I honestly love Ember.js, but a huge reason it had limited adoption was because it was extremely difficult to incrementally migrate to it.
React could be introduced only where it was needed, but Emberjs really wanted to be everywhere and in control of everything.
what reason?
Batteries included backend frameworks exists in the JS ecosystem, just look at https://adonisjs.com/ . The problem is that the nodejs ecosystem started off with micro-frameworks as the antithesis to what they believed were “overbearing” frameworks, like rails and Django, at the time. I remember express’s selling point was to build quick and dirty.
Even from the POV of micro-frameworks, the JS ecosystem sucks. There's just so many competing half-baked libraries doing the same thing slightly differently and incompatible ways.
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.
It's because JavaScript has no culture
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
JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails...
The problems people solve with JS are different from the ones solved with Rails. Which is why the frameworks look different.
> JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails...
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.
I don't know to what extent that's true compared to the npm ecosystem, but the js ecosystem largely rejects the monolith framework approach. It's focused heavily on frontend / browser, and the most popular JS frameworks are really just backends for frontend. Its most common to have a separate backend, perhaps in a different language, and it's an approach I prefer.
And I think rejecting the monolith is a massive mistake for the average CRUD app.
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.
Haha that comparison made me chuckle out loud. It's true though.
I find you get a lot of utility, but long-term you need to keep updating your codebase and follow whatever trend rails is currently on.
It's useful, but not necessary. Plenty of 10+ year old Rails apps in the wild. Github was running Rails 2.3 until 2018 while the entire software world that depended on it didn't fall apart. Even if you follow best advice and update your dependencies for security sake, you can effectively run the same code using the old "trends" (aside from things like safe parameters, etc).
(fwiw, GitHub switched to Rails 3 sometime around 2011-2012 or so).
Large rails apps tend to be on older versions not because they're so very stable but because Rails upgrades are a nightmare at scale. Even point versions have lots of undocumented breaking changes. There was a lot I didn't like during my 4 years as a rails developer but upgrades were the very worst of it.
Github is now running on the main branch:
> 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...
it all depends on your philosophy on dependencies. if you maintain a small set of core dependencies that are there for good reasons and are actively maintained, then rails upgrades are pretty easy. if you have a Gemfile that has a bunch of third party gems that you bring in for small problems here and there, you have to occasionally pay down that debt on version upgrades. we have an 18 year old rails codebase currently on 7.1 that hasn't proven to be a big pain for upgrades. the hardest upgrade we did was because of a core dependency that had been dead for 5 years broke with a new version of rails. but that was a story of letting technical debt ride for too long and having to pay it back.
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....
Honestly asking, but did you forget to add a “/s”?
Were you forced to move to JS for job-related reasons? It's unclear what you miss since Rails still exists.
I remember that era, of using vanilla rails with server-generated forms and POST requests leading to more forms.
... 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).
I’m using Rails with IntertiaJS which allows React Vue or Svelte for your front end views for Rails or Laravel (made by Laravel).
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.
The point of rewriting everything in JS isn't functionality, but portability.