Thus there was no way around Webpack Yarn or any other helping tool for JS until now.
Now we have importmaps and good support in browsers for east least ES6 (https://caniuse.com/?search=es6) thus there is almost no need for extra tooling so you can write modern JS.
Which ones? Never saw another one which comes with the same comfort of batteries included like rails. For example having database migrations built in etc.
Pure SQL migrations, regardless of the back end technology that you use, completely decoupled from how each framework/library views things and therefore not dependent on them (you could even rewrite the back end in another technology later on, if needed; or swap ORMs; or avoid issues when there's a major ORM version update).
* a DB that has migrations applied with dbmate, completely decoupled from any back end(s) that might use it
* a back end that has entity mappings for ORM (if used) generated from the live local test database container during development, used for an API and not much more
* a front end that's typically a SPA using the API, but is otherwise just a bunch of prepared files that can be served off of any web server
Of course, if you need SSR then things move around a bit, but that decoupling works great for me (but might not for others)!
I remember looking at BSON de/serializers for some perceived performance issue a while back, ruby was only marginally slower than PHP for the same task, which was just pulling big record sets back from the db. Can you elaborate?
It was about maybe late last year/Jan this year. When you say intermediate language, do you mean PHP has a bytecode interpreter instead of AST? At the time I looked at it, to convince myself there was no issue with Ruby, I actually hooked up the same table/query to PHP and used PHP's excellent profiling tools, then compared those to the Rails profiler. There wasn't a great difference. PHP was faster sure, but there was definitely no knocking Ruby's speed.
> The performance of Rails serializers is still a nightmare
Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible.
But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent.
This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features.
That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.
And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.
That’s what a lot of people do. The value is still about convention over configuration IMO. If we are building a REST API, typical CRUD, you can go a long way with using Rails there and using something else when you need the performance or a certain feature.
For prototyping you don’t need a back end. You barely need one for production. Just some cloud functions and a cloud database. Firestore, gcf, or equivalent.
I think that’s pretty much it for big apps if we go with batteries included. Only Java frameworks compare on that front and if you’re a Ruby guy you likely don’t like Java.
I’ve been liking Golang but I haven’t had a job that used it in a while. Who knows what’s it’s like right now
I've just removed sprockets from my Rails app and replaced it with propshaft, jsbundling-rails and cssbundling-rails. It took a couple minutes max. Now the "frontend" parts are no longer tied to the rails app, except you get a nice integration with rails assets:precompile and including the final bundle is as easy as ever with Rails.
I honestly can’t tell if your comment is sarcastic because my biggest gripe with Rails is that the asset story changes radically with every major release.
Starting with 3.2 and the introduction of the asset pipeline, every new version was “This is all about to change. A totally new way of using assets is coming.”
Every new version is supposed to solve all of the problems of the previous version. It’s exhausting to constantly change to keep up with the new One True Way™, only for it to be replaced with another assets strategy powered by a gem with a cute name.
RJS and Prototype, then UJS and jQuery, then Sprockets and CoffeeScript and Sass, then Turbolinks, SCSS, then Dart Sass, then Stimulus and Webpacker, then esbuild and TypeScript, then Turbo, then import maps but there’s also jsbundling/cssbundling, then Hotwire, then Strada, then “Turbo 8” and TypeScript is suddenly phased out because DHH doesn’t like it, and now Bun.
I’m probably leaving something out and this is certainly out of order. But my point stands: the prescribed way of handling assets with Rails is ridiculous.
I think a lot of communities assumed letting JS asset pipelines manage JS, CSS, and image assets would lead to a better future. Sadly that didn’t materialize and it inflicted a lot of damage on DevUX.
Today the perception is that the JS community doesn’t seem to care about providing a stable experience for those outside of it, which is why projects like Rails and Phoenix are successful with “No/Low-JS” features.
Where Rails screwed up is not updating their docs to reflect this new reality for a really long time. It wasn’t clear what people should be using. They’re still creating confusion by making it unclear if Turbo is for Rails or all web frameworks, which you’ll notice when you go to the Hotwire landing page and see no mention of Rails.
> But my point stands: the prescribed way of handling assets with Rails is ridiculous
What would the alternative be for a 20 year old project?
I think what we're seeing is a natural progression based on how the web changed over the last 2 decades.
I'd be more concerned if Rails didn't change and `rails new` produced a jQuery / SCSS / CoffeeScript loadout and made it difficult to use modern tools. Now it's easier than ever to plug in whatever front-end you want.
> I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.
How tho?
Things naturally progressed from a lot of asset related things with few choices being baked into Rails to being more componentized but still tightly baked into Rails (Webpacker) to even more componentized and mostly decoupled from Rails (current state of things) to even more decoupled from Rails (Propshaft).
Current day if you want to use Webpack or esbuild or something else or nothing it's easy because Rails no longer cares. It only cares that assets end up in a specific directory. How they get there is up to you. The framework also provides value by giving you generators to tie things together based on the choices you want so you don't have to figure it out individually from ground zero.
If you look at it from that perspective I think things unfolded reasonably well.
Personally I didn't like Webpacker at all. Webpack was complicated enough on its own and then having to learn the Rails way of configuring it made it even harder. But I think it was a good tipping point to demonstrate that from a maintainer's POV it's hard and time consuming to create good abstractions over front-end tools on the back-end and from an end user's POV it's bad because of the complexity.
Being able to look directly at esbuild's documentation and apply it 1:1 is a much nicer outcome for everyone. Maintainers don't have to keep up with every change and users don't have another layer of abstraction to deal with.
It did take Rails a while to come to this solution but it's really good that they did. This is how I managed front-end tools in Flask and other frameworks for around the last ~decade. You have the framework look for assets in 1 spot and how they get there is up to you. It was easy for me to do that because I only had to make it work for my apps, my client's apps and the starter apps I posted on GitHub, but applying that to a framework that has hundreds of thousands of people using it is for sure a bigger project.
On the front-end it’s been a mess for a really long while now though