[titzer]

Frontend engineering is a thing because of the accidental complexity of a massive software stack that's evolved by accretion and gone through fad after fad after fad. I'm not looking down on frontend engineers, but I don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries.

[bastawhiz]

Where do you think all that code lives, then? The support for dark mode, the ability to look at the pixel data of an image so that you can display text with the right color on top of it to have high enough contrast, the subtle animation when you tab between elements in a scrollable grid, the annotations for accessibility, the code that makes drag and drop work like you expect... As much as you don't think it is "hundreds of thousands of lines of code", it really is.

I started a business online five years ago. I used as little JS as possible: the first version was probably 500 lines total. Today, it's approaching a quarter million, and it's all just me. Why? Because I want forms to show helpful errors when you type the wrong thing, and my pages to show appropriate visual cues at the right time in the right places, and for the page to look right when dark mode kicks in on your laptop or you resize your window, and for decimals to be formatted correctly for folks in Europe. Or for the power users who expect things to be fast, so navigating forward and back loads and caches data correctly. Or for folks with high-dpi displays (or as it were, folks who zoom in) who don't want pixelated icons.

And has it paid off? Yeah. As an example, my service hosts a surprising majority of blind podcasters, including the American Council for the Blind. I didn't get here with a spring in my step and a strong belief in semantic HTML, I got here by investing in all the fiddly edge cases so no matter what size your screen is, the browser you use, the language you speak, the currency you want to get paid with, your ability to use a mouse, your screen reader or level of vision, you still have a great experience. As much as you'd like to call it a fad or accidental complexity, it's really just your inexperience with actually building good user interfaces in the 21st century.

[ad-astra]

Hey, I share your passion for human interfaces - huge kudos to you. I built the main interface for the redesigned Amazon Photos iOS app and went through a lot of the things you mentioned - totally agree that it pays off. If you ever want to chat over coffee my email is [e-mail]

[DonHopkins]

I share that passion too! Most people grossly underestimate how difficult it is to implement something as seemingly simple as a text field or menu, when there are so many hidden issues and techniques that make them easy to use because you don't notice all the support you're getting.

Well implemented user interfaces have polish that makes their inherent complexity invisible, but polish is actually millions of tiny little scratches, not just a clean simple perfectly flat surface.

Accessibility and internationalization are two crucial dimensions that most people forget about (especially non-sensory/motor-impaired Americans), which each add huge amounts of unavoidable complexity to text fields and the rest of the widget set.

Then there's text selection, character/word/paragraph level selection, drag-n-drop, pending delete, scrolling, scrollbar hiding, auto scroll, focus management, keyboard navigation and shortcuts, copy and paste, alternative input methods, type-ahead, etc, all which need to perfectly dovetail together (like auto-scrolling working correctly during selection and drag-n-drop, auto-scrolling triggering on a reasonably scaled timer regardless of mouse position instead of mouse movements only inside the text field, so scrolling is deterministically controllable and happens at a reasonable speed, and doesn't freeze when you stop moving the mouse or move it too far, etc).

There are so many half-assed custom text fields out there written by well intentioned people who just didn't realize the native text fields supported all those features, or weren't intimately familiar with all of the nuances and tweaks that have been hashed out over the decades (like anchoring and extending the selection, controlling and editing the selection with the keyboard, inserting and removing redundant spaces at the seams of the beginning and the end of the selection when you drag and drop text, etc).

Even when somebody achieves the straightforward task of implementing a text field that looks pixel-for-pixel equivalent to a native text field, they're usually making a promise that they can't keep, that it also operates exactly the same as a native text field.

I've seen many text fields in games (and browsers) that break type-ahead by dropping keyboard input when you type too fast, because instead of tracking device events in a queue, they're polling the current state of the keys each frame update, so when you get slow frames and stuttering (which is often, like during auto save or browser thrashing), they miss key transitions.

Most games poll the mouse buttons and positions this way too, so they break mouse-ahead by dropping mouse clicks if you make them too fast, and they perform actions at the current position of the mouse instead of its position when the click happened.

Even a beautifully designed well implemented AAA quality game like Dyson Sphere Project running on a high-end PC has this problem. After you place a power pole, you have to hold the mouse still for a moment to let the game handle the mouse down event and draw the screen a few times, before daring to move your mouse away from where you want to place the pole, otherwise the pole goes into the wrong position, away from where you clicked the mouse, and this really throws a monkey wrench into smooth fluid interaction, predictable reliability, mouse-ahead, etc.

The Xerox Star had a wonderfully well thought out and implemented text editor, which pioneered solutions to many of these issues in 1982 (including internationalization), demonstrated in this video:

Xerox Star User Interface (1982) 2 of 2

https://www.youtube.com/watch?v=ODZBL80JPqw

