Earlier quoted context omitted.
Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day? Then you can even run multiple projects off the same server.
No click-ops that way.
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
201–210 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#202I just tried their domains page it took 10.8MB of data and took 2s for the DOM to be ready. page actually took 17s to fully render with multiple shift changes. all to render a domain search bar similar to google home page. https://railway.com/domains
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#203I 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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#204Earlier quoted context omitted.
I got it down to 1.03MB by just switching the png to palette encoding mode.
Got the same running through tinypng.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#205Recently I was ~70% done on a project using the relatively young Electrobun framework when I hit a non-negotiable limitation
So I told a $$$ agent to plan and implement a migration to Tauri, then repeated the loop of telling a $ agent to look for feature parity issues and having a $$ agent verify and fix the issues
In a couple of hours I got virtually the same app in a different framework
So there's definitely less burden in choosing the right framework at the start of a project, and less justification to keep a suboptimal infrastructure simply due to cost of migration
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#206I loved NextJS when it was relatively new but with turbo pack, the app router (and the insane amount of bugs that came with it) it's no longer my go-to frontend framework.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#207Earlier quoted context omitted.
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…
If an LTS of an OS replaced nginx with something else, a. it would be announced with great fanfare months in advance b. if you don’t want to do that, add apt / yum / zypper install nginx to your Ansible task, or whatever you’re using.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#208Earlier quoted context omitted.
HTMX is great when your web interface is just a representation of a server state. If web interface is an application backed by a remote state HTMX falls apart.
> If web interface is an application backed by a remote state What does that mean?
its also the perfect opposite of "true web3" and ethereums original vision, where you load all static assets from ipfs, most app logic is client side and the server or blockchain only comes in (json api, no html fragments or full pages) when you need to interact with other users. still believe in it even after the crypto bros took the name for a bunch of scams and hosted everything on cloudflare anyway. the only thing they have in common i could find is no bundling but for different reasons - everything on server vs compiled libraries shared between apps.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#209Earlier quoted context omitted.
Not containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS. At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
I build some projects via pm2 deploy directly on a server and its much faster then vercel
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#210Earlier quoted context omitted.
Not containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS. At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
Turbopack, custom runtime infrastructure on top of AWS Lambda.