Ask HN: Front End Development 2022 | Hacker News Reader

Ask HN: Front End Development 2022

22 pointsdcwardell19 comments

I've been happy working as a back end developer my whole career, but now I want to learn front end development. It's a little daunting since the space is so large and things change so fast.

I have 2 questions:

1. If you were to start a new product and had complete control of the front end stack, which tech would you choose and why?

2. What are some good resources (books, tutorials, etc.) to learn front end development in general (patterns, best practices, etc.) or the tech in particular.

View on HN

Front end dev here, formerly full stack. For moderate to high complexity apps, I would choose Next.js on Vercel for its incredible developer experience relative to either vanilla JS or React without Next.

If you don't care about React (for its popularity) it might also be worth considering other frameworks.

I would remove as much of the backend as possible and store whatever I could on the edge and use serverless functions extensively (also built into Vercel and Next). Failing that, I would outsource the backend to a headless CMS or a managed database. I would abstract as much of it as possible instead of having to manage containers and VMs.

Javascript is incredibly powerful these days and the backend can often just be a dumb data store. Vercel is incredibly innovative and IMHO one of the two companies really pushing the Web forward (the other being Cloudflare).

My rationale is that this stack allows you to spend the vast majority of your code on business logic instead of infrastructure.

You can write each page in a few minutes, git push, and it's automatically built and hosted and cached. Stacks that used to take days to set up now takes mere minutes. It's so much better than it was even 4 or 5 years ago.

Next took me from hating React and JS to falling in love with it. I enjoy every new project I write in this stack, something I've never experienced before in any other language, frontend or back. It feels like the only stack that was designed with developer experience in mind. It's purpose built for web apps.

The Vercel CEO https://twitter.com/rauchg/status/1603965931293536257 and I would agree.

Also, many others and I would leverage a few extras. Typescript is practically a given these days, preventing a huge class of compilation and runtime bugs. Along with TailwindCSS for much improved styling, and NextAuth for auth.

Hah, that was unexpected. Thanks for sharing.

And yeah, Next's built-in Typescript support is great. And not just TS, but dealing with the other parts of the buildchain that are traditionally a PITA to individually configure (the server, linter, bundler, package manager, etc.). Next sets it all up for you for ease of use and interop. It's beautiful.

Funny, this is my exact approach. Love it. Only comment, is that even if storing "dumb data" is the goal, we use Cloudflare KV, you still need some backend CMS or database to ensure some data integrity. So we build a simple bridge between the CMS/database and KV.

Do you use KV as a read-only cache, then, or?

Mostly read-only, with ocassional writes when we update the database/CMS. The writes handled by a webhook which hits the Cloudflare worker upon any update. Workers is so fast, the data and website is updated in milliseconds. We use Vercel's on demand revalidation.

Honestly, the real revolution at Vercel with NextJs in my opinion is the ability to easily use Edge functions now in any NextJs project. It's strange to me how so few developers use this, and understand how powerful the Edge is with Cloudflare. Even at Vercel itself they are focusing on the App folder and React Server Components (RSC). But, if you store everything at Edge and use Edge functions, everything is so incredibly fast, and easy to hook up/maintain that all the tooling around RSC is entirely useless.

Well, edge functions have a really good case but costs have to be taken into consideration. We use them if the logic is unique to the app and access is minimal. Our backend handles the rest. This way we can control costs.

The Vercel $20 plan comes with a million edge function invocations. Are they really that expensive at scale vs all the maintenance you have to do for a traditional backend?

A backend dev with minor FE exp here.

1. I would go with Vue. Because Vue is focused towards DX and pragmatism. It provides good defaults to start with and flexibility to go through less travelled paths should you need it.

Part of the reason is that when I first tried react (in 2016), I couldn't get it to build. And setting up build tools was not easy.

Vue can be used with a single script tag, so I was able to get it up and running without any issue.

I started with Vue 1, and recently worked on a project using Vue 3. Despite my gap and version changes, I was able to get up and running without issues.

2. Vue docs are great resources. Personally I prefer video courses to get started and then docs and guides. I can personally vouch for Laracasts Vue tutorials.

I also use Vue. It's got good docs, a decent amount of plugins, etc. But the main thing is that it doesn't make me use Jsx for HTML. Jsx in my opinion just creates ugly view files which are massively more complex and harder to read than they really should be.