See Brad Myers video "All the Widgets (Fixed v2) - 1990". This was made in 1990, sponsored by the ACM CHI 1990 conference, to tell the history of widgets up until then. Previously published as: Brad A. Myers. All the Widgets. 2 hour, 15 min videotape. Technical Video Program of the SIGCHI'90 conference, Seattle, WA. April 1-4, 1990. SIGGRAPH Video Review, Issue 57. ISBN 0-89791-930-0.

https://www.youtube.com/watch?v=9qtd8Hc90Hw

Also by Brad Myers:

Taxonomies of Visual Programming (1990) [pdf] (cmu.edu)

https://news.ycombinator.com/item?id=26057530

https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf

Updated version:

http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf

Brad Myers is finishing a book (tentatively titled “Pick, Click, Flick! The Story of Interaction Techniques”) which is partially a history of Interaction Techniques. Probably more than 450 pages. The initial chapter list can be seen at www.ixtbook.com. It is based on Brad’s All The Widgets video and Brief History of HCI paper, and also on his class on Interaction Techniques which he taught three times. As part of that class, Brad interviewed 15 inventors of different interaction techniques, all but one of whose video is available on-line, which also might be a useful resource.

Pick, Click, Flick! The Story of Interaction Techniques:

http://www.ixtbook.com/

https://www.cs.cmu.edu/~bam/ixtbook/#abstract

Brad Myers' Interaction Design Class:

https://www.cs.cmu.edu/~bam/uicourse/05440inter/

Here's the video and slides of the talk I gave to Brad's Interaction Techniques class about pie menus -- there's a discussion of mouse ahead, event handling, and polling around 16:30:

Video:

https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=...

Slides:

https://docs.google.com/presentation/d/1R9s4EEAwUjI_7A8GgdLY...

Pie Menus: A 30 Year Retrospective (Timeline):

https://medium.com/@donhopkins/pie-menus-936fed383ff1

[ad-astra]

Thank you so much for this treasure trove of links! This is exactly the kind of stuff I love learning about. Looking forward to going over this in my free time.

[stackbutterflow]

Is it safe to write your email address unobfuscated?

[nexuist]

> don't believe right-to-left languages or focus order inevitably leads to hundreds of thousands of lines of code or 50+ MB binaries

It does. It literally does. Try writing your own operating system, or font parser, or graphics engine. The work our shitty React apps sit on top of is unimaginably complex. It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app.

It's not simple, at all. Especially not for a video streaming service! I mean, my God, just being able to understand the codecs and licensing issues would take you months, let alone writing decoders that run natively on every platform. Let alone dealing with monitors and color schemes and HDMI and Chromecast streaming and window resizing and bandwidth limits and buffering and....

It's not simple.

EDIT: For reference, vim, a Hacker News favorite and widely considered one of the most popular TUIs ever built, is currently sitting at about 1.2 million lines of code. All it does is edit text files. Imagine if it had to play video.

[d110af5ccf]

> For reference, vim

Vim is an incredibly useful tool but I've seen frequent complaints about its codebase. Competitors with significantly higher code quality exist (ex Kakoune).

> > don't believe ... inevitably leads to

> It does. It literally does. Try writing your own operating system, or font parser, or graphics engine.

There are working examples of such and the code appears to be significantly simpler than the status quo. I'm far from an expert here but to the best of my understanding feature creep combined with maintaining backwards compatibility is to blame for a significant amount of current complexity.

Consider that if you rewrite a low level API with the benefit of hindsight, everything that uses that API has to be updated. Often multiple distinct APIs will be involved though, not just one. Look at the difficulty the Linux ecosystem has had gaining full support for Wayland, which necessitated the likes of PipeWire and a number of other new ways of doing things, and has been "nearly ready" for production for how many years now?

[sangnoir]

> There are working examples of such and the code appears to be significantly simpler than the status quo

Status quo is bloated -> someone rewrites a simple replacement -> becomes popular -> "Can you cover this reasonable use case, it's not currently supported" -> repeated previous step several hundred times -> oh fuck, the "lightweight" rewrite has become the bloated status quo -> GOTO step one

[titzer]

In some sense, this is WAI. Hopefully along the cycle, people learn to build better architectures that are modular, scriptable, customizable, and not giant monolithic piles. If things were more scriptable, then I as a user could script them how I want creating of a wall of my own "UI" and then swapping out the backends as I see fit. In my 25 years or so programming, I wish I had done this more; scripts for everything. Learn how to use my own scripts and only adjust them when stuff breaks/is swapped out. In retrospect, I have been buffeted by the whims of UI designers for decades, and I'm kinda mad about it.

[nexuist]

> There are working examples of such

For whom do they work for? The author and maybe a small group of Internet hobbyists? When you have to support 3 billion daily active users like iOS or Windows does, that lightweight codebase isn't so lightweight anymore.

And sure, Prime Video isn't Windows, but it still has over 200 million international subscribers that it needs to handle. It's definitely not something you can write in an afternoon.

[saagarjha]

> It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app.

