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

131–140 of 164 posts

Re: Practical Front-End Architecture

#131

Post by dynamite-ready »

vagrantJin wrote: post #53
blunte wrote: post #7

Earlier quoted context omitted.

I'm in the same boat. But I don't think there's a lack of good info, but rather there's too much info and too many variants and options. There are probably many "correct" choices in the beginning, but we naturally want the good beginning and good long term maintainability/extendability. Rails without a JS frontend is excellent in so many cases. The trap is when you start adding a little JS here and there to make thin…

> What I'm hoping for is a configurator/wizard where you can choose your options, and then you get a fully functioning foundational system to start from. Not sure if Yeoman is still around but did they not attempt something similar?

Yeoman felt a little too much like a vehicle for one class of developers to foist architectural ideas on people. I'm glad it lost momentum. It would have accelerated the frontend tech churn if it took hold, not simplify or slow it down. It was also clunky to use, and created a situation where 2 or 3 people would compete to vend the canonical Yeoman config for a new frontend technology.

In a way, it's been superseded by create-react-app and it's ilk, but I think those kind of tools are fine. If you're reaching for a tool like create-*-app, then you've already made a specific choice about a number of things, and it's just helping you to bootstrap the project.

It going to happen again soon with WASM. But I'm welcoming that. We'll probably all end up writing full stack Ruby, or something.

Re: Practical Front-End Architecture

#132

Post by leerob »

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…

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

Re: Practical Front-End Architecture

#133

Post by stickfigure »

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…

I think you have it exactly backwards - the days of using string templates to assemble HTML pages was a weird and specialized era. React and modern JS tooling brings us back to traditional client/server GUI application development, just like we did in the 90s. And that's a good thing.

GUI development has its own set of concepts and broad applications. React is somewhat novel but still fits squarely in here; the idea of a GUI component is pretty enduring.

Distributed systems development has its own set of concepts and broad applications. With modern tooling, web interactions look just like traditional RPCs.

I programmed "full-stack" through the GUI fat client era, the primitive web era, and now the modern web era. I'm much happier developing with the modern tools.

Re: Practical Front-End Architecture

#134

Post by acemarke »

nicoburns wrote: post #128
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.

create-react-app is incredibly bloated. My current day job inherited a CRA app, and I've spent silly amount of time getting rid of the rubbish in there. But you don't need most of it. For a simple production-ready React setup try the following libraries: - react (obviously) - redux, and react-redux (which ties react and redux together), and redux-thunk (enables asynchronous redux actions). - react-router and react-ro…

Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packages like `redux-thunk` and `reselect` as well.

We've updated the Redux core docs tutorials to teach RTK as the default [1] [2], and have examples of migrating existing Redux logic to use RTK [3].

As for the CRA aspect: I still don't really understand why some people refer to CRA as "bloated". It has all the standard pieces that have been used in the React ecosystem for years: Webpack for bundling, Babel for transpilation, Jest for testing, and ESLint for linting, and all with a very reasonable default configuration that has had thousands of hours of effort to deal with edge cases.

I'm not saying that CRA is _perfect_. The maintenance has been spotty lately, it's taken a very long time for the Webpack 5 branch to get close to release, and I'd love to see CRA adopt tools like SWC or CRA to speed up builds. But given the problems in the ecosystem before CRA, it's done exactly what it was supposed to: provided a single command to set up a new React app with good build defaults.

[0] https://redux-toolkit.js.org

[1] https://redux.js.org/tutorials/quick-start

[2] https://redux.js.org/tutorials/essentials/part-2-app-structu...

[3] https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

Re: Practical Front-End Architecture

#135

Post by slt2021 »

newshorts wrote: post #40

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…

typical interviewer bias - you are looking for a candidates that look exactly like interviewer does, and possesses the same knowledge

Re: Practical Front-End Architecture

#136

Post by nicoburns »

acemarke wrote: post #134
nicoburns wrote: post #128

Earlier quoted context omitted.

create-react-app is incredibly bloated. My current day job inherited a CRA app, and I've spent silly amount of time getting rid of the rubbish in there. But you don't need most of it. For a simple production-ready React setup try the following libraries: - react (obviously) - redux, and react-redux (which ties react and redux together), and redux-thunk (enables asynchronous redux actions). - react-router and react-ro…

Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packag…

> It has all the standard pieces that have been used in the React ecosystem for years

Yes, that's the problem. It has ALL the pieces, whether you are using them, whether you understand them or not. For example, most projects will use either babel typescript. CRA? It has both and extra logic to switch between the two.

I feel like a better approach would be / have been an "open book" config where there is minimal starting point and it teaches you how to add the extra bits you want/need. That way it would be kept as simple as possible, and people using CRA would actually understand the tools they are using.

Re: Practical Front-End Architecture

#137

Post by Zababa »

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?

AngularJS, Angular, React, Vue, Svelte. That's 5 in 11 years. I could add Knockout, Backbone, Meteor and Ember. That's 9 if you're stretching it. I don't know anything about the last 4, but the first 5 ones all offer different ways to do things. I would even argue that they are more different that the "canonical implementation of the backend MVC framework" and the "Sinatra copy" that you have in every language.

Re: Practical Front-End Architecture

#138

Post by techpression »

If I understand this post correct they seem to like the idea of putting routes in the file system (Next uses magical file names as a way to generalize routes for those who haven’t used it). To me this makes absolutely no sense, a route doesn’t map to the file system in anything more than the most trivial index.html cases and you lose the ability to do things like “resource routes” to avoid mindless declaration of routes. On top of that, I would assume Next creates a route definition in memory anyways and doesn’t read from disk every request so it’s just pollution of the file system with the additional downside of making navigation unnecessarily hard.

Re: Practical Front-End Architecture

#139

Post by acemarke »

nicoburns wrote: post #136
acemarke wrote: post #134

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packag…

> It has all the standard pieces that have been used in the React ecosystem for years Yes, that's the problem. It has ALL the pieces, whether you are using them, whether you understand them or not. For example, most projects will use either babel typescript. CRA? It has both and extra logic to switch between the two. I feel like a better approach would be / have been an "open book" config where there is minimal start…

I'm genuinely curious - what difference does it make to you, the end user, if CRA has that extra logic internally? You won't see any of it unless you intentionally eject, and all it really is is some checks in the Webpack config file and the startup process.

Re: Practical Front-End Architecture

#140

Post by rapind »

stickfigure wrote: post #133
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…

I think you have it exactly backwards - the days of using string templates to assemble HTML pages was a weird and specialized era. React and modern JS tooling brings us back to traditional client/server GUI application development, just like we did in the 90s. And that's a good thing. GUI development has its own set of concepts and broad applications. React is somewhat novel but still fits squarely in here; the idea…

> the days of using string templates to assemble HTML pages was a weird and specialized era.

JSX?

Post reply on HN