Live data from Hacker News

We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

blog.railway.com

221–230 of 230 posts

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#221
post #217

Earlier quoted context omitted.

Facebook, Spotify, Figma, really anything interactive beyond sending a simple form.

You can achieve a great deal of interactivity with pure get/post requests, along with a sprinkling of javascript one-liners and maybe alpine.js if client interactivity is important.

Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful.

Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#222
post #221

Earlier quoted context omitted.

You can achieve a great deal of interactivity with pure get/post requests, along with a sprinkling of javascript one-liners and maybe alpine.js if client interactivity is important.

Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful. Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.

It's just not. I have done all these things. Maintenance is a piece of cake. Sorry that you struggled with this.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#223

Earlier quoted context omitted.

I build some projects via pm2 deploy directly on a server and its much faster then vercel

Not every project can be compiled on production server since compiling NextJS might take quite a lot of RAM, I would advise against it.

we have 128ram on our production server I think it will be fine ;)

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#224
post #104

Earlier quoted context omitted.

Turbopack, custom runtime infrastructure on top of AWS Lambda.

Turbopack does not work for every app, I think they skip some build steps when building like typescript validation etc and aggressively cache node modules.

> skip some build steps

There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-u...

This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers.

> typescript validation

There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons.

There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack.

> aggressively cache node modules

We aggressively cache everything. We don't have special-casing for `node_modules`. See our blog post about our caching system: https://nextjs.org/blog/turbopack-incremental-computation

Interestingly vite does actually special-case and cache `node_modules`: https://vite.dev/guide/dep-pre-bundling

There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#225
post #224

Earlier quoted context omitted.

Turbopack does not work for every app, I think they skip some build steps when building like typescript validation etc and aggressively cache node modules.

> skip some build steps There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-u... This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This chan…

Unfortunately turbopack have some bugs in bundling. Does not work on some of my projects. Can't reproduce outside of whole codebase, so no ticket.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#226
post #78

Earlier quoted context omitted.

web dev is a sewer All my projects are server rendered with jinja/minijinja, bootstrap, jQuery, and htmx when I need a little bit of SPA behavior on forms. No builds, just static <script src= tags. Very fast and easy. I'll never recommend anything else.

With C#'s Blazor templating, you can ditch all JS logic, and use raw C# for all front-end logic, and have it all be transparently server rendered similar to how Phoenix has LiveView. I also have experimented with HTMX and Django, and that seems to be a nice combination. Everything is AJAX again.

And all the latency of classic ASP.Net Webforms. Click a button and see the page change in the length of a short yawn. Or, switch to client side wasm and load a payload that makes the typical react dev jealous.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#227
post #221

Earlier quoted context omitted.

Yes, but doing with just HTMX, a framework we're talking in this thread, would be very painful. Every project I started with alpine.js eventually transitioned to something heavier because it was hard to maintain once you're having something more interactive than an accordion or sliding drawer.

It's just not. I have done all these things. Maintenance is a piece of cake. Sorry that you struggled with this.

Well agree to disagree. To me, it felt like HTMX was a wrong tool for anything other than pure server side representation (i.e. a little bit more advanced than refreshing entire page on new data).

I guess it's easier if you move all client logic to server, but I didn't want backend to know about web representation details.

Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

#229
post #169

Earlier quoted context omitted.

This is all trivial, and can and should be automated. Furthermore, all of your arguments can easily be applied to NodeJS version deprecations, React realizing they shipped a massive CVE, etc. I will die on this hill: parent is correct - the ability to manage a Linux server should be a requirement to work in the industry, even if it has fuck-all to do with your job. It proves some basic level of competence and knowled…

I'm curious about this trivial automation. Let's say the new OS LTS version no longer includes nginx, because it was replaced by a new product with different config. How does the automation figure out what the new server package is and migrate your old Nginx config to the new format? I agree with Node.js version deprecations being a huge problem and personally advocate for an evergreen WebAssembly platform for runnin…

The answer is to write your server in portable C++, and just rebuild it for whatever new OS you're dealing with.

The speed. Imagine the performance. There are plenty of mature C++ web server frameworks, it's really not difficult. If you're afraid of C++, you could choose something else. Rust if you're insane, or golang if you're insane but in a different way.

Anyway. Nginx is not going away, so the argument is a bit silly. "What if js went away". Same thing.

Post reply on HN