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

Practical Front-End Architecture

jaredgorski.org

Post reply on HN
Print view View original

11–20 of 164 posts

Re: Practical Front-End Architecture

#11

Post by dgb23 »

d3nj4l wrote: post #2

I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…

> (Like in this article - I wonder why they chose Next since they're blocking out SSR entirely)

They provided a bit of rationale (kind of sprinkled across the article).

For me using Next over CRA as a default comes down to three things:

- Batteries included, high utility components and defaults for things you ought to stitch together otherwise. CRA is not a drop-in replacement for Next, even if you only render client side.

- Flexibility. Your project might just look mostly static (fully rendered at build time) , or server rendered, or client side rendered. It rarely is. If you default to Next you can easily extend and configure these capabilities (and more).

- Great DX. It's a framework that respects developers with good documentation, flexibility and a "just JS/React" kind of philosophy. There is magic that you cannot easily break through as with every framework, but so far it seems they keep the magic boundary at the right place.

Re: Practical Front-End Architecture

#12

Post by qw »

blunte wrote: post #10
sgdesign wrote: post #4

I think this article shows how far we still have to go. Things like SSR with Apollo (or some other data layer) should be a solved problem by now, and not require every developer to ask themselves these questions again and again. Thankfully I think the next.js team has been doing really great work in that area so I’m hopeful for the next couple years.

> should be a solved problem by now, and not require every developer to ask themselves these questions again and again This applies to so very much of web developement. We have spent so much collective time building web apps, and some have also put a lot of time into building libraries and frameworks, that with all the brainpower and effort, things should be easier now than they are. I believe this is because we've h…

One of the benefits of Wordpress is that it runs on PHP. It's very easy to find a cheap web host and just copy the files over. Many web hosts even have a simple button that sets it up for you.

A viable alternative would need to be just as simple, and currently that implies it should probably be implemented in PHP, which will exclude developers who want experience with "blog-friendly" languages.

Re: Practical Front-End Architecture

#13

Post by dgb23 »

jstummbillig wrote: post #8
sdevonoes wrote: post #5

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 com…

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…

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.

Re: Practical Front-End Architecture

#14

Post by spinningslate »

r6203 wrote: post #6
sdevonoes wrote: post #5

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 com…

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.

+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/

Re: Practical Front-End Architecture

#15

Post by jstummbillig »

r6203 wrote: post #6
sdevonoes wrote: post #5

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 com…

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.

Re: Practical Front-End Architecture

#16

Post by [deleted] »

sdevonoes wrote: post #5

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 com…

[deleted]

Re: Practical Front-End Architecture

#17

Post by fendy3002 »

sdevonoes wrote: post #5

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 com…

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.

Re: Practical Front-End Architecture

#18

Post by korantu »

sdevonoes wrote: post #5

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 com…

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

Re: Practical Front-End Architecture

#20

Post by dgb23 »

sdevonoes wrote: post #5

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 com…

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).

Post reply on HN