Linkbait 42

Full-stack edition. Look no further than here.

Microsoft is rumoured to pull the plug on their EdgeHTML rendering engine and move to Chromium for the next Edge version. It’s always a sad moment when a rendering engine leaves us.
Now as anyone who read my Chromium blog posts knows, one Chromium is not necessarily exactly the same as another. Thus I do not expect EdgeChromium to be 100% the same as Chrome — more like 98%.
How to solve this? Test more in Edge — 3 years ago. Of course my readers know this and do this; it’s the full-stackers that are the problem.

Speaking of which. Heydon takes a stab at defining the problem with full-stack developers. They try to do too much, and as a result, code quality suffers.

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

He also points out that one full-stack developer is cheaper than three specialised developers, and cost cutting is certainly part of the reason why full-stack has become so popular.
Still, to me, it all comes down to the low esteem in which HTML/CSS is held (and Heydon also mentions that). It’s much easier to declare a low-status job redundant than a high-status one. I mean, are there large companies that have the same people do development and devops?

In case you’re wondering why full-stack programmers have such problems with CSS (and HTML), Robin Rendle explains. Front-end (i.e. HTML and CSS) is not a problem to be solved because, essentially, it’s already been solved. Just not by full-stack programmers.

What’s the point in learning about vanilla HTML, CSS and JavaScript if they wind up becoming transpiled by other tools and languages?
[…] Front-end development is complex because design is complex. Transpiling […] into HTML and CSS requires vim and nuance, and always will. That’s not going to be resolved by a tool but by diligent work over a long period of time.

Jeremy compares CSS to a programming language, and finds that selectors, especially, qualify. Still, that’s exactly the part of CSS that isn’t used a lot, since we all have to go modular and use classes everywhere.Foor for thought; also for the book.
While ostensibly explaining a React feature, Dan Abramov gives a lesson about JavaScript prototypes and inheritance. Useful reading for all JavaScripters — I learned (or relearned) a thing or two here.
Addy Osmani takes a look at the cost of JavaScript. While they work OK-ish on modern desktop computers, huge scripts cause a lot of problems on low-end phones. (News? No, not really. But people don’t listen.) As he says,

The web is bloated by user “experience”

If you want facts and figures to convince others, look no further than this article.

Harry takes an exhaustive dive into CSS and network performance.

Your page will only render as quickly as your slowest stylesheet.

If you ever wanted to know absolutely everything about the way stylesheets can block page rendering, read it all. Did you know, for instance, that you should not place stylesheets before async script snippets? That’s because browsers await the full stylesheet before evaluating the snippet. What if the script requests the colour of a certain element, and the CSS hasn’t come in yet? Better to wait.
Tons more good stuff here.

Interesting experiment by Daniel Buchner. He shows how to use the CSS :invalid pseudo, which triggers onkeypress, in a script, where normally the invalid event would fire onsubmit (or in a few edge cases).
Read my native form validation series for a LOT more background information about the differences. (I didn’t think of Daniel’s trick, though. Simple, elegant, useful.)
Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).