9 ms·

Rails 6 with Webpacker 6, Tailwind 2 with JIT, Postcss 8 and some default setup

169 points by nauman 5y ago

Aeolun 5y ago
Wait. So… you practically need to develop an app to start developing an app? When someone tells me to ‘invoke these 3 magic incantations’, I can sort of keep track of it. But here it seems like the instructions are to invoke these 300 magic incantations.
- tolien 5y ago
  Yeah, one of the key selling points of Rails was that it was Omakase (Japanese: "I'll leave it up to you", i.e. you take the defaults Rails provides) and "batteries included" (i.e. there's enough provided in the box to get a working application). Having to jump through all these hoops (I'll note that one of the suggested gems is Devise, which provides a framework for user authentication) suggests either this is very much no longer the case or this is tacking on a lot of stuff Rails was never intended to use, which could be fun to maintain down the line.
  - kayodelycaon 5y ago
    The majority of hoops jumped through in the article are entirely of the writer’s own making. They changed the default CSS pipeline and added functionality Rails deliberately does not define. Devise is common for user authentication (and good choice, in my opinion) but it is extremely opinionated and does not like you departing from the blessed path. Rails tends to avoid enforcing patterns beyond the base building blocks of MVC. User authentication is out of scope. (Turbo links is strongly opinionated but also very limited and very easy to remove.)
    - tolien 5y ago
      My point about Devise was more “if you’re not using auth, why have you included this?”. I think Rails should probably have a Devise-lite in the box, though. This sounds like the second of my options i.e. gl;hf when the next major Rails release comes around.
      - blacktriangle 5y ago
        Rails choosing not to provide a standard auth solution is 100% the right call. There are a wide variety of auth scenarios, and Devise is highly opinionated. If you're doing a pretty standard B2C type system where you have individual users, Devise fits well, but when you get to more B2B multi tenant with users spanning tenants, and more complicated workflows with users managing other users, Devise breaks down quickly.
  - dyeje 5y ago
    Rails still works just fine out of the box. The bulk of this article is setting up Tailwind JIT, which is not required.
  - Mikeb85 5y ago
    Having just been playing around with Rails and different CSS frameworks for a new project, this is entirely due to Tailwind's dependencies. Adding other CSS frameworks is as easy as yarn add X then importing it into your application.css file.
  - jacobsenscott 5y ago
    This setup is deviating quite a bit from a default rails setup: using the beta webpacker, tailwind + plugins, some extra gems. Also - I noticed the author says "foreman is the best way to develop locally". I encourage the author to give overmind a try - it is a drop in, more featureful replacement for foreman. I love it.
- kayodelycaon 5y ago
  This is due to adding a JavaScript framework. Rails can be up and running immediately.
- darwingr 5y ago
  They are only generators. You don't need to use them but they are there if you choose to use them.
pjm331 5y ago
Love seeing the set of gems that folks tend to bring into all their projects. https://github.com/dejan/rails_panel https://github.com/dejan/rails_panel Was a new one for me, will def be checking that out
toberoni 5y ago
It's telling that most instructions deal with the Javascript toolchain and not Rails itself. And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome.
- masa331 5y ago
  It's still perfectly possible and valid to use Sprockets instead of webpack in a Rails app. That's what i do with every one of my applications and it works flawlesly
  - ch4s3 5y ago
    When I used to use Rails pre-webpacker I felt like I was constantly fighting with sprockets. Trying to use it with assets from node modules isn't always straightforward, and it's pretty slow (or used to be).
  - Madeindjs 5y ago
    It works until you try using a library not available with Sprocket...
    - sleepyhead 5y ago
      How can it not be available with Sprockets? You can just add .js files.
- buf 5y ago
  I started a saas company 2 weeks ago with the tool list described in the article. Already at $1k MRR. IMO, use whatever gets you to paid users fastest.
  - edoceo 5y ago
    Can you show it?
