Practical Front-End Architecture • Hacker News Board

Re: Practical Front-End Architecture

#121

Post by ilaksh » Tue, Sep 21, 2021, 7:13 PM UTC

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…

Maybe I am not the only person on the planet who still uses Vanilla JS and plain Node.js.

I mean I have a lot of experience with various front end component systems on desktop on the web, including Microsoft stuff and in the browser some Angular, React and Vue. But for my current project which is a little bit involved, I decided to skip React. It is actually working out fine. I assume React devs who see it will suggest that it's time to take me out behind the barn and put me out of my misery though.

Re: Practical Front-End Architecture

#122

Post by jspash » Tue, Sep 21, 2021, 7:34 PM UTC

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…

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)

Re: Practical Front-End Architecture

#123

Post by turtlebits » Tue, Sep 21, 2021, 7:58 PM UTC

Personally, I wish front-end frameworks were literally that, a set of files you can toss in a directory and serve (with nginx, apache, or any static host like netlify), with your backend as a separate deployable bundle.

SSR, progressive enhancement and all these tricks to speed up load time aren't really necessary if you just keep complexity down and your bundle size small.

Re: Practical Front-End Architecture

#124

Post by lampe3 » Tue, Sep 21, 2021, 7:58 PM UTC

Scarbutt wrote: post #97

lampe3 wrote: post #58

Earlier quoted context omitted.

Senior Frontend Dev: HTML was never gone :) I have and still working on big e-commerce websites. For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. What I see is the problem that people think that "Frontend development is easier than backend development". For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a g…

For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. Can you elaborate how? like some turbolinks thing?

I don't work for Ikea so I don't know how it is implemented.

What you can see in the Network tab is that you get chunks of html from the backend which have all the markup

Other e-commerce stores do that too.

Sometimes these chunks also have js in them.

Re: Practical Front-End Architecture

#125

Post by nicoburns » Tue, Sep 21, 2021, 8:08 PM UTC

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?

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

Re: Practical Front-End Architecture

#126

Post by marsven_422 » Tue, Sep 21, 2021, 8:13 PM UTC

Remember kids, the purpose of architecture is to minimize the cost of development, deployment and maintenance.

Re: Practical Front-End Architecture

#127

Post by insonifi » Tue, Sep 21, 2021, 8:15 PM UTC

Weebs wrote: post #119

iaml wrote: post #102

Earlier quoted context omitted.

> 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

Re: Practical Front-End Architecture

#128

Post by nicoburns » Tue, Sep 21, 2021, 8:19 PM UTC

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.

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.

Re: Practical Front-End Architecture

#129

Post by nicoburns » Tue, Sep 21, 2021, 8:26 PM UTC

lampe3 wrote: post #58

rimliu wrote: post #50

Earlier quoted context omitted.

Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"

Senior Frontend Dev: HTML was never gone :) I have and still working on big e-commerce websites. For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. What I see is the problem that people think that "Frontend development is easier than backend development". For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a g…

> Frontend development is easier than backend development

This always amuses me when it comes from junior front-end devs who are scared to touch the backend because they've never done it before. I always tell them not to worry: the backend is much simpler.

Re: Practical Front-End Architecture

#130

Post by nicoburns » Tue, Sep 21, 2021, 8:33 PM UTC

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 be a plain setup without any heavyweight boilerplate. These days you could you esbuild, but a webpack config can be ~50 lines and quite simple if you build it up from scratch.