Hacker News Reader

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 abstracted enough from JavaScript that you could learn React without ever properly knowing how to write JavaScript (which is something I've encountered in a handful of new devs).

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.

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. I ended up tripping over TypeScript/JS more often than React

At the same time, I do know what you mean about the walled garden ecosystems. It seems unfortunate that every framework I pick up, I'm learning a new set of components everyone uses for things like virtualization. On the backend it feels less common to be using a library that's only relevant to your stack, and when there's a killer library in another language, you don't need to move mountains to use it.

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

I think you actually meant Redux, which as an implementation of the Flux architecture was inspired by Elm, as per the author [1].

[1] https://egghead.io/podcasts/dan-abramov-co-author-of-redux

This is neat, didn't know about elm's influence on redux.

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

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.

I completely agree!

What I intended with my comment was to point out that the idea of new frameworks being created every week is a bit of an exaggeration and that it being the reason frontend development is fragmented is just totally incorrect.

React or Vue on their own with a sprinkling of helpful utility libraries will get most projects 99% of the way there though, and often times that _is_ simpler than trying to put together your own system for server side rendered pages and template composition.

Of course, if you're making a blog, you don't need any of this, but for _web applications_, I don't think I'd reach for SSR anymore.

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.

React's been the dominant frontend framework for over 5 years at this point, and shows no sign of going away anytime soon.

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.

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

JSX?

...does not generate strings.

and it isn't javascript, so it's essentially a template language. It's just being turned into javascript, which then goes into the vdom, which then gets diffed with the real DOM, which generates code to reconcile it with the real DOM.

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

I gotta say, I think React w/ JSX is far more of a weird and specialized era.

The real difference you're talking about is having the server render each user's UI versus offloading that to the user's machine. Regardless of whether it's via strings, 1s and 0s, https, rpc, etc. Browser's have become a more powerful "general purpose" renderer, so it makes more sense that they'll continue to take on more of the UI work themselves. It's still not as good as a purpose built client though, as sluggish electron apps have demonstrated. And sometimes it might still make sense to render the UI on the server (and cache it) for either / both simplicity and performance.

Occasionally you'll even do a bit of both with a client side app being rendered server side then hydrated... talk about a weird and specialized era.

While these terms are fuzzy, JSX has less in common with the template languages we used in the 2000s and more in common with interface builder languages like XUL. The experience is assembling components on a screen rather than generating HTML. Despite all the plumbing complexity, React/JSX (and Angular et al) feels fairly familiar to GUI developers from the 90s like me.

I agree with you that "client side app being rendered server side then hydrated" is pretty weird. I also don't think this is the future of the web but rather a holdover from the previous HTML-based era. It may never go away; after all, lots of content is very well suited to simple HTML.

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 things nicer, but soon you end up wishing you had just started with a fully JS frontend.

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. Yes we can do it all by hand, but especially when it comes to auth and some other needs, the configuration can be a bit messy (because some details are always changing).

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

I know it has been attempted many times. But like the general problem of too many options, it doesn't gain enough attention and develop a critical mass.

And in the case of setup tools, they tend to all suffer from the problem of being very difficult to change once setup. The tool you use to build the customized foundation is often unable to make future modifications if you have changed any of the generated code.

But by now we know the 99% common options people want: a choice of a few databases, (probably but optional) user profiles and auth, etc. The database side is pretty much solved, but the user management is definitely not - and it's the source of so many data leaks.

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.

There is a resurgence of interest in HTML (really, hypermedia) oriented front end libraries like Turbo, htmx (mine) and unpoly.

The a majority of web apps being built today could be created at a fraction of the complexity by using these libraries, and they put full stack development back on the table.

> (Like in this article - I wonder why they chose Next since they're blocking out SSR entirely)

They provided a bit of rationale (kind of sprinkled across the article).

For me using Next over CRA as a default comes down to three things:

- Batteries included, high utility components and defaults for things you ought to stitch together otherwise. CRA is not a drop-in replacement for Next, even if you only render client side.

- Flexibility. Your project might just look mostly static (fully rendered at build time) , or server rendered, or client side rendered. It rarely is. If you default to Next you can easily extend and configure these capabilities (and more).

- Great DX. It's a framework that respects developers with good documentation, flexibility and a "just JS/React" kind of philosophy. There is magic that you cannot easily break through as with every framework, but so far it seems they keep the magic boundary at the right place.

I feel like more people should look into Nrwl Nx to scaffold new projects: https://nx.dev/

It supports Angular, React, Next.js, Gatsby, Storybook, Cypress, and a lot more.

Maybe people don't hear about it, or they stop after reading the word "monorepo", while Nx is also great for stand-alone projects.

Sounds like Vite?

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.

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!

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-router-dom (adapts react-router for web rather than react-native)

That's 6 libraries, but it's really only 3 as the auxiliary ones under redux and react-router are tiny. If you need to support older browsers then you might also need core-js to polyfill the newer apis, but that's it.

And if you use esbuild to build then you won't need need all the complexity that webpack brings.

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

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

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.

And don't even think about using "npm audit fix --force", it wants to downgrade the react-scripts dependency from 4.0 to 1.1 and introduce another 50 vulnerabilities.

Not the smoothest first impression for what's supposed to be the "on rails" introduction to react development.

I found svelte ecosystem to be much lighter than react, svelte also being much smoother to write, but sadly it's still new and doesn't have the same amount of libraries that react has.

Hold out for just a bit longer as I have. The pendulum is definitely swinging back the other way with regards to front-end development. Rails has some interesting things in the works with StimuluxReflex. Basically a SSR SPA. It's a bit like the original promise of progressive enhancement before javascript ate the world. ie. everything is server-side, then "enlivened" after with JS. So if/when JS fails, you still have a working website.

Personally I prefer LiveView from the Phoenix(Elixir) framework. But my day job still uses Rails.

There are similar projects in Django and PHP (Laravel, I think)

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?

Elm's architecture is practical, and I haven't found the ecosystem lacking after having shipped tens of thousands of lines of it over the past five years. I've shipped a bunch of big React applications also, but Elm is the one I would choose every time.