Server-Side Only React with Next(webcloud.se) |
Server-Side Only React with Next(webcloud.se) |
-> Website needs to be more interactive.
Step 2: Server Side HTML + Client Side React SPA
-> Website is now interactive but performance decreased.
Step 3: Server Side HTML + Server Side React + Client Side React SPA
-> Website is interactive, performance is good but now it's overly complex.
Step 4: Server Side HTML + Server Side React
-> Let's make it a bit more simple and even more performant by making it less interactive again.
Step 5: Server Side HTML
-> More performant than the previous iteration, also less complex.
You can see that nothing really changed but developers are super happy because they improved the experience all the time.
- Server-side rendering is actually fantastic. It's fast for users and there's no sluggish build step holding you back.
- Turbolinks covers 70% of the interactivity you need.
- Alpine.js covers another 20%.
- With Rails having webpack built in, there's no friction to writing/importing your super-fancy JS interaction for that last 10% when you need to.
Rails gets it right. It truly makes your dev life better, in ways that actually matter. Back then I was convinced Rails led to spaghetti code, but in hindsight I just needed to improve as a software developer.
10 years later, there still isn't a better tool than Rails for tech founders. There are some promising ones, but none that get you launched nearly as quickly. It's kind of annoying, to be honest. Is this that hard of a problem?
Step 3 is where projects end up when they grow sufficiently in complexity and/or features (React specifically is not a necessity but a good solution).
The problems that are being looked at by many of these frameworks, are pushed by the need of being able to use the same rendering and logic, tooling, language and so on for different stages of complexity/requirements.
These are real issues that people worry about and try to find solutions for. On the grand scheme of things these developments are about reducing pain and cost, while keeping up with or driving advancements in user (read: client) expectations.
Nah, you've started with a good framework focused on querying data and rendering them, and finished with one focused on async network IO and live-updating an interface.
I see them as options, not steps, options within the same ecosystem
A lot changed, but the limitation is still the same - the delivery platform - browser (dom + js)
And less interactive.
What is the definition of interactive?
Particularly static pages with minimal interactivity can be prerendered and cached at the CDN, but that’s not necessarily the same as an on demand server side rendered page, either.
But since you don't need the client, you don't need any of that, right? Seems like without having to structure the server code in the same way you'd structure client code, things just get a lot simpler and the native React SSR stuff should be fine to use directly. Just curious which other features of Next you found you wanted for a server-only app?
I actually thought it might have something to do with data loading, so it was a slightly leading question as I'm very interested in that stuff - I have a library react-frontload [0] that does client & server data loading that could feasibly be used in a server-only context, and am always looking for ideas on different usecases etc.
Ah yes, there are some interesting new frameworks built around this concept. PHP.js comes to mind.
> yes this is experimental and not something I would generally advise.
I know what you mean, but it is still funny, given how long this was the way nearly 100% of web development was done for about 15 years.
You get the speed/reliability of Phoenix and the (for me at least) power of creating your UI in React without having to run a node server at runtime. I'm planning on releasing the plugin once I've used it on a couple of personal projects to remove the rough edges.
Phoenix Live View is cool and all, but still not stable enough for my liking. Also, depending on the use case, it can be unviable.
I have it working with a sample page that renders three dates (static webpack render date, phoenix render date and current date that updates each second with a timer) but I think I need to try it on a real page with real data.
It doesnt have everything built-in, and the fact that Zeit has such tight control over nextjs to be a minus...but im expecting Next (and Gatsby) to some extent to drive full stack webplatforms for the next decade.
You have to write javascript anyway in Rails...why not go JS all the way ? And Typescript is definitely a fantastic language.
It is worth looking into their discussions, issues and so on, doing the tutorial and looking at the roadmap if you are interested in this kind of thing. Very opinionated and they embrace a component based approach with React, GraphQL and so on, while providing useful code generation.
Also this CMS project does a lot of things really well too:
Also pretty young but at a stage where you can use it for real things. Also code generation, GraphQL support and very modular.
But if we're pragmatic, there is still nothing that beats shared hosting LAMP stacks currently if you need a CMS and/or custom backend for a web-app in terms of operational overhead and cost. And it is not like the PHP community was sleeping either. For Rails specifically: It introduced a paradigm shift but both the Python and PHP world caught up very quickly. I don't see a big enough benefit of using either of those three except for the lower operational cost of PHP.
So I agree with your prediction, but we are not quite there yet, or at least not for small to medium projects.
I used a more heavy-handed approach: I strip out all <script> elements from the build output before publishing: https://gitlab.com/nfriend/nuxt-resume/-/blob/63e0298fdb5a08...
The end result is a pure HTML/CSS site that has all the Nuxt.js niceties during development (e.g. hot reloading).
https://github.com/blitz-js/blitz
RedwoodJS, a new rails like full stack framework for JS is also very interesting: https://github.com/redwoodjs/redwood
They focus on a classic server side Rails like workflow but embrace the separation of API and clients on the technical side, for a future as a multi frontend framework (web, mobile etc.).
Most “standard” template languages default missing variable references to empty values and would only throw an error due to dereferencing an empty value. This would catch all those errors in advance at compile time.
At times like this is when I most think of Svelte’s aspiration, to remove the framework and compile its uses to regular DOM calls. It just bothers me so much with their magic syntax.
PS: Maybe something similar could be made for React Hooks? If a component doesn’t use any hooks it’s marked as static and doesn’t need the framework or to be re-hydrated. If it uses any, we only need to create a discrete React root for that component and its children.
Why do people not know about Eleventy, why?
Server-side-only React sounds like a fundamental misunderstanding of what purpose React actually serves.
In React, you write functions that accept data and output what amounts to HTML. Thing is, you can easily do this with a plain template string. You're just dropping values into HTML. The only benefit provided by React is the efficient modification of existing DOM to bring it up to date with the new state, without dropping the whole thing and rebuilding it from scratch. If there is no existing DOM - because you're only making one rendering pass - React serves no purpose at all.
Here's my website. It uses virtually nothing except Express and a Markdown parser. Pages and components are rendered from plain JavaScript functions. Blog posts are in markdown and automatically detected. Right now it statically renders all of the pages on startup, for efficiency, but it could be made dynamically-rendered with a flip of a switch: https://github.com/brundonsmith/website
Related – If anyone wants to learn more about Next.js, my course is free right now while everyone's stuck indoors.
I get that as an educational experience this is interesting, but the level of complexity required to generate static html is extraordinary. Just the amount of tooling and conceptual understanding necessary is so crazy.
I've been working on building out a simple Electron app recently and considered React, but realized with little to no interactivity it would be insane overkill. However, one of the most popular boilerplates out there combines react, redux, typescript, webpack, etc, etc.
There seems to be this default right now of 'over-engineering' everything. It's like people have forgotten how to make simple things.
For a blog or mostly static webpage? SSR is probably the better choice. But there are many times where serving a minified React bundle to the client and letting it do all of the rendering work is better. It's actually a much lower strain on your server, because all you're doing is serving static files from behind a proxy like Nginx, whereas with NextJS your server incurs significant performance overhead from having to evaluate each page view in JS. Imagine this for a million visitors at once when you have content that cannot be statically cached.
Because this triggers me a lot. Why wouldn't you just use a normal templating language that render html? Isn't this seriously all the same except you just add a massive dependency for no reason? This is why I hate the javascript community.
The only word I find for this is that this is dumb.
"I needed something to convert markdown to html", "I like the component mental model", "I wanted to use Node libraries for date formatting etc.", "Next has a great developer experience"
None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".
For years, I was telling people that React and related tooling was a bad idea, that it adds a lot of unnecessary bloat which is not worth it. Everyone (like 99% of developers) disagreed with me and kept insisting that it was a simple solution.
Fast forward half a decade, now pretty much everyone agrees that React adds a lot of unnecessary bloat... The level of bloat just had to get truly appalling for people to actually notice (I swear a lot of projects seem to take 10 minutes to build). It took 5 years for people to accept the PREMISE of my original argument.
But now even though a lot of people finally accept the premise, they are still desperately trying to rationalize the existence of their favorite hyped up tools in any way they can.
I'm tired of explaining to people that "simpler solutions are better than complex ones". If any idea should be recited dogmatically, that should be it. Someone should write a book about it so that people can repeatedly whack themselves over the head with it until it gets through their thick primal skulls.
You aren't the first person (or the last) to care about payload size to the browser. Everyone cares about that, including the React core team.
I don't doubt React's effectiveness as an economic tool for job creation. No economic tool is able to turn a simple 1-person job into a complex 100-person job as effectively React does. The Federal Reserve Bank loves React.
But is it the most effective tool for writing web apps? Not by a long shot.
Everything is a tradeoff. React adds bloat but simplifies development. If any idea should be recited dogmatically it should be "software development is too complicated to live by blanket statements".
Solutions do have tradeoffs, but if I tell you that breathing is important, we don't really need to discuss tradeoffs...
Simplicity is that important.
I'm getting more this way every year and I've been coding for over 15 years. I'm yet to find the bottom in terms of how simple things should be; things can almost always be made simpler and simplifying things as much as possible nearly always pays off (except if you get paid hourly and care more about salary).
Maybe just a bit of Babylonian language confusion. Static, to dynamic, to server-side-dynamic-vs-client-side-dynamic...
But cheers, I'll check it out some more.
"I'm using x technology because I'm familiar with it" is exactly what most people should be doing. Many people try to create production sites with tooling they're not familiar with, or take too long learning something new.
Why do none of these justify using React? They probably care about different things than you do.
Not necessarily, there are multiple tools in the world and not without reason - almost all of them were created with specific purpose. One can be very familiar and skilled with using hammer but it doesn't mean that it will be efficient to cut a slice of bread with it.
For software tools makers it is very tempting to try to make it versatile enough to be able to use it for every possible case, however this is not possible and never will be without sacrifices - and most frequently speed, clarity and ease of use is sacrificed first - there are multiple examples of this: jira, gitlab, facebook, clickup. Complexity, bloat and cognitive load is growing, users are starting to have difficulties to grasp all options and possibilities - and boom suddenly from most loved to most hated.
Why would the author prefer unfamiliar tools in favor of tools they are productive with that produce the same output?
What's your preferred alternative, pray tell?
It takes a lot of effort to figure out how to use VueJS without the bundling step and it can feel constraining initially, but the simplicity pays off in the long term.
I'm quite annoyed though that VueJS team has been moving towards TypeScript and bundling. Am I the only person who thinks that front end work is too simple to need type safety?
Front end programming is like riding a bike, after a while, you don't need the training wheels anymore; they just slow you down and deprive you of real enjoyment.
Also, there is a joke my colleagues used to say about front end:
"Front end work is like building a house of cards. If it collapses, no one gets hurt. On the other hand, back end work is like building a house out of wine glasses..."
Anyways, your disdain for front-end development will probably preclude a lot of people from taking your stance seriously.