JSX gives you a powerful way to describe your html. But template is easier and gives more opportunities for optimizationa.

I like that Vue has chosen to use templates as default and supports jsx for complex use case.

This way advanced use case can leverage the power of jsx while most common scenario can use html

I feel like if your views are complex, you're probably doing something wrong. Views really shouldn't have complex logic in them.

It is just like Reflection. Usual business logic should not use it, but all complex libraries (ORM, MVC, Dependency Injection) use Reflection and won't be ergonomic without it.

Same way, the jsx is advanced API. You will have complex logic, when you are authoring super reusable components for a variety of use cases. And jsx helps you in making it possible.

While allows you to use simpler approach for rest of the codebase

Back in the day the conventional advice was LAMP, Linux, Apache, MySQL, PHP. A lot has changed since then, but I'd say conventional advice has not changed much beyond the current equivalent stack:

Linux, Nginx, MySQL, Node.js/React/Express.

Nginx eventually overtook Apache. PostgreSQL is very popular but MySQL is still more widely used. The JavaScript ecosystem has not been displaced by much, although in recent years Go has made some ground on the backend.

If you learn Linux, Nginx, MySQL, Node.js, React, and Express, you can get hired almost anywhere today.

Just read the documentation. Most newbies do not.

1. It depends on the product. For a landing page go with zero javascript since you want things to load blazingly fast. I like static site generators for this such as Jekyll. For simple websites (e.g. small web shops), you might be okay just serving HTML/vanilla JS through e.g. PHP or Python. For apps that need to be an app, my go-to framework is Angular. I know I’m in the minority here but its tooling has come a long way. The developer experience is stellar nowadays. For CSS: Tailwind, which finally made me productive in styling elements.

2. If you don’t know vanilla JS it’s best if you learn that first before thinking about any “stack” – I can recommend Eloquent JavaScript. After you get the hang of it, pick any stack that fits your problem and interests you, and start building. :)

I published a fast and lightweight starter pack with Vite and wrote about it here: https://cpojer.net/posts/fastest-frontend-tooling-in-2022

#1 will depend a lot on:

* Team or solo

* Existing knowledge

* Performance requirements

* App complexity

* Is it more traditional (forms and submits and reports) or modern (infinite canvases, realtime collaboration)

* What can I assume about the users browsers? Are they stuck on old versions

* Do I need React due to complexity, or even just to make onboarding simpler if everyone has used it.

* Maybe the team is small and we all prefer Svelte so use that

And so many more things to consider. This is architecture / solution design space.

Web development is now like trying to choose a shampoo at the supermarket! If there was only one brand it would be much easier to pick!

* Transmission - I am using HTTP to request assets into the page, I have managed to reduce my total asset requests down to only 4. Other than that I am using websockets for absolutely everything, because the way I am using websockets is 8x faster than HTTP. Its like all the benefits of gRPC without the frustration of protobuf. It isn't just faster its also way easier to manage from the application code because there is no round trip and no callback/promise/await on transmission. Just fire and forget.

* Automation - I am automating the shit out of it. I am automating my documentation, bundling, compilation, and a few other things as much as possible in my build step, which is under 4 seconds. I use TypeScript to type absolutely every declaration. I use TypeScript-ESLint to enforce use of TypeScript declarations and a bunch of custom rules to eliminate known bad practices like "this", bind, call, and apply.

* Framework - What a dirty word. I am not using any of this nonsense. TypeScript is good enough. I have a simple 4 step solution for state management, otherwise I just work directly to the DOM and my current application is an OS GUI. Don't knock it til you try it.

* Performance - You don't know how slow you are until you measure things with numbers. Today I managed to reduce my page load time with state restoration (an OS GUI in the browser) from about 300ms to 192ms by eliminating a CSS reflow and removing 90%+ instances of innerHTML. In the browser the performance tab/graph in the developer tools is fantastic. In Node I prefer to write my own performance tools that typically intertwine with test automation. I eliminated the css reflow by visually hiding all dynamically rendered elements until everything is fully built into the DOM. To dynamically size things vertically I removed some JavaScript arithmetic based upon parent container clientHeight and instead am using CSS min-height:100%.

Reduce complexity to minimum.

Html + CSS. If I need JS interactivity maybe use htmx. Or, use stimulusjs if custom stuff is needed.

I’d do my best to avoid complicated front end solutions and frameworks.

Reply on news.ycombinator.com