paozac 5y ago
Useful recap. I went through something similar a few weeks ago and the webpack/tailwindcss JIT/postcss setup has been a pain in the ass: dependency hell, outdated documentation, unintelligible error messages. I'm glad to see that both rails and phoenix guys are looking for a way out of this madness. The writing is on the wall.
- blacktriangle 5y ago
  What disappoints me is that the Rails team fell for this madness in the first place. Rails in particular has planted its flag on the maximize server-side work camp for the sake of overall tool simplicity. It seems like the Rails team was getting insecure of all the JS hype and "is Rails dying" articles and decided to start chasing trends. I called this the second they shoved webpacker into Rails6 and am not at all surprised this is where we are.
gjmacd 5y ago
Another reason to move to Elixir from Ruby...
- anamexis 5y ago
  Where setting up a new app with Tailwind JIT is substantially easier?
  - gjmacd 5y ago
    Where Phoenix does a better job with all this and you don't have Ruby's baggage anymore.
    - anamexis 5y ago
      What is "all this"? This post is almost entirely about setting up Tailwind. (I have developed professionally with both Rails and Phoenix and enjoy both.)
    - gjmacd 5y ago
      https://pragmaticstudio.com/tutorials/adding-tailwind-css-to-phoenix https://pragmaticstudio.com/tutorials/adding-tailwind-css-to...
      - anamexis 5y ago
        Right, this process looks basically equivalent in steps and complexity.
    - Mikeb85 5y ago
      It's literally the same process and it still uses webpacker...
- kweinber 5y ago
  Elixir is like the alternate town in Blazing Saddles. It looks great but you find out there aren’t really people nor library depth there. After it blows up your staffing and project plans you end up moving back.
cutler 5y ago
I think esbuild would have made webpack redundant soon if it hadn't already been removed.
ramesh31 5y ago
What is Webpacker?
- meepmorp 5y ago
  Webpack packaged for use in rails.
bouk 5y ago
I started work on a (webpacker-like) esbuild integration for Rails: https://github.com/bouk/esbuilder https://github.com/bouk/esbuilder It works, but needs UX work, documentation and more extensive testing to be appropriate for general use
chana_masala 5y ago
There are enough instances of webpacker in this thread (instead of webpack) making me think it's something different.
petepete 5y ago
I do kind of wish Rails had just taken the 'bring your own JavaScript and CSS' route instead of wrapping Webpack and adding a boatload of confusion due to multiple layers of things that don't feel like they were designed to work together. Tell me where to output my .js, .css and other assets and let me worry about compiling - or not as is often the case.
- deleted 5y ago
  [deleted]
- coffeefirst 5y ago
  Django went that route and it's not great either. I think the ideal would be some kind of middle ground: an optional contrib module, plugin, or even just documented pattern that can serve as an officially supported approach without baking a strong opinion directly into the framework.
- baggy_trough 5y ago
  Rails 7 is heading more that way. https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript...
adamwathan 5y ago
Creator of Tailwind here — if you don’t want to go deep into JS tooling and really just care about spitting out a CSS file, it's a lot simpler to just use our CLI tool: https://tailwindcss.com/docs/installation#using-tailwind-cli https://tailwindcss.com/docs/installation#using-tailwind-cli
- Mikeb85 5y ago
  Good to note!
- deleted 5y ago
  [deleted]
- AlchemistCamp 5y ago
  Any plans for adding integration guides for back-end frameworks like Rails and Phoenix? It seems like Tailwind is popular enough now to support guides for more than just JS frameworks and Laravel :)
- nauman 5y ago
  Thanks for responding, I wrote this to keep a record of my steps for future reference. I did not intend that this was the only way or the right path As I've seen many tutorials that were too complex to set up JIT with Tailwind, I thought it might be helpful to others as well who were having difficulty. The next version of Rails will eliminate webpacker anyway, so I'll write for it
