Practical Front-End Architecture • Hacker News Board

Re: Practical Front-End Architecture

#111

Post by eatYourFood » Tue, Sep 21, 2021, 4:39 PM UTC

dgb23 wrote: post #20

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…

What did Java move to exactly?

Re: Practical Front-End Architecture

#112

Post by rawoke083600 » Tue, Sep 21, 2021, 4:43 PM UTC

All good comments here...

I think the reason we have so many fe/js/options is that no one option has jump out as 'x10 better' than the rest.

Svelte for me at least gets close to 'it' - ymmv

Sidenote(sorry for highjack): The ninja hackers/coders out there please code this next:

Like you know how we have tree shaking for dead js/ts code ?(Really cool and impressive btw)

I want to get "html tree shaking" - Im putting it in quotes since what Im after is:

The least amount and/or optimized html that will generate the same 'view/end-result' of my current unoptimzed html.

Maybe a case for optimal-auto-encoder ?

Re: Practical Front-End Architecture

#113

Post by rawoke083600 » Tue, Sep 21, 2021, 4:52 PM UTC

lol it would be funny if in a few years... Google(crawler) becomes good enough to read all text from images(they are probably there already and beyond)

And instead of rendering html or static site generators...we just export everything as one or a few(for responsive) jpeg :) ?

Re: Practical Front-End Architecture

#114

Post by gspencley » Tue, Sep 21, 2021, 5:29 PM UTC

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…

GraphQL's biggest problem is that it dispenses with the concept of Interface Segregation (from SOLID). Instead of having more, special-purpose, API interfaces (which RESTful APIs give us) we bring all the problems that SQL introduced for interfacing with RDBMSs in the 1970s (that have been plaguing us for 50 years now) into the realm of front-end application development.

GraphQL is popular because it helps rapidly develop backend services. BE devs don't have to spend as much time wiring up end-points and serializers. But it just shifts the problem from the BE, where it belongs, to the FE where it doesn't. Like you said, it makes FE development needlessly more complicated. Now, instead of focusing on view-related concerns, which is the point of your front-end, devs need to understand more details about the BE's domain model (unnecessarily) and need to use a text-based query language to communicate with the services. It is pure stupidity.

Re: Practical Front-End Architecture

#115

Post by atom_arranger » Tue, Sep 21, 2021, 5:40 PM UTC

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…

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.

Re: Practical Front-End Architecture

#116

Post by bern4444 » Tue, Sep 21, 2021, 6:06 PM UTC

jaredgorski wrote: post #95

bern4444 wrote: post #88

Earlier quoted context omitted.

Totally, I think if this article were titled patterns it'd be more accurate. Architecture has a more specific meaning (at least to me). As for using state, when you use something like react-router, all those things, path parameters, query parameters etc are stored in state. You can build hooks that use the hooks provided by react-router to retrieve those values in a useEffect in the relevant components. The hooks you…

I see what you mean. By way of clarification, I see route validation and pageload validation as potentially separate. For example, a given route parameter may govern a whole scope of pages in the app, so it makes sense to centralize that route validation logic rather than duplicate it in each page’s validation hook. In a more traditional server (like Express), we can just handle requests which contain that route para…

That's the thing. In react, there's no difference between a route and a component (at least with react-router). So you can write logic that applies to a Route and logic that applies to a component the same way and apply it at the appropriate layer.

I don't know how Next.js' filesystem router works, but it seems to perhaps be the cause for this roundabout solution.

You can do middleware in client side routing with react-router similar to how you would with express. That's exactly what hooks are for and you can build your own to enable that functionality at the scope that's needed.

Re: Practical Front-End Architecture

#117

Post by emilecantin » Tue, Sep 21, 2021, 6:40 PM UTC

rattray wrote: post #90

emilecantin wrote: post #87

Earlier quoted context omitted.

Not the user you were asking, but the way we do it is that the OpenAPI/Swagger spec is auto-generated from server-side code (a C# .NET app with the ABP framework) during the CI build, and that is then used to auto-generate an API client (via swagger-typescript-api) which is what the frontend app uses. When the backend team makes some changes, they notify the front-end team which then runs the auto-generation script,…

Nice! Why not re-run the auto-generation script automatically?

We use these types all over the app, manual intervention is very often needed.

Re: Practical Front-End Architecture

#118

Post by dgb23 » Tue, Sep 21, 2021, 6:48 PM UTC

eatYourFood wrote: post #111

dgb23 wrote: post #20

Earlier quoted context omitted.

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…

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.

Re: Practical Front-End Architecture

#119

Post by Weebs » Tue, Sep 21, 2021, 6:52 PM UTC

iaml wrote: post #102

Weebs wrote: post #76

Earlier quoted context omitted.

I think if we're talking about concepts at the level of OOP, we'd be comparing MVU and virtual DOMs rather than React. I learned to write UIs in F# through Elmish (used by Bolero), which was inspired by (unsurprisingly) Elm. React, also being inspired by Elm, was simple enough to transition to once I was comfortable in Bolero. It was basically MVU with components that have local state and lifetime function callbacks.…

> React, also being inspired by Elm This is news to me, are you sure about that? Wasn't react released earlier than elm?

I believe you're right, I meant to say React's Hooks, but now I can't find a reference to that so maybe I misremembered. I wasn't interested in previous versions of React after going over the basics in the docs a few times, but after the introduction of hooks I found it more appealing.

Re: Practical Front-End Architecture

#120

Post by cannabis_sam » Tue, Sep 21, 2021, 6:58 PM UTC

Practical for front-end devs, not so much for us users who have to live with laughably shitty js-reimplementations of decades old built-in browser functionality…

Heaven forbid you’re on a shitty internet connection, these inane js-behemoths just die from a dropped tcp connection, since they’re built on the most optimistic assumptions about network connectivity.

I remember when accessibility was a part of web development, but I guess the ROI was to low.