Not really. Several years, maybe.

[nexuist]

I have been developing iOS apps since 2014, and was active in the jailbreaking scene before then. I don't believe any one person understands the entirety of what is going on when they launch an app. Remember, iOS is based on macOS, which is based on NeXTSTEP, last released in 1995!

iOS has been plagued by a whole host of bugs from the 90s and below. Remember effective Power? (https://apple.stackexchange.com/a/189064/364414) A Unicode memory allocation bug, the code for which was probably written decades ago and intended to run on a CRT monitor. I find it hard to believe anyone at Apple had interacted with that code since the initial iPhone release. Probably nobody at Apple in 2015 knew it existed. It's so unfathomably complicated.

[saagarjha]

I started working on iOS apps around that time as well, soon after I started programming. If you put your mind to it tracing the startup process of an iOS app is not actually as difficult as you think it is, especially if you skim things like “how does RunningBoard manage my app’s lifecycle?” or “is this launch being logged by CoreDuet?”. Also, FWIW, Core Text has several engineers working on it–text rendering is not a solved problem in the slightest–and is public API depended on directly by many apps.

[root_axis]

Alternatively, it could be that building high quality cross-platform front-ends that look and behave consistently across those different platforms is actually complex and the tools to solve those problems reflect that complexity. In my view, this is pretty common knowledge... just consider, every example of native software is horrible outside of one or two platforms, and most native software project/products don't even support more than two platforms.

[shroompasta]

This comes off incredibly naive of FE engineering.

Buttons and Doodads? sigh.

A significant factor as to why Apple has succeeded the past 2 decades is due to the design of their products - from the sleek aluminum bodies of their hardware to the UI/UX of their operating systems.

Unless you want your UI to look like something out of 1995, you're going to have to make it look good.

Making it look good will require a decent amount of code.

From animation libraries like Framer Motion, or data visualizations using d3, or even After Effects renders from Lottie.

That isn't even mentioning the amount of state that is required to be stored so that proper renders could occur - If your user has logged in, if your user has typed something into an input field, how many times you should retry a request if it fails, what functions to run due to a websocket response, and myriads of other things that FE engineers have to deal with.

Please reconsider your thoughts.

[titzer]

I feel the conversation will just cycle if we try to push people to the poles of opinion and insult them. Accidental complexity is an enormous, pervasive problem across all software stacks. The ratio of lines of code to pixels on the screen is pretty bonkers. Since you mention Apple, if you look at the ratio of lines of code per pixel, it's really hard to understand how an OS weighs in at 10GB, even for Apple which is brazen about deprecating and only catering to their own hardware and products. That speaks to a universal bloat problem that shows no signs of slowing down. I mean we could dive down into the details and keep coming up with special pleading for every little functionality, but it won't be a productive conversation, really, and the big picture will be completely lost.

> Please reconsider your thoughts.

Just leave that part out next time. Anyone can write this at the end of any comment and it only injects a bad vibe into the whole conversation.

[shroompasta]

Your whole line of comments is equivalent to "No offense, but.." -> proceeds to offend.

Especially with your "buttons and doodads" comment.

I wasn't even trying to get personal, but If you're going to hit, be prepared to take a hit.

------------

Never once has the weight of my OS been a concern for me, and I'm going to make the assumption that is the general case for the majority of users.

Never once have I heard the metric of LOC/pixels.

You say it's bloat. I say its necessity.

It's just keeping up with the times - beautifying and manicuring to attract eyes.

And you failed to address my comment about all the logic that FE engineers have to deal with - which is more of the meat in FE development than what happens skin deep.

[titzer]

>> I feel the conversation will just cycle if we try to push people to the poles of opinion and insult them.

> Your whole line of comments is equivalent to

You're doing exactly what I won't respond to, which is pushing me towards an extremist position I did not, in fact, state. I'll point you to the guidelines ( https://news.ycombinator.com/newsguidelines.html), which states:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

And I won't be responding further.

[lpcvoid]

I, for one, would love if UIs looked like it's 1995 again. Imagine the crispness, everything is fast, responsive and written in sensible languages. A simpler, and better time.

[sofixa]

I don't know you, but from what i recall Windows 95 and 98 were anything but with fast and responsive UIs. Many windows were fixed size, and with significant input lag

[lpcvoid]

I still remember Win 3.1 as being incredibly fast UI wise (once loaded), a feeling that propagated until around the Win7 era. As soon as this newer, non win32 stuff started happening in Windows, I lost that feeling. I have it again on Linux/Wayland, where native GTK controls are just such a joy to use.

And yeah - even if there was lag or slowness I don't recall, imagine those systems on today's hardware. I recently used a WinXP on fast hardware, and by god was that thing responsive, lean and fast.

[shroompasta]

While I agree in some cases, tech companies aren't marketing to those with that specific taste pallete

[lpcvoid]

Yeah, it's unfortunate. No money in a small minority.