nickjj 5y ago
If anyone wants to see a working example of this in Docker, I have an example app at: https://github.com/nickjj/docker-rails-example https://github.com/nickjj/docker-rails-example Besides Rails / Webpacker 6 and Tailwind with the JIT compiler it also includes Sidekiq, Action Cable and Turbo along with Postgres and Redis. I'm not married to the idea of Webpacker, but currently it's the most painless way to create bundles and process your CSS and JS even if you mostly use server side templates with sprinkles of JS. I'll switch the example app to what Rails defaults to in the future but right now we're in a limbo state where combining a bunch of other independent watchers (esbuild + Tailwind's watcher) and ESM isn't a better development experience IMO. With Webpacker and Tailwind's JIT, CSS + JS changes take 100ms and you can further optimize startup times with using Webpack's disk cache. With the above Docker set up it's configured with multi-stage builds so your final Rails app only has the end result of running an assets precompile which only runs with RAILS_ENV=production. The Webpack watcher only runs in development too. If anyone works with Phoenix instead, a similar example app is here https://github.com/nickjj/docker-phoenix-example https://github.com/nickjj/docker-phoenix-example. There's also example apps for Flask, Django, Node and Play too if you replace the name of the repo. All of them go over the motions of setting up a base line app with Tailwind and Webpack plus whatever else is idiomatic in that stack. Plot twist: For the Flask, Django, Phoenix, Node and Play examples I've used nearly the same Webpack config for 2 years and I continuously keep Webpack and all of the JS dependencies up to date. There hasn't been any issues at all. I wouldn't consider myself an advanced front-end developer either. I glanced their docs, found something that works and stuck with it.
thomasjklemm 5y ago
Using Vite with Ruby/Rails is also a modern option [1], really impressed after trying it out. The article "A Rubyist's Guide to Vite.js"[2] from the author of ViteRuby provides a cool deep dive. [1]: https://vite-ruby.netlify.app https://vite-ruby.netlify.app [2]: https://maximomussini.com/posts/a-rubyist-guide-to-vite-js/ https://maximomussini.com/posts/a-rubyist-guide-to-vite-js/
- bjacobso 5y ago
  I agree, this feels like the direction the framework should go in the future

169 points by nauman 5y ago

Wait. So… you practically need to develop an app to start developing an app? When someone tells me to ‘invoke these 3 magic incantations’, I can sort of keep track of it. But here it seems like the instructions are to invoke these 300 magic incantations.

tolien 5y ago
Yeah, one of the key selling points of Rails was that it was Omakase (Japanese: "I'll leave it up to you", i.e. you take the defaults Rails provides) and "batteries included" (i.e. there's enough provided in the box to get a working application). Having to jump through all these hoops (I'll note that one of the suggested gems is Devise, which provides a framework for user authentication) suggests either this is very much no longer the case or this is tacking on a lot of stuff Rails was never intended to use, which could be fun to maintain down the line.
- kayodelycaon 5y ago
  The majority of hoops jumped through in the article are entirely of the writer’s own making. They changed the default CSS pipeline and added functionality Rails deliberately does not define. Devise is common for user authentication (and good choice, in my opinion) but it is extremely opinionated and does not like you departing from the blessed path. Rails tends to avoid enforcing patterns beyond the base building blocks of MVC. User authentication is out of scope. (Turbo links is strongly opinionated but also very limited and very easy to remove.)
  - tolien 5y ago
    My point about Devise was more “if you’re not using auth, why have you included this?”. I think Rails should probably have a Devise-lite in the box, though. This sounds like the second of my options i.e. gl;hf when the next major Rails release comes around.
    - blacktriangle 5y ago
      Rails choosing not to provide a standard auth solution is 100% the right call. There are a wide variety of auth scenarios, and Devise is highly opinionated. If you're doing a pretty standard B2C type system where you have individual users, Devise fits well, but when you get to more B2B multi tenant with users spanning tenants, and more complicated workflows with users managing other users, Devise breaks down quickly.
