4 ms·

I love the new hotwire stuff. What don’t you like about thd front-end?

bradgessler 3y ago
Asset pipeline is a hot mess: https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ Propshaft should bring sanity back to it, but its going to be a while before that's mainstream.
- ulizzle 3y ago
  That has been a hot mess for almost a decade now.
- mosselman 3y ago
  This is all about to change. A totally new way of using assets is coming with Propshaft which replaces Sprockets
  - caseyohara 3y ago
    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.
    - nickjj 3y ago
      > 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.
      - hu3 3y ago
        I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech. There's a point when change is just too much and the returns are diminishing.
        nickjj 3y ago
        > 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.
- config_yml 3y ago
  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.
- hu3 3y ago
  And this version added Bun support :)

Asset pipeline is a hot mess: https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ https://fly.io/ruby-dispatch/making-sense-of-rails-assets/ Propshaft should bring sanity back to it, but its going to be a while before that's mainstream.

ulizzle 3y ago
That has been a hot mess for almost a decade now.
mosselman 3y ago
This is all about to change. A totally new way of using assets is coming with Propshaft which replaces Sprockets
- caseyohara 3y ago
  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.
  - nickjj 3y ago
    > 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.
    - hu3 3y ago
      I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech. There's a point when change is just too much and the returns are diminishing.
      - nickjj 3y ago
        > 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.
config_yml 3y ago
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.
hu3 3y ago
And this version added Bun support :)