Railway should try Rails
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
111–120 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#112It’s absolutely mind boggling to me that we have gotten to a point that building a web frontend takes longer than compiling the Linux kernel..
[deleted]
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#113Earlier 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.
I've a C# fanboy, but Blazor's DX just isn't very good compared to say Vite.
There are many conditions under which the hot reload just straight up crashes out regularly.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#114Earlier quoted context omitted.
It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.
This is extremely easy with tools like dokploy tho... I use dokploy locally to manage all my VPSs + home server. Truly good stuff and I don't believe your quip at the end, it feels like poisoning the open source waters for consolidated anti democratic cloud platforms. It's way way way way easier managing a basic VPS that can be highly performant for your needs. If this was 2010, I'd agree with you but tooling and pra…
Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human.
I can see though that today's AI models could eventually replace the human in the loop and truly automatically fix every possible situation.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#115Earlier quoted context omitted.
This is extremely easy with tools like dokploy tho... I use dokploy locally to manage all my VPSs + home server. Truly good stuff and I don't believe your quip at the end, it feels like poisoning the open source waters for consolidated anti democratic cloud platforms. It's way way way way easier managing a basic VPS that can be highly performant for your needs. If this was 2010, I'd agree with you but tooling and pra…
Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human. I can see though that today'…
I must be using the wrong cloud services. Whenever a part of our app goes down someone on the team still needs to respond to it.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#116You can't keep JS devs away from the new shiny framework for long.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#117Earlier quoted context omitted.
Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human. I can see though that today'…
I must be using the wrong cloud services. Whenever a part of our app goes down someone on the team still needs to respond to it.
you actually need new ops teammates, not new cloud services :)
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#118Two minutes is still way too long. What are we doing? This is ridiculous.
2 mins for a production deploy of an app with millions of users? Seems fine to me! How fast would you expect it to be?
so build time scales with the number of users? meta's build times of roughly 2hrs and 11 minutes then makes a lot of sense
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#119Incredible that the builds were ever 10min. How far things have regressed.
[deleted]
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#120I have a Nextjs heavy app which takes around 7 minutes currently. But I've been thinking of moving away from next for a long time now. TanStack seems to be a good fit. This gives me a bit more confidence in just doing it.
I recently switched from NextJS — where every one of the dozens of projects I built would have 7-8 minute deployment times, regardless of hosts — to React Router, and saw my deployment times drop to 1-2 minutes.
Aside from some difficulty with mastering environment variables, I’ve been delighted with the change and will probably not look back.