- dyeje 5y ago
  Rails still works just fine out of the box. The bulk of this article is setting up Tailwind JIT, which is not required.
- Mikeb85 5y ago
  Having just been playing around with Rails and different CSS frameworks for a new project, this is entirely due to Tailwind's dependencies. Adding other CSS frameworks is as easy as yarn add X then importing it into your application.css file.
- jacobsenscott 5y ago
  This setup is deviating quite a bit from a default rails setup: using the beta webpacker, tailwind + plugins, some extra gems. Also - I noticed the author says "foreman is the best way to develop locally". I encourage the author to give overmind a try - it is a drop in, more featureful replacement for foreman. I love it.
kayodelycaon 5y ago
This is due to adding a JavaScript framework. Rails can be up and running immediately.
darwingr 5y ago
They are only generators. You don't need to use them but they are there if you choose to use them.

pjm331 5y ago

Love seeing the set of gems that folks tend to bring into all their projects. https://github.com/dejan/rails_panel https://github.com/dejan/rails_panel Was a new one for me, will def be checking that out

toberoni 5y ago

It's telling that most instructions deal with the Javascript toolchain and not Rails itself. And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old. I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome.

masa331 5y ago
It's still perfectly possible and valid to use Sprockets instead of webpack in a Rails app. That's what i do with every one of my applications and it works flawlesly
- ch4s3 5y ago
  When I used to use Rails pre-webpacker I felt like I was constantly fighting with sprockets. Trying to use it with assets from node modules isn't always straightforward, and it's pretty slow (or used to be).
- Madeindjs 5y ago
  It works until you try using a library not available with Sprocket...
  - sleepyhead 5y ago
    How can it not be available with Sprockets? You can just add .js files.
buf 5y ago
I started a saas company 2 weeks ago with the tool list described in the article. Already at $1k MRR. IMO, use whatever gets you to paid users fastest.
- edoceo 5y ago
  Can you show it?

paozac 5y ago

Useful recap. I went through something similar a few weeks ago and the webpack/tailwindcss JIT/postcss setup has been a pain in the ass: dependency hell, outdated documentation, unintelligible error messages. I'm glad to see that both rails and phoenix guys are looking for a way out of this madness. The writing is on the wall.

blacktriangle 5y ago
What disappoints me is that the Rails team fell for this madness in the first place. Rails in particular has planted its flag on the maximize server-side work camp for the sake of overall tool simplicity. It seems like the Rails team was getting insecure of all the JS hype and "is Rails dying" articles and decided to start chasing trends. I called this the second they shoved webpacker into Rails6 and am not at all surprised this is where we are.

gjmacd 5y ago

Another reason to move to Elixir from Ruby...

anamexis 5y ago
Where setting up a new app with Tailwind JIT is substantially easier?
- gjmacd 5y ago
  Where Phoenix does a better job with all this and you don't have Ruby's baggage anymore.
  - anamexis 5y ago
    What is "all this"? This post is almost entirely about setting up Tailwind. (I have developed professionally with both Rails and Phoenix and enjoy both.)
  - gjmacd 5y ago
    https://pragmaticstudio.com/tutorials/adding-tailwind-css-to-phoenix https://pragmaticstudio.com/tutorials/adding-tailwind-css-to...
    - anamexis 5y ago
      Right, this process looks basically equivalent in steps and complexity.
  - Mikeb85 5y ago
    It's literally the same process and it still uses webpacker...
kweinber 5y ago
Elixir is like the alternate town in Blazing Saddles. It looks great but you find out there aren’t really people nor library depth there. After it blows up your staffing and project plans you end up moving back.

cutler 5y ago

I think esbuild would have made webpack redundant soon if it hadn't already been removed.

ramesh31 5y ago

What is Webpacker?

meepmorp 5y ago
Webpack packaged for use in rails.

bouk 5y ago

I started work on a (webpacker-like) esbuild integration for Rails: https://github.com/bouk/esbuilder https://github.com/bouk/esbuilder It works, but needs UX work, documentation and more extensive testing to be appropriate for general use

