The art of Front end Engineering | Hacker News Reader

The art of Front end Engineering

narative.co

53 pointskintalo35 comments

There’s a deep understanding of the tools they use every day. They may use a framework as a starting point, but they also understand the JavaScript that makes the underlying work. They leverage CSS like a fluent language, manipulating DOM elements to their will. They see browser APIs as the foundation of their process rather than puzzling concepts pulled from Stackoverflow answers.

I wish that were true, I have not seen this in the corporate world and it appears absent in the job opening details of startups.

My experience tells me this:

* If you are really good you can be up and running a new project in something like React in 2 or 3 days.

* If you are really good you can be up and running without any framework at all in about 2 weeks.

* If you don’t use a framework you are forced to make tough design decisions early. This is critically beneficial and pays interest over time. Those decisions allow you to scale in ways frameworks cannot.

* The value of frameworks is over estimated for the wrong reasons and under appreciated for reasons developers don’t immediately see.

* Working directly to the DOM (even without query selectors) is amazingly easy, but it takes practice (just like writing CSS). The value is not the data, but the relationship between the nodes. That line of thinking reminds me of this board game called Othello.

* State management is less easy but still not challenging. https://github.com/prettydiff/wisdom/blob/master/state_manag...

This is pretty drab. I can be up and started in about two minutes with React, typescript and parcel.

He didn’t say “started”, but up and running. I interpret that as having a basic working site.

By the time you build your solution in native DOM, you've missed the market.

This is why we don't write applications in assembler.

If performance is your only metric, write Rust and target WASM. But that's probably not the right solution for 95% of cases.

VS Code must have been lucky then.

VS Code requires more careful engineering than a CRUD web app. It also has a lot more dedicated talent with eyes on the problem.

These technologies aren’t limited to CRUD apps.

I built a Windows like GUI, including basic file system display and population, using native DOM for the front end of a node app. It took me, one person, two weeks. It includes state management.

If you think that’s the same as writing assembly you probably aren’t the right guy to drive the success of a startup.

> you probably aren’t the right guy to drive the success of a startup.

Since when did giving honest opinions about speed and practicality merit personal insults?

It’s not an insult. If you took that as an insult you probably aren’t as open to honesty as you imagine.

I'm probably not a lot of the things you call me. :)

What kind of design decisions are you talking about, any examples?

What would you suggest for interactivity and JS; e.g. in a dashboard application with crud records/posts?

The benefit of a dashboard is real time status updates. My recommendation is don’t think about the JS at all. None.

Instead focus on services. Get the content you need. I recommend web sockets so that the updates come to the browser asynchronously without polling the server.

Once you have what you need you will figure out the most ideal user interactions.

Yeah one major benefit of a framework is the ability for new-to-the-team devs to get up to speed quickly and in general for people to understand what’s going on without having to pickup your domain specific stuff.

Similar to reasons Java became so popular in the enterprise

I’m not sure I agree with your takes on frameworks. It definitely depends on what you’re building, but in React to have composition and reuse for free immediately sets it apart from any bespoke solutions. I’m also struggling to imagine how you propose to out-scale the React framework with early & tough design decisions... these are Facebook engineers that made those same decisions, and they managed to scale the framework to Facebook levels. You understand that they may be the UI leaders of the world, yes?

Facebook, the product, did not use React until very very recently.

Do you use FB? If Facebook’s interface represents the “UI leaders of the world” we’re in troubled waters!

Can you say more about why we'd be in troubled waters for such a thing?

Facebook and its non-titular products are probably used by the most people in the world. The org is 50k people, and I imagine their engineering staff is proportionally quite large - they rarely introduce bugs and seem to have quite a good update cycle. There is a huge featureset and the website performs very well.

> the website performs very well

IME you could measure page transitions in seconds, it is an extremely slow website

If composition is your first concern you lack vision. Instead start from a good idea, form a vision on how you want to execute that idea, determine what you need, and then build those pieces in isolation. You get separation of concerns for free and composition becomes the last step. If you spend all your energy over concerns on how to build something you are spending creative energy thinking about what cool things to build.

Hey, OP here! I think I could've worded that better. It does sound a bit anti-framework when it wasn't meant to be at all. I was thinking more in broader terms where you'll inevitably be using Browser APIs even within a framework like React.

I specifically tried to avoid talking too much about stuff like React, Next, Tailwind, etc.

Like any position my enjoyment of front end depends highly on the philosophy of the company. Am I going to work with designers and product managers to really put the customer first and craft accessible, enjoyable, and useful ways of customer interaction? Or am I going to spend my time building dark patterns

Definitely. There's something amazing working as a frontend on a design led company. Often time my role feels closer to the designers than backend. The best part though is we get to participate in both spectrums if we really want.

This article is just empty

> They see [XXX] as the foundation of their process rather than puzzling concepts pulled from Stackoverflow answers.

Apart from front end, this in general is the mark of people who are fun to work with. Especially so when the XXX in question is something I don’t have facility with myself.

I’m very glad that programming has become less an obscure art known only to the adepts. Nevertheless I personally prefer to work with those with deep knowledge of their domain.

Great article!

I felt alienated by the first paragraph.

“As the web continues to expand, the tools we use for work and leisure have become synonymous with a URL in the browser.”

No, they have not. I rarely use web tools.

“The need for applications that marry the best in design and development has never been so high.”

I have no idea what this is supposed to mean.

“A frontend engineer brings these pieces together in an interface made to delight with every interaction.”

Even if I used web tools, I’m not ready to have sex with my word processor.

“So, what makes a great Frontend Engineer and why is it so special?”

I can’t parse this. What is “it”?

>“A frontend engineer brings these pieces together in an interface made to delight with every interaction.”

>Even if I used web tools, I’m not ready to have sex with my word processor.

I was thinking delight used in the same way a foodie uses it.

The phrase "delight the user" has always rubbed me the wrong way. I cannot recall ever being "delighted" by software. Frustrated often, yes. Not frustrating != delightful. Sometimes I have even been impressed, but that's different from delight.

Mostly the phrase "delight the user" is a red flag that the speaker is spouting buzzwords.

The only software that has the potential to delight the user are games or gamified software (likes, follows, etc). Everything else is out-of-mind at best.

I absolutely agree. "Delight the user" is superficial sales talk. What you should do as a designer is to put yourself in the user's shoes and solve the problems you will encounter when using the design.

Reply on news.ycombinator.com