Hacker News Reader

Comment by deanclatworthy | Hacker News Reader

Front end development is insane. Are there any other GUI implementations across any other industry (native, embedded etc) that has to implement this level of granularity and optimisation to make meaningful and responsive UIs?

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.

View on HN

> As a developer I don’t want to have to optimise my code based on the first meaningful paint

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.

<Rant> 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. </Rant>

Regarding your last point, yes I used to believe backend engineers deserved more pay.

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.

It still boils down to css and html,but we are champs at complicating things.

> Nowadays it's a different kettle of fish. The tooling is insane. The dependency tree is insane.

That sounds like a self inflicted problem. Is there any problem that the javascript-driven approach to frontends actually solves that justifies the added complexity?

I've definitely had to fight, as a frontend engineer, to prove that my job is just as demanding (and in many cases more so) as any other engineer.

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.

You make a very interesting point. As a reasonably recent dev (three years ish), starting with Python (and Kivy), then Go, then HTML/CSS/JS, I can see some consistent patterns emerge.

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.

Frontend? ¯\_(ツ)_/¯

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).

Javascript-anything always feels yanky. No matter how much I optimise it to death using webworkers, try every CSS trick in the book to load things as quickly as possible. On my 4.5Ghz 4790k with 32GB of ram, everything I do always hitches, stutters, jitters and doesn't feel smooth. This is true for the web (and that's after adblocking). Like, how is that the state of things? Browsing the internet on a weak work-machine without adblockers is literally unbearable. I simply don't do it.

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...

Front-end often has longer data transformation pipelines than back-end, and that leads to the complexity you mention.

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.

Front end work is just messy, solutions that optimize everything at the same time are rare/non-existent.

When I've run into hitches, stutters, etc, it was when I was doing too much of the rendering myself in Javascript, micromanaging the HTML and CSS. A little load time is better than any amount of jittering or hitching, which give me a headache very fast.

When you make the Javascript do less of the browser's job, work with CSS rather than against it, your code even drifts a little bit toward elegance.

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.

I've got some bad news for you: if you want to have a UI that's both complicated and responsive, you have to do something like this regardless of the platform. The golden rule is "don't block the UI thread", but then you have to decide how much work you can do synchronously before it counts as "blocking" versus the cost of moving it to some asynchronous worker. Getting it wrong gives you "white windows" or "beachballs" on native UIs.

Native UIs also have the significant advantage of loading all their resources from the filesystem, which is usually faster than the network.

Another big difference is that native UIs are usually way more rigid than HTML. For example a scrolling view in majority of applications contains cells of either the same width or same height. The frameworks are optimised for this. HTML can’t put any expectations on content size by default.

It is an area of front-end dev that easily crosses into premature optimization. You are right that it is insane to worry about this when first drafting a new UI for an app. But once that app is live, and you are iterating on enhancements and new features, a snappier user experience may bubble its way to the top, and then you would work on these things.

No, but then how any other GUI systems stream their implementation over a network before first load. Many desktop applications also don't open nearly as quickly as the average website.

How often do the other GUI implementations you mention load arbitrary code across an unreliable network?

I think it is all about the money. The reason anyone even gives a shirt about paints and when they happen is because someone equated it to money.

An A/B test somewhere reported that pages that paint faster make more money... And at that point the race is on.

Reply on news.ycombinator.com