chana_masala 5y ago

There are enough instances of webpacker in this thread (instead of webpack) making me think it's something different.

petepete 5y ago

I do kind of wish Rails had just taken the 'bring your own JavaScript and CSS' route instead of wrapping Webpack and adding a boatload of confusion due to multiple layers of things that don't feel like they were designed to work together. Tell me where to output my .js, .css and other assets and let me worry about compiling - or not as is often the case.

deleted 5y ago
[deleted]
coffeefirst 5y ago
Django went that route and it's not great either. I think the ideal would be some kind of middle ground: an optional contrib module, plugin, or even just documented pattern that can serve as an officially supported approach without baking a strong opinion directly into the framework.
baggy_trough 5y ago
Rails 7 is heading more that way. https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript...

adamwathan 5y ago

Creator of Tailwind here — if you don’t want to go deep into JS tooling and really just care about spitting out a CSS file, it's a lot simpler to just use our CLI tool: https://tailwindcss.com/docs/installation#using-tailwind-cli https://tailwindcss.com/docs/installation#using-tailwind-cli

Mikeb85 5y ago
Good to note!
deleted 5y ago
[deleted]
AlchemistCamp 5y ago
Any plans for adding integration guides for back-end frameworks like Rails and Phoenix? It seems like Tailwind is popular enough now to support guides for more than just JS frameworks and Laravel :)
nauman 5y ago
Thanks for responding, I wrote this to keep a record of my steps for future reference. I did not intend that this was the only way or the right path As I've seen many tutorials that were too complex to set up JIT with Tailwind, I thought it might be helpful to others as well who were having difficulty. The next version of Rails will eliminate webpacker anyway, so I'll write for it

nickjj 5y ago

If anyone wants to see a working example of this in Docker, I have an example app at: https://github.com/nickjj/docker-rails-example https://github.com/nickjj/docker-rails-example Besides Rails / Webpacker 6 and Tailwind with the JIT compiler it also includes Sidekiq, Action Cable and Turbo along with Postgres and Redis. I'm not married to the idea of Webpacker, but currently it's the most painless way to create bundles and process your CSS and JS even if you mostly use server side templates with sprinkles of JS. I'll switch the example app to what Rails defaults to in the future but right now we're in a limbo state where combining a bunch of other independent watchers (esbuild + Tailwind's watcher) and ESM isn't a better development experience IMO. With Webpacker and Tailwind's JIT, CSS + JS changes take 100ms and you can further optimize startup times with using Webpack's disk cache. With the above Docker set up it's configured with multi-stage builds so your final Rails app only has the end result of running an assets precompile which only runs with RAILS_ENV=production. The Webpack watcher only runs in development too. If anyone works with Phoenix instead, a similar example app is here https://github.com/nickjj/docker-phoenix-example https://github.com/nickjj/docker-phoenix-example. There's also example apps for Flask, Django, Node and Play too if you replace the name of the repo. All of them go over the motions of setting up a base line app with Tailwind and Webpack plus whatever else is idiomatic in that stack. Plot twist: For the Flask, Django, Phoenix, Node and Play examples I've used nearly the same Webpack config for 2 years and I continuously keep Webpack and all of the JS dependencies up to date. There hasn't been any issues at all. I wouldn't consider myself an advanced front-end developer either. I glanced their docs, found something that works and stuck with it.

thomasjklemm 5y ago

Using Vite with Ruby/Rails is also a modern option [1], really impressed after trying it out. The article "A Rubyist's Guide to Vite.js"[2] from the author of ViteRuby provides a cool deep dive. [1]: https://vite-ruby.netlify.app https://vite-ruby.netlify.app [2]: https://maximomussini.com/posts/a-rubyist-guide-to-vite-js/ https://maximomussini.com/posts/a-rubyist-guide-to-vite-js/

bjacobso 5y ago
I agree, this feels like the direction the framework should go in the future