[HN Gopher] The art of Front end Engineering
___________________________________________________________________
The art of Front end Engineering
Author : kintalo
Score : 47 points
Date : 2021-06-12 14:25 UTC (8 hours ago)
(HTM) web link (narative.co)
(TXT) w3m dump (narative.co)
| ______- wrote:
| Developers only get to call themselves 'Engineers' when they deal
| with lots of Javascript. HTML+CSS is a sort of glue language, and
| using that on a daily basis is not engineering anymore than
| filling up plant pots with compost and seeds and then calling
| yourself a 'gardener'.
| kintalo wrote:
| Are we really going to go down this path? Feel like this is
| such an outdated view that doesn't add any value.
| joshwcomeau wrote:
| Yep. In addition to being toxic and wrong and pointless, it
| also reveals that OP isn't actually very good at the non-JS
| parts of front-end engineering. It's easy to assume that
| something is basic when you only have a basic understanding
| of it.
| hobs wrote:
| It's also the same kind of gatekeeping that they said about
| javascript when it was first introduced... the gp doesn't
| even know their history.
| cupofjoakim wrote:
| Nice gatekeeping dude. I disagree - a lot of cases can be done
| with just html and css. Choosing the right tool for the job can
| by no means mean that you're any less of an engineer.
| ab1375260 wrote:
| Very well said.
| leephillips wrote:
| 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"?
| throwawayboise wrote:
| 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.
| reidjs wrote:
| 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.
| augustk wrote:
| 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.
| bryanrasmussen wrote:
| >"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.
| jasonkimtech wrote:
| Great article!
| austincheney wrote:
| _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...
| mason55 wrote:
| 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
| nawgz wrote:
| 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?
| jiofih wrote:
| 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!
| nawgz wrote:
| 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.
| echelon wrote:
| 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.
| austincheney wrote:
| 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.
| echelon wrote:
| > 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?
| austincheney wrote:
| It's not an insult. If you took that as an insult you
| probably aren't as open to honesty as you imagine.
| krychu wrote:
| VS Code must have been lucky then.
| echelon wrote:
| VS Code requires more careful engineering than a CRUD web
| app. It also has a lot more dedicated talent with eyes on
| the problem.
| austincheney wrote:
| These technologies aren't limited to CRUD apps.
| namanyayg wrote:
| 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?
| austincheney wrote:
| 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.
| nbardy wrote:
| This is pretty drab. I can be up and started in about two
| minutes with React, typescript and parcel.
| leephillips wrote:
| He didn't say "started", but up and running. I interpret that
| as having a basic working site.
| gumby wrote:
| > 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.
| celim307 wrote:
| 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
| brotzky wrote:
| 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.
| firechickenbird wrote:
| This article is just empty
| [deleted]
___________________________________________________________________
(page generated 2021-06-12 23:02 UTC)