13 ms·

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

by d3nj4l 5y ago

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 it's way too complicated for things I would consider a JS-heavy SPA for, which are all mainly client-side apps (Like in this article - I wonder why they chose Next since they're blocking out SSR entirely). Elm is perhaps better but I think the ecosystem is lacking compared to React and Next, and it really does its own thing so I can't be sure what I'm learning applies broadly to frontends. Every time I think of making an SPA for a side project I hit up create-react-app, look at the uncomfortably blank canvas, and go back to Rails with ERB. TBF for most purposes Rails + Turbo gets you really, really far - just look at GitHub.

blunte 5y ago
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).
- vagrantJin 5y ago
  > 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?
  - blunte 5y ago
    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.
  - dynamite-ready 5y ago
    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.
phist_mcgee 5y ago
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.
- enumjorge 5y ago
  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.
  - phist_mcgee 5y ago
    Spot on, any tool will look blunt in the inexperienced apprentice's hands.
dgb23 5y ago
> (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.
- dSebastien 5y ago
  I feel like more people should look into Nrwl Nx to scaffold new projects: https://nx.dev/ 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.
  - tvphan 5y ago
    Sounds like Vite?
ehnto 5y ago
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).
- pc86 5y ago
  > 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?
  - mdtusz 5y ago
    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.
chakkepolja 5y ago
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.
- wlesieutre 5y ago
  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.
  - chakkepolja 5y ago
    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.
- nicoburns 5y ago
  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.
  - acemarke 5y ago
    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 https://redux-toolkit.js.org [1] https://redux.js.org/tutorials/quick-start https://redux.js.org/tutorials/quick-start [2] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... [3] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
recursivedoubts 5y ago
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.
jrochkind1 5y ago
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?
yakshaving_jgt 5y ago
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.
jspash 5y ago
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)

by d3nj4l 5y ago

blunte 5y ago

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

vagrantJin 5y ago
> 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?
- blunte 5y ago
  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.
- dynamite-ready 5y ago
  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.

phist_mcgee 5y ago

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.

enumjorge 5y ago
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.
- phist_mcgee 5y ago
  Spot on, any tool will look blunt in the inexperienced apprentice's hands.

dgb23 5y ago

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

dSebastien 5y ago
I feel like more people should look into Nrwl Nx to scaffold new projects: https://nx.dev/ 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.
- tvphan 5y ago
  Sounds like Vite?

ehnto 5y ago

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

pc86 5y ago
> 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?
- mdtusz 5y ago
  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.

chakkepolja 5y ago

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.

wlesieutre 5y ago
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.
- chakkepolja 5y ago
  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.
nicoburns 5y ago
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.
- acemarke 5y ago
  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 https://redux-toolkit.js.org [1] https://redux.js.org/tutorials/quick-start https://redux.js.org/tutorials/quick-start [2] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... [3] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

recursivedoubts 5y ago

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.

jrochkind1 5y ago

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?

yakshaving_jgt 5y ago

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.

jspash 5y ago

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)