Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

Post reply on HN
Print view View original

301–310 of 395 posts

Re: The absurd complexity of server-side rendering

#301

Post by isaacimagine »

christophilus wrote: post #274
jwr wrote: post #269

I've been using server-side rendering for many years now and I find it to be almost zero overhead at this point. Yes, I had to do some initial work to set things up, but these days I don't even remember it's there. Most people make an assumption that in order to have SSR you need to run JavaScript (e.g. Node most of the time) on your backend. That is not a valid assumption. I think the title of the article could bene…

This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever. I wish there were more stacks like Clojure/Script. While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies. Does anyone know w…

It's still a long way from being complete, but I'm working on something like that[0]. Eventual plans are to have good Rust library interop (e.g. bindings to hyper for http) while also being able to compile to Wasm (to run on an erlang-style distributed runtime / the browser). The language is currently interpreted, but one I get typechecking working, I should be able to merge in the Wasm codegen backend I'm working on (with eventual plans for LLVM). Current compiler has zero external dependencies.

Language itself could be described as a mix of OCaml, Scheme, and Lua. Currently working on the hygienic procedural macro system and system injection through algebraic effects.

[0]: https://github.com/vrtbl/passerine

Re: The absurd complexity of server-side rendering

#302

Post by ehnto »

rawoke083600 wrote: post #264
ehnto wrote: post #262

Earlier quoted context omitted.

> SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized. This is the only realistic reason I have seen to be honest. Isomorphism is a tool that you use to achieve a statically rendered site that you can give to Google, that will then become highl…

>SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized. SEO aside(that is another discussion), but Google "requiring" your site to be fast is a net positive for consumers/us !

It has been of benefit I will admit, but I think for SSR in particular it can make things worse since you wait until a user interacts to spin up the application so to speak. But like anything, you can do this well with enough care.

Re: The absurd complexity of server-side rendering

#303

Post by G4BB3R »

christophilus wrote: post #274
jwr wrote: post #269

I've been using server-side rendering for many years now and I find it to be almost zero overhead at this point. Yes, I had to do some initial work to set things up, but these days I don't even remember it's there. Most people make an assumption that in order to have SSR you need to run JavaScript (e.g. Node most of the time) on your backend. That is not a valid assumption. I think the title of the article could bene…

This is a really nice combo, I agree. But… I think it’s safe to say it’ll probably remain niche forever. I wish there were more stacks like Clojure/Script. While I’m wishing, I’d love to have a modern ML with simple tooling, a good stdlib like Go (with a high performance http server baked in), and a good full stack story that doesn’t produce a 1MB “hello world”, and doesn’t require 1K dependencies. Does anyone know w…

