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

31–40 of 164 posts

Re: Practical Front-End Architecture

#31

Post by d3nj4l »

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…

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.

Re: Practical Front-End Architecture

#32

Post by prakis »

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

Re: Practical Front-End Architecture

#33

Post by toastercat »

Hey all, as someone ignorant to this whole SSR/Next.js stuff: I understand that Next.js is particularly popular for creating landing pages that require strong SEO. What I don't understand is, in what way is it better than say, using something like HUGO or Jekyll? If you require some dynamic content, wouldn't it be easier (and faster to build) to use a SSG and ship the JS along with all the other static assets? What am I missing here? Thanks.

Re: Practical Front-End Architecture

#35

Post by tenaciousDaniel »

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…

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.

Re: Practical Front-End Architecture

#36

Post by cjonas »

This article is great timing. I'm working on a "next gen" FE app and it validates most my decisions.

Only real difference in my stack is I'm using redux toolkit query to connect with a Rest API instead of GraphQL (GQL would be nice, but can't have it all).

I'm a HUGE fan of antd! I've been working with it since like 2017 and it blows my mind what I can build in a few hours.

I haven't used tailwind, but wanting to look into it. Anyone have practical advise for using tailwind alongside a component library like antd?

Re: Practical Front-End Architecture

#37

Post by BigJono »

> 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 clusterfuck about integration between Next and Apollo. How many brain cells did your team kill figuring that one out just to decide on client side rendering?

I've been using React and webpack for 6 years now, and interfacing with Rest APIs dependency-free using the standard library for at least as long as fetch has been around. All the commenters here are musing about how back end is so solved and front-end is a mess then lauding OP for posting about his "practical" stack at the same time?

This stuff is literally the entire reason front end sucks. Front end has been solved for ages with a couple of simple dependencies and all anyone wants to do is write blogs about over overengineered and/or VC funded fadtech because they're terrified of having to write a few lines of simple code.

It's not normal to just randomly spend a year "upgrading" to stuff that's barely been popular longer than that. I've been on projects that do just that, then on the next project we'll build a much bigger app from scratch in 3 months with 1/3rd of the team size.

Re: Practical Front-End Architecture

#38

Post by newshorts »

ilkkal wrote: 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.

Me too. This regularly reminds me that some folks don’t have full stack experience and are coming from a completely different background. I am subsequently much more deliberate in describing architecture these days to front end devs.

Re: Practical Front-End Architecture

#39

Post by jrochkind1 »

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…

Same spot as you. If you find any front-end "standard" that doesn't seem "way too complicated for things I would consider a JS-heavy SPA for", let us know! I think maybe it's just... unavoidably complicated. At least any present options are, which probably means it's hard to make one that's not or someone would have done it, right?

Re: Practical Front-End Architecture

#40

Post by newshorts »

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 to know about addEventListener?

Post reply on HN