Hacker News Reader

Comment by sdevonoes | Hacker News Reader

I get the appealing of SSR with frameworks like Next.js (e.g., you get to develop frontend components using React, which is nice). So, my question, for the ones who know, would be: if in the following years a new generic (backend) programming language emerges that allows building frontend components in the backend (think of PHP + Html, but better; or think of Golang templates but better) as easy as it is to build components using React, then that would mean we wouldn't need anymore a myriad of different technologies: a frontend library (React), a frontend framework (Next.js) a middleware (Apollo), and a backend api (let's say Python/Go/PHP/whatever). We would only need one technology: the new generic (backend) programming language in which you can build frontend components and write business logic as well. We would be back to the 90s (think PHP + Html, but better).

View on HN

The eventual linchpin is roundtrip latency. If you want to have a frontend with native level responsiveness, you simply can not move all logic to the sever. Physics will get in your way.

So any universal solution will have to include strong client side prediction in addition to handling the server (something the game industry has understood and implemented for years, and I remain confused as to why it has gained near 0 traction on the web).

To my knowledge Meteor is still the only frameworks to explore down this path, but it has never really caught on. Does anyone know of any frameworks that acknowledge this issue and manage both server and client side accordingly?

The game industry and the web industry are so closely tied together in terms of their core working model and architecture. It really is strange that there hasn't been much in the way of cross-domain inspiration or knowledge sharing.

Relay has very good support for optimistic updates on the client.

When developing an app recently I added an artificial 1s delay to server responses (during development), but because of optimistic updates you would never notice it was there.

Interesting. I am still very much hoping for a framework to tie it all together but in the meanwhile I'll have a look at this — thanks!

To expand on that, CSR doesn't automagically save you from round-trips. It enables you to be agnostic where your data structure is built, but there are a lot of cases where you need to do that on the server anyway.

Then there is caching, if your stack is well-integrated and aware of mutations you can respond with 304, or you can intercept requests with serviceWorkers, or edge/cloud workers/functions etc. AKA speed of light or practically instant responses.

HN doesn't talk about it often but PHP is still the workhorse of the web. And that is for good reason. It's fast, stateless, easy to use and not just batteries included, you also get the charger, the repair kit, repair parts and adapters for seemingly every use case.

That said, it's clunky in many ways and (very) slowly losing it's dominance. It's community clings on class based, mutable OO (while even languages like Java expand in other directions). And there are thousands of little gotchas, weirdness-es and limitations that make using the language un-fun and sometimes unproductive/limiting. For newcomers it is a nightmare to fall into all these traps for the first time.

A true PHP competitor however would need to be incredibly accessible and re-imagine a lot of things. I think it would need to fully embrace modern HTTP, HTML, CSS and browser APIs. Deno is seems to partially lean on that direction for example, but that is "just" the server side so it doesn't count. Isomorphic development is a big deal. There is Imba which is also an interesting attempt. Modern languages like Clojure and Kotlin provide the capabilities but not the development accessibility and defaults (personally a huge Clojure fan though).

> and (very) slowly losing it's dominance

Is it losing dominance?

https://arstechnica.com/gadgets/2021/09/php-maintains-an-eno...

Haven't seen those numbers yet thank you. I was basing the above more on tiobe index, google trends and gauging the frontier of web development, which includes tooling, modern libraries.

Much of the effort in the latter part, innovation, products, tooling and marketing at the web frontier seems to more strongly focus on JS/TS/Node/V8/serverless/WASM. When I started with web dev, PHP was the de-facto standard language for small web-shops (Ruby was on the rise, Node on the horizon). I don't think that is true for the next generation of web developers.

What did Java move to exactly?

There have been more constructs that are leaner and less traditional class based OO since a while, such as lamdas, records, more expressions, higher order functions.

The Phoenix framework for Elixir supports something like that with its "LiveViews".

A few other backend frameworks for other languages also have something like that.

LiveView is, unfortunately, somewhat of a footgun. The idea is super neat and works great on localhost -- but then somebody clicks a dropdown with a dynamically rendered list of whatever in production and has to wait half a second for a piece of UI to appear, and that's really bad.

+1 for Phoenix LiveViews.

The Nitrogen Framework for Erlang [0] is another in a similar vein (and pre-dates LiveViews).

Another is lamdera [1] which I came across on the Elm Radio podcast [2]. I've never used it, but the focus on minimising accidental complexity between front and back end was appealing, (along with the use of Elm).

[0] https://nitrogenproject.com/

[1] https://lamdera.com

[2] https://elm-radio.com/episode/lamdera/

You already have that: JavaScript.

Otherwise, what you are describing isn't going to be "Just Go" or "Just the language"... you'll have again a ton of libraries/frameworks on top of it... the complexity is going to be there... one way or another.

I strongly believe Blazor is going to rule that market in couple of years. Single language C# will be good enough to do both backend and frontend.

I had great experience with Lona framework [0], for smaller projects; You do everything in Python, and have a representation of your UI as a set of python objects. Then changes in python objects are propagated back to web.

- [0] https://github.com/lona-web-org/lona

To some extent, you can do what you’re talking about with Rails using ViewComponent and Stimulus. ViewComponent allows you to write reusable components in Rails. I’m using it in a project and it’s nice, but not perfect.

Well, you only need to use Node now if you want a single language (+ optionally Next, which runs on node/express and will make your UI development much smoother if it's anything beyond super basic).

CMIIW that's what asp.net webform try to tackle. And it failed miserably.

IMO, having the ability to separate presentation with backend is valuable.

Reply on news.ycombinator.com