Hacker News new | past | comments | ask | show | jobs | submit login

This is so overdue. I'm ecstatic to see this finally happening. The frontend framework bloat trend honestly went on ten years too long. It was like the thin client and thick client debate turned into the thick client and thicker client debate.

People will roll a gigantic create-react-app mess for the tiniest of frontend projects. Yes, it's an instant codebase! But that's all code you have to maintain. Stuff like hotwire and htmx can't come fast enough.




This isn't the only one... JS frontend world as a whole has been moving back to SSR for the last 5yrs. But importantly while still maintaining the benefits of desktop-style interactivity, instant page transitions, componentized code organization, treeshaking/ + lots of small JS/CSS files only loading what's needed vs one massive asset, cached/offline friendly JSON data streams, etc, etc.

It is still SSR but it's much much more than just going back to 2005. Combining the lessons of the last 15yrs with the as much of the past SSR world as possible. It's not simply throwing it away and regressing to the old ways.


The project is originally from 2014 and the presentation seems to be from 2016.


Hence the 'finally'!


I don’t see the difference. Isn’t backend code code you have to maintain too?


Yeah it's gonna be somewhere. I guess it's really about the sweet spot that minimizes the complexity on both sides. This captured it: https://imgur.com/a/mx7Y0uD


You need a backend anyways. Shifting to a server-side codebase is eliminating duplication, and arguably server languages have better DX so win win.


That might sound convincing to someone who already prefers working on the backend, but you can basically invert your statement to describe a typical serverless setup: “You need a frontend anyways. Shifting to a client-side codebase is eliminating duplication, and arguably browsers have better DX so win win.”


You still have to connect with data somewhere which often means running an api server connecting to database. There's certainly options to outsource this to managed services, but "serverless" and distributed systems can often be "more complexity" unnecessarily, without any corresponding productivity or functionality gain.

There's a clear trend back to the server to some degree, so on the margin what I'm saying seems to have some basis in many people's experience, where the sweet spot of many apps does not require the added complexity of SPA's or lack of expressiveness of writing so much app code in javascript, building distributed systems, or having to use Firebase style non-relational database services. Moving much of this to the server reduces some of this complexity often with productivity gains.


> or lack of expressiveness of writing so much app code in javascript,

???

Modern SPAs are typically written in TypeScript which is very expressive and using frameworks to structure them.

One may like or not like the tooling around it, but the language and code is just as robust and clean as any backend code.


Most backend developers are used to maintaining high quality codebases, however. On the other hand...


Uhh. Cheap shot, very constructive…


Additionally, you as the developer have full control over the backend environment which isn't true of the front end.

That reason alone is why I prefer having the server doing the bulk of the heavy lifting. It reduces variables in the most functional parts of the app and reduces my need to try to herd users into using particular browsers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: