51–60 of 456 posts
Isn't Next.js (and in turn React, on which Next is built) the answer to that question? It can do client side rendering, server side rendering, and static site genration.
That said, something that requires a lot of thought is not just constantly displaying spinners. When I look at projects built by experienced FEs it seems like there's a lot of patterns to work around this that I'm not aware of.
Earlier quoted context omitted.
You want a web browser talking directly to an RDBMS of some kind?
Yes, like we had with WebSQL until it was deprecated. Basically a SQLite db per site.
The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.
Isn't SSR (or even better SSG) the M in JAM? It's a marketing term anyway and it doesn't really need to "lose", we can just talk about the technologies instead. Next.js gives you a great toolbag to choose from for each challenge, it's definitely going to stay around and keep growing like crazy.
LiteDOM https://litedom.js.org/
Stimulus https://stimulusjs.org/
Turbolinks https://github.com/turbolinks/turbolinks
My argument for SPAs rests on the completely subjective yet I feel incredibly powerful impact of latency. When anything takes more than 50ms to react, it becomes mentally jarring to the user. Whether it is typing in an SSH session, clicking a menu with a mouse, auto-completing a box, etc - all these things generate a completely different human response and relationship with the application if they get below that thre…
If a non-SPA page loads near instantaneously because the client-side rendering isn't bloated, it can feel just as good as an SPA with spinners.
You can also use tools like turbolinks the author recommended, to turn your non-SPA into an SPA.
The future is Next.js with SSR first and selective client side hydration. Ignore the jamstack, it's going to lose and go away. Requiring a JS download first to show a dynamic site is a recipe for bad performance.
I would also prefer something like Next.js with partial hydration. But what I want in that is probably a much bigger ask: I want the partial hydration to be performed automatically with static analysis. Something like Svelte (real DOM codegen, no need to ship a library to the browser) would be especially nice, but I don’t want to give up JSX. In the end, this is probably well outside the scope of a framework coupled…
Isn't Next.js (and in turn React, on which Next is built) the answer to that question? It can do client side rendering, server side rendering, and static site genration.
It was my first thought, but mope. Read the article and check out a few of the mentioned frameworks, it's eye opening.
I know the other frameworks and to me they all seem to have given up and go back to SSR.
I'm much more interested in what's coming from the Snowpack/Skypack direction.
The missing link, IMHO, is the lack of client side SQL and a sync mechanism. IndexDB is okay, but nobody is going to use it server side. So you kind of always have to end up writing things twice.
The framework that I feel makes development less ugly is svelte. But still, I really don't like the idea of heavy client side websites. It really makes everything more complicated and the user's device slower.
I love the simplicity of Turbolinks, I love how clean svelte code is and I am trying to figure out the "glue"