For the next year(s), take a look at Roc (https://roc-lang.org). It is being developed by some folks from the Elm community, but it's focused on backend/CLI.

Re: The absurd complexity of server-side rendering

#304

Post by cersa8 »

marcus_cemes wrote: post #281
cersa8 wrote: post #271

Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state ma…

It's easy to server-side render Next.js apps, but usually they still have to talk to a backend. I don't think Next.js' API routes are good for this, especially if you need messages queues, cron jobs, etc. Now you have three distinct parts, client-side rendering, server-side rendering and the API, usually all communicating via JSON. Traditionaly with PHP, C#, Ruby, Elixir, etc, your backend and frontend was tightly co…

"Limiting the backend stack to what browsers support is not great" Node.js shares the same language but that's about it. In the Node.js backend you have access to modules like lovell/sharp with optimized c code (libvips) for image processing. There really isn't much you can't do. With pm2 it is easy to spin up say 8 instances of Next.js utilizing all available cores. In my experience there is barely a distinction between client and server side rendered components. getServerSideProps() or getInitialProps(), even though not perfect allow you to either call your backend code directly or call an API with the session cookie as a parameter.

Re: The absurd complexity of server-side rendering

#305

Post by tored »

dgb23 wrote: post #298
tored wrote: post #263

Except for the confusion about terminology the article has some good points. We had an idea a long time ago in the web dev world that we could run the same language in the browser and in the backend. Basically reuse everything and save time. It think this is bad assumption to begin with. If I have a clean separation between frontend and backend, regardless if doing mostly server rendering or client rendering it is on…

That has not been my experience. Input validation or more broadly data integrity is just the first, obvious issue. There are things that can help with that like json-schema, openapi, graphql and so on, which solve some part of this at some level. Let's go for json-schema, which is the simple, focused data driven and pretty well designed. Great isn't it? But it doesn't stop there. You now have at least two libraries i…

Most of these problems stems from moving too much to frontend, making the frontend tilt over. If you keep more logic in the backend much of these problems goes away.

Problem is that for every core concept moved to the frontend it still needs to exist in the backend, a representation of an article needs to exist both in the frontend and the backend, same for error handling, logging, authentication etc, but they are rarely identical, even if you would code them in the same language, because the frontend will always be a remote representation of what the backends implements. Thus the more you move the more you need to duplicate.

Some views or components needs to be more interactive, true, but not every view, thus you solve the interactive part of those specific views or components in pragmatic way to minimize friction.

One pragmatic solution is to use BFF, backend for frontends, where you have a specific API, both for reading and writing, for that component or view only. Now you can adapt those together to a better fit, including error handling.

General and reusable (REST) APIs for driving a frontend is a bad idea, you should have specific APIs for each case, otherwise you end up doing asynchronous JOINS over HTTP.

The next step to realize after that is that if you already have specific APIs for a components you can skip passing JSON all together and just return HTML, thus saving an entire JSON encode/decode roundtrip.

JSON schema is trash btw, schemas does not fit JSON data well, structured data is better handled by something like XML. And what this shows is that using JSON for large data representation is a bad idea, but it is usually where you end up when doing heavy frontend.

Re: The absurd complexity of server-side rendering

#306

Post by fuzzy2 »

pjmlp wrote: post #294
fuzzy2 wrote: post #255

Earlier quoted context omitted.

IMHO, this isn’t about “Modern JavaScript” or “JavaScript Culture” at all. It’s just $CURRENT_THING and the Cargo Cult is happy to oblige. Futhermore, dev shops (like my employer) profit from selling overcomplicated solutions. So in the end it’s just group dynamics that drive the usual hype cycle. Remember MVVM?

MVVM is pretty much alive in native frameworks, as it makes easy to write tests and share behaviours.

I’m not saying it’s bad. You just have to know when to use it. But that’s how it is with any technology/library/framework/whatever.

IIRC there was a “MVVM craze” back then, but that could’ve been my bubble.

Re: The absurd complexity of server-side rendering

#307

Post by tored »

slim wrote: post #227
astrange wrote: post #108

Earlier quoted context omitted.

PHP itself is perfectly designed to run CGI scripts and the correct architecture for web performance (shared-nothing). It's the third party developers that have second-system effect enterprise dreams. Though maybe some of them have found simplicity again.

you're right. it was obvious when we started seeing templating engines for php while php is itself a templating engine

Only thing missing from PHP now is to programmatically detect tainted strings, i.e. strings that are dangerous like user input, if we had that we could continue with the built in templating and still be sure to escape output at the correct moment.

Tainted strings should be built into PHP (there was an RFC for it but it didn't pass). Another solution could be using operator overloading instead (that RFC didn't pass either).

Re: The absurd complexity of server-side rendering

#308

Post by ryanbrunner »

franze wrote: post #279

I make a difference between website and webapp. a website is a collection of webpages, where the maingoal is to display some mostly static information (i.e. an article) a webapp has the main goal of managing and reacting to a complex, non trivial user state. website, go server side all in, do not add the tax of client side rendering / hydration to the frontend. if necessary embed small enclosed client side webapps on…

What's Amazon in this example? Hacker News? Google Search? All of these are problems that are still perfectly well suited to server-side HTML generation - the dominant user interaction replaces all / a significant part of the page, with relatively minimal non-database state preserved between interactions (a cart for amazon, your user name, your search term). All of that can be built perfectly simply by a traditional request-response cycle with some Javascript enhancement.

Going SPA for most "webapps" (if app is defined as something that isn't purely static) is a massive waste of time. Use Javascript on the few items that require more interactively, but if most of the time major interactions are replacing > 50% of the UI, a SPA isn't buying you anything.

Re: The absurd complexity of server-side rendering

#309

Post by epolanski »

Widdershin wrote: post #270
epolanski wrote: post #237

Earlier quoted context omitted.

Which, again, has very little to do with any of the gist.

Hiya, I wrote this gist. I do actually think Monads or similarly expressive type constructs would allow us to eliminate this class of issue for good. Hopefully the rise of Wasm makes this problem irrelevant for functional programmers, but that’s a whole other can of worms. That said, it’s probably impractical to try and achieve that sort of type safety in JS via the Monad route, but maybe a clever TypeScript extensio…

Monads are just type constructors with two operations: bind and pure. I fail to see the connection and why do you need a type constructor with a bind and pure operation at all to solve SSR.

Re: The absurd complexity of server-side rendering

#310

Post by noduerme »

nickcox wrote: post #211
noduerme wrote: post #197

Earlier quoted context omitted.

Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React that would automate the Dom update and bind the Dom more closely to the data state on the server. After many years, front end programmers forgot how to build…

> Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React I think you skipped a few years there! AJAX, Mootools, prototype, JQuery, etc.

Totally ;) Between the first and second sentence. I'm still writing a lot of software in that paradigm. Basic AJAX, with nice typescript. JQuery (still super useful for having its own event loop). Underscore JS. Bit of PixiJS to replace the Flash I lost when I need something in canvas. Here's what I won't do:

* Move any logic into HTML files

* Use any nonstandard tags or inline any code to hook frameworks

* Use any frameworks that modify the dom on the fly in any way I'm not 100% in control of.

[edit] Here's what I do: Write all data types front/back in NodeJS now, or maintain a 1:1 datatype where PHP is involved that's a perfect mirror of the database table structure; strongly type everything coming in from DB calls before it hits the front end, including types that need to be dehydrated; make outbound objects rewritable to the DB and cached for writing until the time is right, depending on load; maintain high readability without forcing the backend to choke on every single long poler's data update.

But hey, take 20 years worth of kids and put them through the same academies and job interviews, eventually they'll be great at answering questions about React and suck at writing useful code.

Post reply on HN