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

61–70 of 164 posts

Re: Practical Front-End Architecture

#61

Post by rattray »

yashap wrote: post #52
BigJono wrote: 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…

Agreed. Having worked extensively with GraphQL, I’ve come to see it as a MASSIVE source of unnecessary complexity in almost all cases. Haven’t worked with Next.js, but using an SSR framework, then not using SSR, seems like a tonne of unnecessary complexity too. They even say: > At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful…

How do you keep your openapi spec up to date?

Re: Practical Front-End Architecture

#62

Post by andrewingram »

Not planning on getting dragged into a debate about whether GraphQL is a good tech choice here (even though I won't pretend i'm not a massive fanboy). But the "with-apollo" Next.js example used as a reference (and then decried as being a bad experience and unscalable), is a pretty bad representation of how it can feel to use GraphQL with Next.js.

I've never used Apollo in anger, but i've used Relay with Next.js for a few projects and it's been a dream. The biggest downside has been the size overhead of the Relay client itself (approx 40kb over the network), and the size of the serialized data (but that's the same price you'd be paying whether you were using GraphQL or not, just an unfortunate reality of the hydration model).

Re: Practical Front-End Architecture

#63

Post by mdtusz »

pc86 wrote: post #28
ehnto wrote: post #24

Earlier quoted context omitted.

I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. When I learned about OOP I was able to understand OOP code in a broad range of applications, languages and frameworks, but learning how react works gives me no insight into anything but react, and it's even abstract…

> they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. This is sort of an expected side effect of recreating nearly-identical JS frameworks every couple months, no?

I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times just curiosity).

Considering you have so few language options for frontend webapp development (excluding wasm and other such options), this really isn't a surprise to have a handful of options either. I can name more python server frameworks that are used in earnest than I can name frontend frameworks.

Part of the difference for frontend frameworks is that there's so much variety possible. Nearly every server framework has the same general design and API - some kind of routing, route handler definitions, and some additional niceties like with, db connection handling, sessions etc. I can't conceive of any other design that would work better or even be sensible.

While components have become the norm in front-end, there's still plenty of room for different architecture and actual API to use and define components, and manage state. That's where the fun of writing them comes in, and where there is still likely a better react or vue lurking in the shadows or yet to be created.

Re: Practical Front-End Architecture

#64

Post by jaredgorski »

ehnto wrote: post #24
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…

I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. When I learned about OOP I was able to understand OOP code in a broad range of applications, languages and frameworks, but learning how react works gives me no insight into anything but react, and it's even abstract…

Absolutely.

The trends and gimmicks have caused this “walled garden” effect. It’s made both “practical frontend engineers” and “practical frontend architecture” a rarity. If I could write this post again, I’d talk more about how most use-cases simply don’t need a “modern tech stack”.

React is basically a glorified templating engine that attempts to enable reactive mechanisms on the client. Need “reactive”? Consider Svelte as well. Don’t need it? Consider moving the render to the build and use a lighter templating engine.

Re: Practical Front-End Architecture

#65

Post by andrewingram »

nprz wrote: post #43

I haven't spent much time with Next.js, but luckily React will soon natively support[0] SSR. Wonder if Next.js will still be around once React Server Components are fully released. [0] https://reactjs.org/blog/2020/12/21/data-fetching-with-react...

In short, the answer is likely yes. React's server component stuff is about providing primitives to make it possible to address some of the downsides of the current approach to building apps/sites that follow the SSR-with-SPA-handover (hybrid rendering) model. There'll still be a need for more holistic frameworks that sit in front of React. SSR itself has been possible with React since 2014 (allowing for a few memory leaks), Next.js just eliminates a lot of the grunt work.

The React team is working with the Next.js team (amongst others) to make sure there's alignment.

Re: Practical Front-End Architecture

#66

Post by yashap »

rattray wrote: post #61
yashap wrote: post #52

Earlier quoted context omitted.

Agreed. Having worked extensively with GraphQL, I’ve come to see it as a MASSIVE source of unnecessary complexity in almost all cases. Haven’t worked with Next.js, but using an SSR framework, then not using SSR, seems like a tonne of unnecessary complexity too. They even say: > At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful…

How do you keep your openapi spec up to date?

We edit the OAS with Stoplight Studio, and enforce it with server-side middleware, which validates that requests and responses conform to the OAS (400s if requests don’t conform, 500s if responses don’t conform).

At a previous workplace I’ve used OpenAPI Generator to generate clients and server stubs from the OAS, which is a nice approach to ensuring you’re confirming to the spec, too.

Re: Practical Front-End Architecture

#67

Post by jaredgorski »

mdtusz wrote: post #63
pc86 wrote: post #28

Earlier quoted context omitted.

> they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. This is sort of an expected side effect of recreating nearly-identical JS frameworks every couple months, no?

I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times…

I think both can be true. There are practical reasons to use React and Vue, but that practical approach is obfuscated by the zeitgeisty culture around tools that get unwisely applied to every use-case. Frontend architecture needs to be approached soberly and prudently. Not every site needs React and GraphQL.

Re: Practical Front-End Architecture

#68

Post by lolive »

yashap wrote: post #66
rattray wrote: post #61

Earlier quoted context omitted.

How do you keep your openapi spec up to date?

We edit the OAS with Stoplight Studio, and enforce it with server-side middleware, which validates that requests and responses conform to the OAS (400s if requests don’t conform, 500s if responses don’t conform). At a previous workplace I’ve used OpenAPI Generator to generate clients and server stubs from the OAS, which is a nice approach to ensuring you’re confirming to the spec, too.

Did you have the requirements for users that you do not know want to define their own API upon your data?

Re: Practical Front-End Architecture

#69

Post by jaredgorski »

yashap wrote: post #52
BigJono wrote: 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…

Agreed. Having worked extensively with GraphQL, I’ve come to see it as a MASSIVE source of unnecessary complexity in almost all cases. Haven’t worked with Next.js, but using an SSR framework, then not using SSR, seems like a tonne of unnecessary complexity too. They even say: > At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful…

> So, why are you using an SSR framework then?

Great question; I should’ve mentioned this more concretely in the post.

I would’ve nuked Next completely, but we like the filesystem-based server and the ability to add imperative server-side logic cohesive with each page (getServerSideProps). In the past, this logic ends up on a separate server file and it’s less cohesive. Next keeps things a bit more organized for us.

I like your stack. What’s your use-case?

Re: Practical Front-End Architecture

#70

Post by woutr_be »

vagrantJin wrote: post #59
toastercat wrote: post #33

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

Trust your instincts. That gur feeling like you are missing something important is nothing more than psuedo FOMO. Its complicated and contrived for no good reason at all. SSG are good. Plain HTML is even better.

> SSG are good. Plain HTML is even better.

I would always advocate for plain HTML, or some basic templating engine. But such a statement highly depends on your needs. Plain HTML is great when you know exactly what you're building. As soon as you're going for something a bit more dynamic, or when certain elements require conditions, you quickly move to either SSG or some for of SSR.

Not saying you have to use whatever latest technology people are advocating, but use whatever makes sense to use. Plain HTML has its limitations, that could be solved with SSG or SSR.

Post reply on HN