Live data from Hacker News

Practical Front-End Architecture

jaredgorski.org

41–50 of 164 posts

Re: Practical Front-End Architecture

#41
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…

Can I say an aside, it's refreshing to hear a backend developer talk about frontend as an equal partner in the picture, rather than disparaging it? A lot of HN is quite anti-frontend, especially when it involves abstractions like React or even languages like JavaScript. It's great that backend devs are looking into our side of the fence and talking about rational pros and cons.

In fact I’d say part of the problem with the front end ecosystem has been people trying to get by with shallow knowledge. Building a SPA (as opposed to a web page) is a technical and challenging problem. It’s people who blow that off who, for example, adopt Redux without understanding if they need it and then complain about the complexity in their codebase.

Re: Practical Front-End Architecture

#42
post #37

> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of cl…

I was excited about this post, saw the stack, and noped out of there. I was hoping for a really simple approach but this ain’t it.

Re: Practical Front-End Architecture

#45
> Likewise, don't choose server-side rendering just because it's buzzy and sounds powerful. Server-side rendering does basically the same job as client-side rendering: generating HTML.

Well not quite. With client side rendering you now have manage state in the browser as well as build API end points for each screen you want to create.

It's a more complicated architecture.

Re: Practical Front-End Architecture

#46
post #20

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…

> and (very) slowly losing it's dominance

Is it losing dominance?

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

Re: Practical Front-End Architecture

#48
post #29

Got a big chuckle out of them describing server-side rendering as this new-fangled unproven technical risk of a technology :) I get the context, but it was still funny. Ah, back to editing index.php I guess.

Because your index.php did not need to dehydrate and hydrate.

Back in the days the apps were unresponsive, clumsy and user unfriendly.

You really can't compare web apps with old websites or even forum software like phpbb.

EDIT: The down vote of the PHP developer which still wants to write phpBB forum websites :)

Good luck with that. I'm waiting for the article that complains about frontend development ;)

Re: Practical Front-End Architecture

#49
post #30

maybe a bit off topic but i'm still on the fence if front end will ever be "solved". The difference is that backend is always going to be some variation of CRUD, so the architecture isn't changing too much. front end being the actual user-facing layer means it will always evolve with human-computer interface (UX?). Mobile phones completely changed the way we thought about frontend, and it's just time until the next b…

I’d say backend architecture is also changing. React is older than Kubernetes.

I do get your point though that UI dev probably sees more variation since you need to adapt to the form factor of the user’s device, which changes significantly every few years.

Re: Practical Front-End Architecture

#50

Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day. I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion. Maybe I’m too old for this game and front end devs will never again need…

Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"
Post reply on HN