Hacker News Reader

Comment by girzel | Hacker News Reader

In my attempts to be a "generally competent programmer", I've waffled about how much web-dev technology I should reasonably expect myself to know. I think where I've come down is: knowing CSS well -- and yes, that means a real understanding of grid and flexbox -- but forgiving myself from Javascript.

Anyone who might conceivably hire me to do anything JS related is likely to want the whole shebang: lightboxes, horizontal scrolling, SPA-like stuff, and I'm never going to be conversant with that. It's enough to be really good at CSS, and to save the JS for when people don't really realize you're writing JS: some little vanilla ECMA6 bumps to site usability, and maybe some tasteful htmx. That's enough. Leave the rest to someone else.

View on HN

Quite honestly, as a self-taught frontend dev with only 5 yrs experience, everything about frontend is backwards in terms of priority. There are people who've been doing frontend for 15 years, so before the boom when it was a jQuery/Dojo/MooTools etc, who have no clue what a finite state machine is, never mind the implicit ubiquity in their business code. But asking about if people are familiar with React seems prioritous.

Frontend is just stacked with this form of mistaken understanding, hence the bike-shedding over frameworks. We know we can represent a given app as a function signature, whose implementation would be comprimised of related, derived signatures, and a framework is just a bunch of implementation details between these in a sense. Details that may have profound significance for your project, but you'll be surprised how shallow the discussion resolves around those differences.

This is why frontend is just piles of code on top of code, at least at operations I've seen, the JIRA ticket fest being another contributer, but there's so little engineering understanding being propagated by and large, people mistake these high-level concepts for software engineering proper.

And somehow, the tech managers are usually the least in understanding, so they hire people who are like them and make them comfortable, and the process continues

This may be a general problem with the stack/framework emphasis.

If a framework is good, it should be friendly enough to people who've got essential coding/algo/data skills that the details of the framework can be picked up as you go, especially if they're familiar with other approaches in the same space.

If utility with a framework demands two years of familiarity before employable productivity with it... maybe it's not a great framework.

Frameworks just dont give af cause framework authors are out here busy trying to monopolize ALL THE STARS (dev mindshare, basically).

Just look at Hooks and React.

How many posts have we seen where people demonstrate the authors could've done something different, without buggering with what the meaning of a call site in a React component is, or even accomodated hooks in the Class API, but React devs can get away with this cause they don't need to prove coherent technical benefits, they just need to make it look like "the next big thing".

Numerous frameworks solve the problem of cross-cutting state concerns targeted at distinct sub-trees in the your UI (see mobx/freactal/etc).

The componentDidMount/componentDidUpdate simplification is nice, but could've been accomodated in the Class API.

Other reasons like "readability" or some shit, I honestly don't give af cause these are subjective statements that aren't at all neccesarily related to a solution's quality per project

You are putting programming on a pedestal. Knowledge of finite state machines is like pretty far down on the list of shit you need to know really well. Of course, if it makes you feel superior, pedal that nonsense.

The fundamental problem I’ve witnessed in the component composability era is that many people have their own mental models on what simple composability actually is. It’s a difficult topic to broach as many will see nothing wrong with their component architecture.

The thing that makes React powerful is how easy it is to compose components, and as a side effect, it’s allowing every developer (of every mindset, of every background), to come up with what they believe makes intuitive sense.

Case in point, you might think a finite state machine lib makes a lot of sense for a Dropdown component. I’ve seen one asshole actually write a whole blog post about it.

I’m not perfect either, and have certainly gone down the path of making a fucked up component composed of essentially my world view.

Another common example is the wonderful json config that gets passed into this elaborate component or HOC component, and allll you have to do is update the params and it will be suitable for all your fancy needs. A truly precious thing to stumble upon, and usually makes me want to just kiss the precious genius that concocted this world saving contraption.

Mr. Abramov of course, the grandest of psychopaths managed to turn a simple pub/sub into derivatives options trading buy/sell order chain of actions and reducers.

Some people simply do not think clearly, and it’s wearing me down.

Over time, the composability freedom of React has made me utterly hate my fellow frontend developers. I hate how absolutely insane some of your mental models are.

Literally every webpage that has more functionality than links contains a developer-maintained finite state machine.

Are you ok?

This is exactly my approach, and I'm glad to see it written out so well.

Reply on news.ycombinator.com