Yeah I don’t disagree here. I think my sentiment is mostly if Turbo isn’t the route that you want to go something like next js or sveltekit or whatever starts looking a lot shinier. Especially someone outside of the Rails world evaluating tech for a new site
I would watch this talk. I honestly have no idea, at least for JS. I use Tailwind for CSS (I can write style rules but not well and maintaining stylesheets is not a skill I possess) so I definitely understand my need for a build step there.
@fito.codegardener.com and I are considering writing a talk about why putting all your business logic in your models is a bad idea -- specifically for Tropical.rb -- but in the context of, "Hey, Merb had some good ideas (restful routes, bundler!). Why can't we challenge the status quo elsewhere?"
Tropical has a list of topics they want speakers to discuss in their CFP. It's basically marketing for Rails 8. But, the do say this: "We encourage you to submit proposals that challenge the status quo, showcase forward-thinking ideas, and push the boundaries of what's possible with Rails."
We had a fantastic time at Tropical.rb last year. With the infusion of Rails Foundation support, it seems like the conference will be a bit more like Rails World this year.
São Paulo is astonishingly big. Hardly saw any of it. Want to go again!
i think no-build is a sensible default for Rails. it allows you to get going fast and is a good onramp for indie devs, which DHH specifically calls out as the goal -- "one person framework" etc. for anyone larger than that they have the resources to invest in more complex tooling from the start
please! We adopted import maps from day one and used them till the shim was removed. Suddenly hundreds of users couldn’t access our app. Instead of rolling back, or shunning our users with older browsers, we switched to esbuild—and gained 10 points on our Lighthouse score!
Don't you think no-build makes sense for small applications with minimal JavaScript dependencies?
Modern CSS is very good and I don't feel the need for a build step anymore. Importmaps works fine too if you know you won't rely on a lot of JavaScript dependencies.
I don’t. The point where you have a single import or function is the point where TypeScript starts paying for itself by stopping you from making easy mistakes.
Careful on this one: import maps are still not supported for workers, SharedWorkers & ServiceWorkers. If you want to use a module based on it inside a worker, you might get screwed.
Otherwise I agree: running the dev mode of frontend code without a build step is a life saver. Doing it since 6 years
I think it's a sane default though, yes? Anybody doing something complex with an existing rails project will go right to esbuild when they evaluate the options, and anybody truly new to the frontend can benefit from starting off with the simplicity of import maps as they learn.
I guess I disagree here. Importmaps are more conceptually straightforward than bundling and transpiling, where there is a ton of hidden complexity and third party tooling instead.
The worst case scenario though is that you start small with importmaps only to later need a lot of dependencies.
You still have to learn and understand the Rails configuration/DSL for importmaps. And TBH, esbuild is easier to understand and learn + more generally useful outside Rails (at least for me it is)
I do agree with you 100% on this one. There's nothing more straightforward than import maps. What I like is that Rails for example doesn't force "no build" on you, it gives you options. I started working on an app recently, considered the requirements and just picked esbuild.
We at @evilmartians.com agree! I gave a short talk saying that Vite is the missing abstraction at @viteconf.org this year https://www.youtube.com/watch?v=vIxQ6u9pHaw (also, @marcoroth.dev 's slide was super helpful!)
Answering your question, RailsConf is the best place! Now that I think about this, with RailsConf gone, Rails World is about the "mainstream" Rails only. Where're all the "Rails at Scale", Rails as a big tent, Rails as an ecosystem after 2025? Sadly, I don't know.
If I start a new Rails project I want to keep things as simple as I can until I can't, which means if I need a smattering of JS it's going through Propshaft.
Been a few years since i set up a build pipeline, though; how much work is it to integrate with Rails 8?
I'm very curious about this because it's very far from my area of expertise, and I want to level up in frontend stuff in 2025 🤔 I do disagree about it being a mistake because it works perfectly fine in some cases, but I don't know about the competitive disadvantage, really would like to know more
I'm in the same boat as Rosa, I'm actively learning. But it would be interesting to know how the current setup is disadvantageous? There is an option to go as advanced as a project needs.
For me, starting simple, seems like always a good option.
The importmaps implementation as it stands (v2) isolates you from a large number of NPM packages.
Packages which work for everyone outside of Rails, but needs a special snowflake precompiled single index.js entry point for Rails, with no way to fix it
*imagine a package pulls in Stimulus as a dependency, and you have stimulus in your app, now you've downloaded stimulus twice because you don't get deduping on precompiled files.
I have to check if Propshaft concatenates CSS, I know Sprockets still does it, but in theory for "#nobuild" if you're not concatenating CSS, it results in render blocking waterfalls if you use "@import" syntax in your CSS files.
Comments
I'm using Inertia with React here, but I agree with you. The community should embrace an open mindset like Laravel’s folks do.
Meanwhile, I can't use Mission Control’s jobs dashboard here no matter how hard I fought with the asset pipeline 🥲
https://www.youtube.com/watch?v=DtbimoRP7nc
It seems kinda crazy for the framework to not even acknowledge anything else.
Vite rails is actually a solid option though
“Not even acknowledge anything else” seems like a stretch 😅
I think they should invest in making alternatives just as first class and easy like Laravel does.
That’s just my opinion though. I don’t think there’s a lot of potential for growth with Turbo as your big bet
For some apps, it just makes sense to use a SPA for everything.
We had a fantastic time at Tropical.rb last year. With the infusion of Rails Foundation support, it seems like the conference will be a bit more like Rails World this year.
São Paulo is astonishingly big. Hardly saw any of it. Want to go again!
Rails 9 -> yes-build
Trust, my uncle knows someone who works near 37s who said dhh actually is gonna switch it up next year
But what is true is that the Rooftop Ruby Podcast is back with a great episode where I learned a wild story about the Beach Boys
Modern CSS is very good and I don't feel the need for a build step anymore. Importmaps works fine too if you know you won't rely on a lot of JavaScript dependencies.
I bet it would be a great talk!
I do agree w him, but totally get there are many TS fans out there
Run it as a check before committing, and ignore things you don’t care about? Sure. But most tools type check as you type….
Otherwise I agree: running the dev mode of frontend code without a build step is a life saver. Doing it since 6 years
The worst case scenario though is that you start small with importmaps only to later need a lot of dependencies.
I start my Rails app using ViteRuby
Would enjoy a post on your perspective!
If you want to use JavaScript or CSS, building it is best. Doesn’t really matter how much of it you have or how many dependencies.
Been a few years since i set up a build pipeline, though; how much work is it to integrate with Rails 8?
For me, starting simple, seems like always a good option.
Packages which work for everyone outside of Rails, but needs a special snowflake precompiled single index.js entry point for Rails, with no way to fix it
https://github.com/rails/importmap-rails/pull/235
So if I have 2 packages that each rely on that third package, I have to download that 3rd package twice.
Imagine pulling in packages with stimulus as a dependency
And it’s not like that package is going to be cached for other websites to use since that ideas was scrapped for security and privacy reasons.