As a developer I don’t want to have to optimise my code based on the first meaningful paint, I don’t want to have to piss around to optimise my code based on when the browser determines it needs to redraw and I don’t want to have to understand how a browser rendering engine works and why. Does nobody else realise this is insane levels of micro-optimisation? I used to think being a front end developer only was a silly role as the skills are easily learned. Now it’s so complicated, the top front end engineers should be getting paid the same salaries as senior backend.
You don't have to implement this anywhere, not even on web. This is only because people making web frontends want to measure the performance to this granularity.
The web is different from all other native frameworks in that it is highly asynchronous: your text comes first, your images come later, css gets applied somewhere in between, then come in the third party content (usually ads but not necessarily, it could be embedded video for example).
> I used to think being a front end developer only was a silly role as the skills are easily learned. Now it’s so complicated, the top front end engineers should be getting paid the same salaries as senior backend.
Wow. Reading this I get the impression that you think that currently backend engineers deserve more money intrinsically. Why? Depending on the program the frontend might be way more important than the backend.
Making good interfaces _is_ complicated, even if the tooling would be perfect a good interface requires a lot of thought.
I've seen many threads and discussions dissing backends made by 'frontend devs' as if it were an insult. But please realize that frontends made by devs unskilled in this domain are equally bad and prevent your programs from being used by a lots of people.
Usually they had higher education, and were solving more complex problems with all kinds of dependencies and integrations.
Frontend, 10 years ago, was about knowing jQuery, how to make an XMLHttpRequest maybe, and a little bit of domain knowledge on browser bugs and using floats to implement your layout. Back then you weren't even doing responsive layouts on all projects. People usually filling these roles were not required to have the same amount of domain knowledge as a backend engineer - no way.
Nowadays it's a different kettle of fish. The tooling is insane. The dependency tree is insane. The amount of granular optimisations and obscure browser APIs you need to know to work on big-tech frontends is nuts.
So yes, I used to think this was the case. Not anymore.
I have the education, knowledge, and problem solving skills required for backend engineering; I just find the front end much more interesting. Building a complex, intuitive user interface for an application/website is a huge challenge.
I've built a few apps with frontends by now and every, single, time, I could not tell you whether my frontend code is any good.
In Python I sort of know when my code is good. It 'feels' good. It might not be clever or amazing, but I can get it to a point where it doesn't repeat loads, is reasonably easy to read even months later and behaves consistently and can be tested easily.
In Go I feel this effect even more strongly. It feels quite wholesome to me.
I just can't get to a point where I am satisfied with how it's setup. Yes, I can make it work, but it never stops feeling messy. I don't want to use a billion libraries or frameworks either. I like to do my own thing (having tried some frameworks, I felt I was mostly working against the framework).
So I don't know what this predicament is we find ourselves in nowadays, or whether I need to spend more time with frontend work, but overall it feels far messier, far more difficult to get right than the backend stuff I have built. Anyone have any pointers as to how one deals with FE work?
Even simple sites quickly turn into a mess of thousands of DOM elements and every time I try to write non-repeating code, I notice one more setting or attribute I need to switch particularly, so then I am adding yet another conditional to a function or writing another function, which basically does the same thing, but not really...
Wish I could go backend-only, lol...
If you treat it as a programming problem, you can write better front-end code by shoring up on your ability to compose, glue, and modularize code. You also need a way to represent front-ends as a data structure rather than a sequence of imperative actions. Data is easier to think about - imagine if instead of HTML you had to write imperative code to paint everything on the screen - that kind of code can get tangled up easily and make it difficult to understand or modularize the code.
In this vein, using a library that lets you think of the front-end as data ('declarative') rather than imperative DOM mutation (with jQuery etc.) is an important thinking tool.
A way to short-circuit the amount of learning associated with this is to pick-up tools that have already reified this knowledge, so that by learning the tool you pick up the many mental models they embody. I suggest either Reason (with ReasonReact) or Elm as great starting point. Pursue their homepages, toss a coin, pick the one that appeals to you on first blush.
Both these languages are typed functional languages. Types here are tools of thought - especially the ability to represent data as One of Many (sum types) - will forever add a dimension to the way you model data. Functional programming is a toolkit of methods that let you compose and glue code together, and while it wouldn't appear that they attack the problems you're facing head on (should I add yet another conditional here, or should I extract another function that looks almost the same vs DRY etc.), those are exactly the problems you'll be able to confidently answer after you've practiced in this paradigm for a while.
The other thing that has caused it, on reflection, is just too many elements (hundred of thousands or millions) particularly in complex SVG visualizations. If this is your issue, the solutions might include summary statistics, fancy graphics algorithms, or just changing the design.
Native UIs also have the significant advantage of loading all their resources from the filesystem, which is usually faster than the network.
An A/B test somewhere reported that pages that paint faster make more money... And at that point the race is on.
Maybe a better metric would be something like "last DOM reflow" or something along those lines? Usually I don't consider a page to be usable until its content stops jumping around the screen.