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

141–150 of 164 posts

Re: Practical Front-End Architecture

#141

Post by phist_mcgee »

enumjorge wrote: post #41
phist_mcgee wrote: post #9

Earlier quoted context omitted.

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.

Spot on, any tool will look blunt in the inexperienced apprentice's hands.

Re: Practical Front-End Architecture

#142

Post by axhl »

leerob wrote: post #132
nicoburns wrote: post #130

Earlier quoted context omitted.

> Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense. Doesn't NextJS do the same? The alternative to compare to would…

Next.js is rewriting its core with a Rust-based compiler. SWC (JavaScript and TypeScript compiler written in Rust) will replace two toolchains used in Next.js: Babel for individual files and Terser for minifying output bundles. Happy to expand on this more if you want. https://news.ycombinator.com/item?id=28609125

Not the original commenter but would appreciate more on this. If you can be bothered, could you also expand a bit on how Next.js works under the hood when it comes to forcing CSR à la

  {typeof window === 'undefined' ? null : children
On a related note, thanks for what you do for Next in the discord.

Re: Practical Front-End Architecture

#143

Post by jaredgorski »

cannabis_sam wrote: post #120

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

I did mention that our clients are enterprise-level.

But I did fail to address a more general decision-making process regarding choosing frontend architecture. If I did (and I probably will soon), I would talk a lot about the egregious initial load times on too many blogs that roll crazy dynamic tools for what should be a completely static site.

Re: Practical Front-End Architecture

#144

Post by leerob »

axhl wrote: post #142
leerob wrote: post #132

Earlier quoted context omitted.

Next.js is rewriting its core with a Rust-based compiler. SWC (JavaScript and TypeScript compiler written in Rust) will replace two toolchains used in Next.js: Babel for individual files and Terser for minifying output bundles. Happy to expand on this more if you want. https://news.ycombinator.com/item?id=28609125

Not the original commenter but would appreciate more on this. If you can be bothered, could you also expand a bit on how Next.js works under the hood when it comes to forcing CSR à la {typeof window === 'undefined' ? null : children On a related note, thanks for what you do for Next in the discord.

The easiest way to force CSR would be to render nothing on the server, `useEffect` and then render everything on the client. This could be at the top level of your application. But, I'm guessing most folks don't actually want that. It's typically a better user experience to serve some loading state/skeleton pre-rendered from the server, followed by loading data client-side (instead of full CSR). If you have NPM packages or code that can only execute on the client-side, you can also use next/dynamic to load specific components in client-side only.

https://nextjs.org/docs/advanced-features/dynamic-import

Re: Practical Front-End Architecture

#145

Post by acemarke »

chakkepolja wrote: post #25
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…

As someone without this new web tech background, I have same experience about react. create-react-app has so many dependencies and takes a lot of time to scaffold a hello world. Adding some router or some popular library produces deprecation warnings and '2 moderate vulnerability' messages. Folder size will blow up over 1 GB to make trivial apps. That's insane.

The "audit warnings" are unfortunately entirely irrelvant to a build tool like CRA:

https://overreacted.io/npm-audit-broken-by-design/

The size of CRA is largely due to its primary dependencies (Webpack, Babel, Jest, and ESLint), which are normal parts of most modern web app build toolchains.

That said, there's plenty of other alternatives. For example, Vite uses a combination of ESBuild + Rollup for its build steps, and has only a relative handful of dependencies. As a result, it installs fast, and creates + starts projects even faster.

None of that is specific to React the UI library, though.

Re: Practical Front-End Architecture

#146

Post by chakkepolja »

acemarke wrote: post #145
chakkepolja wrote: post #25

Earlier quoted context omitted.

As someone without this new web tech background, I have same experience about react. create-react-app has so many dependencies and takes a lot of time to scaffold a hello world. Adding some router or some popular library produces deprecation warnings and '2 moderate vulnerability' messages. Folder size will blow up over 1 GB to make trivial apps. That's insane.

The "audit warnings" are unfortunately entirely irrelvant to a build tool like CRA: https://overreacted.io/npm-audit-broken-by-design/ The size of CRA is largely due to its primary dependencies (Webpack, Babel, Jest, and ESLint), which are normal parts of most modern web app build toolchains. That said, there's plenty of other alternatives. For example, Vite uses a combination of ESBuild + Rollup for its build steps,…

Yes. But I am a n00b and the obvious way was CRA.

In contrast, when I tried sveltejs, the 'official' way using degit worked sewmlessly, standard dependencies were also much smaller than when I used react.

But I will give a try to Vite, thanks for recommendation!

Re: Practical Front-End Architecture

#147

Post by jstummbillig »

atom_arranger wrote: post #115
jstummbillig wrote: post #8

Earlier quoted context omitted.

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.

Interesting. I am still very much hoping for a framework to tie it all together but in the meanwhile I'll have a look at this — thanks!

Re: Practical Front-End Architecture

#148

Post by drewpc »

nicoburns wrote: post #130
drewpc wrote: post #94

Not the OP nor the post's author. We have a similar stack (React + NextJS + TypeScript + Mobx) but use a traditional REST API using Django Rest Framework. There are some interesting topics in the post and in these comments that I figured I could expand on: 1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a butt…

> Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense. Doesn't NextJS do the same? The alternative to compare to would…

Yes, NextJS does the same. After re-reading my comment, I don't think I was clear: our reasons for moving to NextJS were the two mentioned, not because it was less complicated than our Webpack config from 7 years ago. It's not less complicated, it's different. NextJS does some weird things under the hood to make it seamless (like CRA does) but it can make things even more complicated to go with nonstandard Webpack rules or Babel presets/plugins. Overall, I think any JS application written in this day and age is going to be a tooling nightmare--NextJS included. In our case, it's not bad enough to force us away from JS (or TypeScript) yet.

Re: Practical Front-End Architecture

#149

Post by drewpc »

leerob wrote: post #132
nicoburns wrote: post #130

Earlier quoted context omitted.

> Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense. Doesn't NextJS do the same? The alternative to compare to would…

Next.js is rewriting its core with a Rust-based compiler. SWC (JavaScript and TypeScript compiler written in Rust) will replace two toolchains used in Next.js: Babel for individual files and Terser for minifying output bundles. Happy to expand on this more if you want. https://news.ycombinator.com/item?id=28609125

That'll be nice!!

Re: Practical Front-End Architecture

#150

Post by drewpc »

axhl wrote: post #142
leerob wrote: post #132

Earlier quoted context omitted.

Next.js is rewriting its core with a Rust-based compiler. SWC (JavaScript and TypeScript compiler written in Rust) will replace two toolchains used in Next.js: Babel for individual files and Terser for minifying output bundles. Happy to expand on this more if you want. https://news.ycombinator.com/item?id=28609125

Not the original commenter but would appreciate more on this. If you can be bothered, could you also expand a bit on how Next.js works under the hood when it comes to forcing CSR à la {typeof window === 'undefined' ? null : children On a related note, thanks for what you do for Next in the discord.

Read @leerob's answer first. Additionally, the notion of "forcing" CSR might be a misnomer. The way I understand it, NextJS always prefers CSR; the server renders HTML on first page load and the NextJS framework attaches JS stuff to the page on render to handle the client-side interactivity. So, if you turn off JS on your browser and load the page, everything works out of the box (page renders HTML, links work, etc). There are ways to specify server-only data requirements.

Once the client-side JS has taken over, the `next/link` component [1] is used to render and listen to events when a user clicks on a link. That component tells `next/router` to render the page that was clicked on. All of this happens on the client by default. If JS is disabled on the client, then the HTML rendered by the `next/link` component on the server is a simple `` tag and a normal browser page load occurs.

[1] https://nextjs.org/docs/api-reference/next/link

Post reply on HN