| Where nextjs kicks ass is that coding front end interaction (sans back end interaction) and doing interaction in response to server feels almost identical. There is no “ugh ok … better set up react now” feeling to make say an interactive chart because it was always there. Similarly there is no “ugh ok … better set up a backend now” feeling you get using create-react-app as it was always there. There is almost no mental gear switch as you switch from front to back to front. The only small negative is you need to be careful what that first “server side” render produces and what it can access. But that is also part of the magic, as you can fine grain control the initial flash of content. For example include the layout/menus. Or include a cached view of a list that then updates on final render. It just feels so well integrated more than any other framework I have tried (like aspnet mvc or RoR for example). It will be hard to beat: If you want to beat it in Go you need at least a good Go->JS transpiler so you can use the same language. But even then anything other than JS/Typscript means I need a mental modal of what the transpiler is doing. I don’t get a free pass
on understanding JS or the DOM. |
I hope is that Go <=> JS/Svelte won't be too much of a context switch for folks.
I'm not planning on innovating as hard in the frontend space as Next.js. I'll probably just stick with SSR, add support for pre-rendering and build up the client-side runtime with features like prefetching and client-side routing. If something really cool comes along, we'll see.
I'll instead focus on the area where Next.js neglects: backends. DB workflows, mailers, queues, scheduling, pubsub are all coming to Bud.