I work for one of the biggest ecommerce aggregators in Polish Internet. The most valuable feature is quite simple - you see some products, click them and buy them on a shop site. So how could we end up with SSRed React + Redux combo? Is it really worth it?
When I joined the team and saw redux state in Rails controller my first thought was - someone finally got this right. Instead of rendering full HTML or preparing containers for SPA-like components we can just use React on Rails SSR and use redux_state helper to pass it to props. On Rails side I no longer thought about views, I only focused on passing proper JSONs to frontend.
It’s quite fast and easy to maintain, but has also some downsides - you have to stick to React on Rails hydration model, you’ll probably use older node because of Ruby’s JS bindings (or have incorrect locale). Because you use the same components on backend and frontend you may end up with really big JS bundles, especially if you’re too much into SPA having all components available in single bundle. As you can see it has limitations in the way you can optimize it so we decided to give a try to some other options.
It became popular lately as a way of creating single page apps or rich static pages. The framework seems to be really simple - you create a component for each route - the route is represented with file (even with weird names like [id].js). There is a layout you use to share common HTML snippets, each component has its CSS and JSX-alike component code with some JS bindings - quite Web Componentish. It’s SSRed with rich frontend interactions - i.e. you can go to other route, get its JS (from other bundle) and JSON with new state. And it’s all done by framework with a magic link.
The magic is something I’m always fear anxiety of. It’s usually just metaprogramming or really complicated function with convention around it but still too clever solutions feel like smell. They are hard to manage in long term, especially when you need to extend or slightly override them.
It’s the first framework I saw using backend-to-backend calls even for frontend events. I mean - when you call new page that depends on a REST endpoint the request is made on next’s backend and populated to frontend. So it’s AJAX call which makes backend call to real backend. 2 hops. The latency may hurt you twice.
It’s also problematic when the backend is slow. The interaction becomes so weird you don’t actually see consequences of your actions. You can polish the UX slighly by adding native-alike throbber or just optimize the backend too.
I explored few real life examples of next.js usage on ecommerce websites and it was aweful. Interactions were out of sync, load time was aweful and I don’t actually understand why someone decided to use it. This is the biggest painpoint - I don’t see any good implementation.
It’s new language you can transpile to JS. It’s optimized for rendering components - instead of using virtual DOM it just compiles actions into DOM-change chunks ready to apply. It’s the main promise - you’ll have your frontend faster because you don’t have to calculate diffs between virtual DOM and real one.
I really like the other great feature - reactiveness. Instead of inlining mappings into components or preparing special functions to transform the data you can actually create reactive values which will depend on variables and constants only. That way you can transform your state into read models and communicate the difference more clearly.
I implemented TodoMVC (without nice stylesheet) in about 2-3 hours while learning the language so you can expect it to be really easy. The biggest difference is in templating language and the are some gotchas with collection components.
The svelte itself is dedicated to frontend-heavy applications. There is SSR support as far as I know, but it looks hidden in documentation and believe it’s just immature. But the svelte has its own next.jsish framework called Sapper. It’s actually heavily influenced with next.js, so you can expect weird filenames for route components, SSR support and backend-to-backend communication style.
I played with it only on dev environment so it’s hard for me to say about its production performance. The dev one looked promising though, but as its Sapper framework is influenced on next.js backend-frontend integration ideas I believe it may be hard to have it performant backend calls.
Both new ways of creating frontend-heavy apps looks promising and would probably buy me in, but their backend support and interaction looks really weird - links that loads seconds after click with no visual indicator or so. You have to take care of your backend calls performance and probably optimise a route between frontend and backend. Will we use any of it? Maybe the best parts, ideas behind these solution, but not them per se.