I've never been on the web side of things, but I knew enough HTML in the early aughts to put up a basic informational website. After digging in to some sites I admired, I decided that it was too much distraction from my actual work to roll my own.

Granted some of this complexity comes from the legitimate need to support mobile gracefully, but damn are there layers upon layers upon yet more layers of stuff just to get some pictures to show up nicely with some text and look consistent across devices.

Props to everyone who does this for reals and does a good job achieving that consistency. For my money, I'll hire it out.

That group had to shift overnight (in relative terms) to app development. This might be more foreboding than people realize. Aside from those who need to write complex queries stitching big data together or generating reports, will we need a typical backend engineer ever again? How complex are schemas ever going to get that a UI can’t do it (and generate the corresponding api)?

It happened to the first version of the frontend developer and I think backend is next. Then frontend again at some point, and Data people have another thing coming when the backend folks need to find another job when theirs goes away.

If tech is going to replace industries, it’s going to start with replacing parts of itself first. We’ll be the first to know how this is going to go down.

They have business logic specific to our product, and owned by the company, so although I'm doing a lot of pointless "plug together HTML" work for my learning, I'm also doing stuff that, AFAICT, has to be original code written by me.

Did I manage to successfully duck out the entire web trend already? When I was a kid, the web barely worked. When I was in college, web apps were a strange novelty Google was working on. When I started my career as a developer, I heard murmurs that web was the only kind of developer left. 10 years on, I'm still working steady and still not a web / mobile dev. I learned a little TS and started using Rust for backends, and that's about it. I knew SQL from college. The web trend came and went and I only learned how HTTP works in the last 5 years. Doesn't seem like the hardest thing in the world.

Is it just a combo of luck and privilege that I missed it?

> If tech is going to replace industries, it’s going to start with replacing parts of itself first. We’ll be the first to know how this is going to go down.

Probably. At first it was funny - Software was a coal vein that just kept going deeper and deeper the more we dug, and high-level languages kept lowering the barriers to entry, making more programmers who each made more money.

Some day the vein's either got to run out, or widen so much that everyone is a programmer getting paid nothing. Since I have enough money to save, I'm hoping to retire before the sigmoid inflects fully.

If businesses didn’t start moving their apps off Desktop and into the browser, what the hell were we all going to do? We’d have to goto the Java bootcamps, instead of the web app ones.

Pay attention because I don’t think business wants a fancy new UI and backend every few years (especially in the Enterprise space). I think we’re going to be done with this too.

They will one day just load all that crap into Airtable and standardize business tools industry wide.

The command line can be daunting until you play with it a bit and I know many web devs try to avoid it as much as possible while working.

And yah, there's only so many ways to write CRUD, auth, profile, and presence; backend is already commodified as B2B products.

We have a precedent for dealing with government intervention in established industries which usually involves providing support to transition to other industries. Fisheries management is full of examples of government paying fishermen to fish less for example. Yet somehow coal miners became a target of derision by a certain branch of American politicians who gleefully cackled about regulating them out of work.

Devs have been so resilient because learning new things has been a part of the job description for decades.

It actually has something in common, you still write structured text for living, though your target audience are now people, not machines. Some readers commented that they find my style clear and understandable; maybe it is a carry-over from programming, where you cannot be ambiguous.

But I find writing for people much more enjoyable than writing for computers. As a computer programmer, you mostly receive negative feedback: something stopped working and the users are often angry or frustrated. As a writer for people, you receive more than a few thank-you e-mails from your readers, which brighten your day.

FWIW there are different types of writing and different types of programming.

Writing copy for a bank will probably generate a lot of feedback about mistakes that need to be fixed.

Writing code to reduce annoying monotonous tasks for coworkers so it takes ten minutes instead of two hours will get you a lot thank yous from your coworkers, and will also brighten your day.

It's all about what your job is, and how close you are to the people you are affecting.

The software that I spent most of my time with was a communication tool. So whenever something broke down, people had problems calling or texting one another. This pissed them off, naturally.

OTOH now my bestsellers are about half-forgotten events from world history. Aside from a weird e-mail I received from an even weirder Stalin-apologist, people generally enjoy this kind of reading and do not feel angry about it.

If, on the other hand, I were an investigative journalist and dug out dirt on politicans and mafia, the tone of the e-mails from readers would definitely get rougher, to say the least.

https://www.goodreads.com/author/show/18339067.Marian_Kechli...

Everything I write is in Czech, though. Automatic translation from Czech to English sucks.

I suspect this is literally true, but only because we don't see them. I've heard second-hand the story of a top developer at a famous unicorn who just couldn't keep up with all the stimulants everyone was using to code more and burned out, bought a cabin in the woods, and became a hermit.

That's interesting. Do you mean Adderall/Ritalin?

That stuff has a relatively fixed useful half-life. It doesn't work for as long as people might think. It also doesn't actually make thinking clearer. It makes people feel as if they are thinking more clearly. I don't feel like looking for it, but this has been studied and reported, somewhere.

If you are referring to crank, well, the half-life of that stuff is even shorter...

I thought is was obvious. It’s even some type of cliché.

But... now that I’m writing this. All those folks are either French, German or Central European. I currently lives in the US and I see more folks doing bootcamps to archive better income and address their debts.

Hmm. I would be curious to see number about that, because obviously it’s highly anecdotal.

Exemple :

- starting to roof painting company

- starting a small farm business ( direct to farmer market type )

- starting a goat herding business

- becoming a wood worker

- becoming a car mechanic in a communal garage

- becoming a teacher ( of non tech things )

- become a bootcamp teacher

- becoming a kumbutcha brewer

I know myself that I will burn out ( in a soft way ) of tech roles.

To clarify : those folks where able to do it because :

- their state offer reconversion package

- they have tech money

One reason I prefer frontend libraries like Vue and Svelte is they feel closer to the grain of the web (HTMLesque templates with JS and CSS sprinkled in), and provide a reasonable level of abstraction and magic. The learning curve and paradox of choice is also much easier to navigate than React especially for solo devs who aren't working on a huge app with a team.

It all builds up in me to be honest. You get the frontend complicated, then the deploy/infra gets complicated for the needless cloud dependency, and then the backend people don’t want to get left out of the party so they manage to rewrite their shitty php app in Go.

It’s like a shitty third world country. Not only do the roads suck, but there’s no water or electricity half the time, and you need to bribe everyone to get something. Instead of it becoming a wasteland, the population somehow still increases (more people actually entering tech). Now you really can’t change anything because there’s too many people.

How the wicked live.

I've given up every time I've tried it on personal projects. It's just a complete poorly document mess indeed.

At work we host our stuff on AWS but we have an ops team that deals with all the garbage. All I care about are APIs, endpoints and that one thing can talk to another.

The list goes on. The front end isnt that complicated relative to back end, there is just one ecosystem vs 10 for the back end.

Then I got sent a 15 page deployment document outlining the AWS infrastructure they had gone with. They paid megabucks and got a rube goldberg machine. To run a zend based PHP site developed 15 years ago that has never had any significant maintenance.

I was having the same opinion and practice. However, I'm kind regret it as well.

Even if you done everything with plain JS, eventually, one day some idea will float into your head such as "Hey... I want to automatically compress the script file/snip", "Hey I wonder if I can polyfill all my script", "Automatically bundle assets?", "Compress assets images?" etc.

Then, you start to learn Webpack/Gulp/Grunt (if the last two are still alive), and commit your entire soul to it few minutes later.

I think the reason for the messy front-end tech is, the Web itself is messy. You have to consider a lots of things, networking, file management, cache management, cookie, user-side storage, security etc. Some eyes saw the problem and then built a framework to address it, then others discovered some other issues in the framework ... the circle of life.

I guess we'll eventually settle down on something when people finally figure out what they want from the Web technology, or when the Web is "dead" (no dramatic changes anymore, like what happened to Desktop Applications today).

The trick is to write so little JS that its bandwidth usage does not even register. I'm recently going as far as to include licensing headers and extensive comments in my website JS, see e.g. <https://xyrillian.de/res/chapter-marks.js>.

(Side rant: I refuse to use the term "client-side rendering", because dang it, "rendering" makes an image. "Client-side rendering" as web developers use the term doesn't actually render anything, but instead compiles the page down to HTML, which is then rendered by the browser.)

For a hobby project, if I personally don't have fun with it, then nothing gets done on it. If I decide after a few years that I want to pick a project up again in order to add a new feature, the last thing I want is to find out that framework X needs to be replaced with framework Y, and so the two weekends I had expected becomes two months of weekends to rewrite the whole thing.

However, one could also say "Well, it's a hobby project, so I'll just slap this framework on to save my time..." or "What? I have to manually deploy this hobby thing every time I made a change? I'll just put it on a CI and let Webpack pack the thing for me"...

My method is this: I will start the project with all new tech/frameworks/lib/"display: grid", then I publish the project, if it turns out to be a success, I'll maintain it (including upgrade the framework, bug fix etc); if it's not, I'll just put it aside and start another one. This way, I can touch/learn many new stuffs that might later benefit me in my day job without any risk.

So, I believe it eventually boils down to personal preference (based on objective information on hand, of course) :D

For frameworks, I'm sure they save time once you are familiar with them, but that also requires evaluating which frameworks to use and how to go about using them. That ends up taking a lot more time than throwing something together with plain JS.

That definitely makes sense, especially if you're using the hobby projects to learn about frameworks that you'll later use elsewhere. I tend to do the same thing on the compiled side, trying out different libraries and languages. (For example, picking up Rust for last December's Advent of Code challenges, then porting some of my other projects over to make some performance comparisons.)

Part of this is also that my dayjob has very little interaction with JS. If/when I use JS in my dayjob, I'm usually picking something minimal so that it can be used/expanded on by others without framework-specific JS knowledge. My goal is to make sure that I leave behind a codebase that can be read/understood by as many people as possible, which may mean picking a software stack that has a bit worse usability, in exchange for ease of finding developers.

[1] https://github.com/cfenollosa/bashblog

I thought about plain HTML, but writing blog articles with it is a bit of a pain. Hugo was quite the right balance.

    function ce(tag, attrs={}, children=[]){
     var el=document.createElement(tag);
     for(var attrName in attrs){
      el[attrName]=attrs[attrName];
     }
     for(var child of children){
      el.appendChild(child);
     }
     return el;
    };

My concern isn't in "ignorance" or "cheating", but in spending time to learn a technology or framework that may quickly become obsolete.

1) need for capability that old method doesn't meet, so new tool is made

2) dev working on both simpler and more complex sites, wants everything to use the same tools

3) even sites with simple needs now get done using tools powerful enough to satisfy needs of complex sites

4) experienced dev doesn't see a problem, because they are conversant with those more complex tools, and also don't often get assigned to do simple websites anyway, but anyone doing the (considerably more numerous) simpler websites now is getting their groceries by flying a SpaceX rocket from home to the grocery store.

5) now that websites can do more, and very occasionally do, someone thinks of something else they want a website to do, and the cycle repeats

Imagine you are just getting into the business and are confronted with complexities, which would let you come to a grinding halt for the next 6 months until you have at least a foggy idea of what is going on. (Angular, Elm, PHP, React, ...) And once you worked through your initial list of "need to know", 5 more have popped up, like a hydra where chopping off heads just results in... more heads staring at you.

So, in this situation, it is quite reasonable to try and "get ahead of the curve" instead of lagging behind the ever changing world. You decide to write your own framework (based on your current and imperfect understanding), ignore what is already out there and pass the ball to anyone else. They have to look what you did now and read your stuff and scratch their heads, while you can be productive. And it feels good. You feel like a messiah. You can publish even a book, maybe and hold some enlightened talks.

This is the result. New generations are literally forced into re-inventing the wheel to even stand a chance at getting something done.

And its not only in web design/javascript/web-assembly/call-it-how-you-will.

The same happened e.g. in the Microsoft ecosystem (desktop programming). MFC -> ATL -> VB6 -> .NET WinForms -> XAML -> Silverlight and back to XAML -> .NET core -> however it will go on (I detached at that point, having run 'too many laps').

And since someone mentioned Linux... what is the canonical way to write GUI apps in Linux these days? Tcl/Tk? xlib? xcb?, SDL2, wayland over X? Gtk, that huge google framework? QT? SDL2? Motif? Pure wayland? Also a huge mess and people "innovating" just to be ahead of the curve. Yes, there are always reasons, if you need them to be...

There isn't a canonical way - Tcl/Tk, Qt, Gtk, SDL, Java, pure graphics backend calls all continue to work. All as long as there's someone out in the world with enough dedication to them to keep them up to date. Linux ecosystem is not at mercy of Microsoft or Apple, thankfully.

The learning curve for Linux was larger than Windows or MacOS, but I only learned the truth. By cutting away abstraction, I can actually understand what my system is doing, and be a better citizen of my operating system. Linux is arranged masterfully, and makes the Windows filesystem look like a joke in comparison. It's also faster than any of the Macs I own, with the freedom to plug in a modern Nvidia GPU and play whatever games I want.

>By cutting away abstraction,

I don't think I agree with this take. You haven't cut away abstraction, you've changed to a different kind of abstraction. Linux's 'everything is a file' abstraction is just that, an abstraction.

>Linux is arranged masterfully, and makes the Windows filesystem look like a joke in comparison

It's arranged more simply and straightforward, masterfully though, I dunno...

Every flavour of Linux uses a different layout for its root directories, stores configs in different places and generally is not consistent from distro to distro.

User configs are also scattered in random places at times. They could be in .config they could be in .local they could be in .$APP_NAME they could be in the app's directory, they could be in /usr/ somewhere. Maybe in a couple different places at once. Who knows? It's a mystery until you track it down.

Dependencies and libraries are a huge pain to deal with, especially when you start mixing and matching distro provided libraries with custom built ones.

I'm not trying to disagree with your post or anything. I love the way Linux lets you have control over your computer and doesn't try to stop you. But, it's definitely got some issues. I've only touched on a few related to your comment itself.

Yeah but once you track it all down you feel like a developer superstar genius...

Then you confidently sit down and proceed to repeat the process on another distro and immediately feel like a complete noob again as nothing is where it should be and you realize, you mastered nothing.

https://github.com/npm/npm/issues/533

The argument from the maintainer is reasonable that distros can just patch it, but realistically, everyone wants a newer version of things than what their distros ship—a similar tug-of-war ends up happening in the Python world, where distros like Ubuntu and Debian ship patched versions of pip/setuptools, and then users are encouraged to self-upgrade those tools to the upstream versions.

Anyway, this kind of thing isn't necessarily anyone's fault, but it is just a pretty different experience from Mac or Windows where you tend to have things be more self contained, like "here's where my Python installation lives because it's the path I put in the box when I ran setup.exe."

As a very casual Linux user (macOS is my daily driver), are there any efforts to solve these "death by 1,000 cuts" arbitrary (I assume) differences?

A bit of an exaggeration, but well...pretty much that.

[0]: https://refspecs.linuxfoundation.org/fhs.shtml

Yes, Linux depends upon abstractions. Everything in computing is an abstraction, including those 1's and 0's that tell the processor what to do. (Anything below that is electrical engineering.) The differentiators are the complexity and stability of that abstraction. When people talk about "everything being a file", they are referring to lower level abstractions that are relatively simple and stable. Likewise, when people talk about HTML/CSS/JS they are referring to lower level abstractions that are relatively simple and stable. This is less true (sometimes significantly less true) when people start discussing frameworks/libraries, whether that's in Linux or web development.

Let me give you an example of something that used to be clear and trivial in Unix that isn’t anymore because people «improved» it: telling your system about name servers.

Every flavour of Linux uses a different layout for its root directories, stores configs in different places and generally is not consistent from distro to distro.

there are differences, but it's 90% the same in the major distributions.

and while you do have a point about user configs, it is getting better. .config and .local are getting used more and more and are an improvement over every app dropping stuff in $HOME.

Yes and that 10% can cause some unexpected, sometimes hard to fix problems. A poorly written build script or installer that expects a specific distro's directory layout can cause some problems. Especially if it's a large convoluted build system that hard codes the directories in multiple places.

I've actually had to deal with this, it sucks. That was as an end user trying to use an app, not as a developer.

You run into this a lot trying to build small libraries and stuff. There's unfortunately a lot of poor programming habits out there. Directories inevitably sometimes get hardcoded and this causes problems because of the inconsistencies between distros.

>and while you do have a point about user configs, it is getting better. .config and .local are getting used more and more

And yet there's hundreds of apps that will never be updated or changed to conform to standards.

>are an improvement over every app dropping stuff in $HOME.

Tell that to snap. It insists its folder must sit nicely in my home folder and nowhere else.

i suspect many of those are no longer actively maintained. at best they receive security patches from distributions.

Tell that to snap. It insists its folder must sit nicely in my home folder and nowhere else.

my (low) opinion of snap aside, the bad here is that the location is not configurable. as a library of applications, i would want snap in $HOME. or i would put it in $HOME/lib or an equivalent. maybe .local would be appropriate too, but i understand it's for app specific user-data, so it doesn't look like whole apps should be in there. (edit: elsewhere i just read that .local is supposed to be like a user specific /usr/local, so snap should fit in there somewhere)

as a workaround try to use a bind-mount

Are people finally following the XDG standard? [0]

[0] https://wiki.archlinux.org/index.php/XDG_Base_Directory

It's easy to make "complicated". It's very hard to make "simple and straightforward".

Whether that's an indication of mastery is not a closed question.

If I try to interpret the bit about abstraction, I lean more towards "less opaque" being the intended meaning. On Windows and Mac, it's harder to see what is happening. On Linux, it's all exposed and there to tinker with.

> It's arranged more simply and straightforward, masterfully though, I dunno...

I would argue that simple and straightforward is masterful!

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

I have no idea what causes it or if people on Linux are not as sensitive to it or its a specific hardware setup which causes terrible fonts but once you read Windows fonts stuff looks so much better to me. Apparently its a hot debated topic but its so obvious to some it seems.

[1] https://pandasauce.org/post/linux-fonts/

Repeat after me:

    72pt is one inch tall!
    72pt is one inch tall!
    72pt is one inch tall!

Test it: Open up a word processor and load some reasonably normal font (e.g. Arial) and make some text that's 72pt. Then hold a ruler up to your screen: Is it about 1 inch tall? How far off the mark is it?

If you're using a modern, high-DPI display it's probably waaaaay TF off, haha. Even with regular displays it'll be off and there's actually no way to fix it because you can't tell Windows the precise DPI of your display! It tries to guess based on the DDC data given by your display but then averages the X/Y together to scale fonts. So if your X DPI is higher than your Y DPI it'll always get it wrong. Always!

Macs cheat in this area by always having displays of a fixed DPI. For the longest time all Apple displays were precisely 96 dpi (with perfectly square pixels) but recently changed it to 220-ish and made adjustments in their font rendering engine to match. I have no idea how they're handling non-Apple displays these days.

Linux, on the other hand does it right (at least X11 and KDE do) in that it scales fonts very accurately based on the DPI presented by your display via the DDC protocol (or if your monitor doesn't provide that you can set both X and Y DPI manually).

Gnome and GTK applications have the same problem as Windows though in that they only take one DPI setting and if the DDC protocol gives separate X/Y values it'll just average them and the results can be... Ridiculous. You don't really notice the weirdly-stretched fonts until you open a KDE application side-by-side with a GTK one.

Web designers loved to do their web pages with pixel measurements instead of real lengths in millimeters or points. Which is a horrible idea because of the different DPIes.

DPIes became bigger and bigger over time and browser developers were between two fronts of bullshit. The OS told them a bullshit DPI and web pages gave them a bullshit pixel length design. What did they do? The invented a third layer of bullshit to fix the other two (a little): the fake pixel. "Pixels" in web pages today have not the same length like the screen's real pixels, they are somehow scaled.

This is all broken beyond repair.

I wished that browser developers would have implemented it the right way. A pixel is a pixel and an inch is an inch. Many sites would be broken after that and the web designers would be forced to fix that and to use for example millimeters or points for lengths. And in a perfect world the OS would then use the correct DPI to display the rendered result.

With HiDPI displays all over the place, is subpixel rendering really still a thing? Pixels have gotten so small, I can't see individual ones anymore even if I'm trying. They could leave out anti-aliasing altogether in fonts and I'd hardly notice.

Or I'm just getting old.

By the way, font rendering in Chrome for Linux used to be really awful (no subpixel AA or something). It was fixed a few years ago - it looks like any other app now.

I omitted some detail that you can easily find in your favorite search engine.

What windows filesystem (FAT, FAT32, exFAT, NTFS) look like a joke and compared to which Linux filesystem? Ext2? Ext3? Ext4? ReiserFS? ZFS? It’s pretty clear that you never used Linux in the 90’s from your comment. And the main problem with Linux at the time had nothing to do with the filesystem but mainly with the immaturity of the complete system. I am very curious to understand what great truth you understood by using Linux. Would you kindly teach me this great knowledge and illuminating experience that I somehow missed?

Many other projects do not follow this way of thinking or don't have a BDFL. They break API's because... someone felt like it? Every once in a while I dig into the changelogs or migration guides of projects (sometimes they don't even have a migration guide which is just awful) and you'll see things like changed names of functions, swapped argument orders or even complete removal of functions. But why? We don't know and my guess is it usually boils down to someone "feeling like it".

> They break API's because... someone felt like it?

I empathize with them. Designing software is essentially philosophy. The interfaces reflect the developer's current understanding of the world. When this understanding improves, people are tempted to update software because they feel like the software is wrong and unelegant when it doesn't match what's in their minds.

It takes a really good engineer to reject this impulse and take responsibility for interfaces people came up with in the 90s.

I’d be lost without wsl.

Were you forced to update to Catalina? I'm still on Mojave right now. My 32-bit apps still work, happily unaware of the fact that they're no longer supposed to.

But what about 3rd party plugins? As far as I understand, most of these won't work on Linux either.

By not running hundreds of useless programs, I guess. If you launch htop inside OpenBSD, it'll fill half of your terminal, and the rest is empty.

The easiest way to try it is to install it on a virtual machine. You'll see that not much is needed to get to a point to launch firefox from an xterm.

Taking a NPM+Framework project of 9 months old I often have a low change of install-run at the first time. Always there's an update, an incompatibility, or something that brakes the build process and I need a couple of hours to fix it again.

Is not possible to work like this in the long run. Front-end projects are investments of time and money and I want them to be durable and maintainable for a long period.

P.S. I started digging into clojurescript/webassembly for this reason

The trick with this is you have to avoid dependencies that compile C code or native binaries as part of their installation process, since those binaries might not be portable. I try when possible to avoid anything that's using node-gyp.

But if you are vendoring dependencies and they're compatible with the system you're compiling on, then you will never need to worry about libraries breaking or changing underneath your nose.

You will still need to worry about security vulnerabilities, but that's just the case with all software. At the very least, 10 years from now your project will still compile.

No, even further. Just commit your node_modules folder.

There's this idea that vendoring has to be really complicated, but committing node_modules was actually official advice early on in Node's history. And what that means is that if you clone your repo, you just run `build`, you don't have to change or configure anything at all. The only dependency you have in your project becomes a node binary -- and honestly, you can vendor that someplace as well, node is reasonably portable.

There are a lot of advantages to this, not the least being that if you're demoing or working on a project someplace without an internet connection, having an up-to-date Git repo is all you need, you just have your entire project. If you switch branches, your project is ready to go.

Of course, if you have something like 1G of dependencies, checking them into Git starts becoming kind of cumbersome. But if possible, avoid that, for the same reasons you would avoid JS dependencies that compile native binaries. Having gigabytes of dependencies is going to be a nightmare for debugging and security, no matter what language you're in.

But I have built some pretty complicated projects where vendoring is fine. It doesn't balloon the size of my git repo, it doesn't make the project less portable, and it regularly saves my butt when I forget to check out the right branch before getting on a train without an Internet connection.

And all you need to do is not add node_modules to your gitignore.

This is the second best strategy, but:

- node makes it kind of annoying to do this, because unless you do a clean build every time (which is much slower) `package-lock.json` will get largely ignored.

- I have seen multiple projects break with semver. Just because people are supposed to avoid breaking changes in minor releases doesn't mean they actually do.

- Even if you're downloading the same version, there are scenarios where natively compiled binaries can bite you. I've run into issues where node-gyp just wouldn't work unless I downloaded a completely separate compile toolchain onto Windows and restarted the computer. If you can avoid that and have all of your dependencies be pure Javascript, you will eventually save yourself a lot of horrible dev-ops work when the "quick" install on a new VM turns into an hour long process of watching Visual Studio tools download (tools that to GP's point may not be available or compatible 10 years from now).

- And finally, sometimes you want to do work across multiple branches without an internet connection, and vendoring your dependencies allows you to check out a branch and know you have the correct dependencies even if you don't have a connection to run `npm install` with.

Additionally I looked at the sqlite3 package and not too surprisingly it uses node-gyp as well. So even checking in node_modules might cause the problems you described.

Out of interest: which backend language do you recommend to reduce such problems...?

I agree that node-gyp is a problem. It's possible to avoid, but can take some work (particularly when you start dealing with databases that basically have to be in compiled languages). The one saving grace is that if you have a set hardware that you're running on, you can sometimes vendor node-gyp dependencies. Unfortunately, that comes with some weird edge cases, and sometimes your dependencies break because your OS changes. I don't recommend it, but I understand that sometimes it's unavoidable.

I am hopeful that native WASM will solve some of these problems, but I don't know how realistic that hope is.

If you want to make a complex web app today, that's easier than it was 20 years ago. The tools are infinitely better.

If for some reason you decide to use the tools meant for complex web apps to make your simple page, you're going to feel like everything has gone horribly wrong. But why are you doing that?

It is horribly difficult to not use these advanced tools for simpler problems. At work my team does just f**ng CRUD forms, and for doing this we have the most overcomplicated stack I've seen in my life. Go backend with React, Redux, Rxjs,custom.webpack craziness, and 32 tons of internal weird libraries no one would willingly use ever even if pointed with a gun.

If I propose to just use Rails for this and be done with it, I'd be declared and heretic and expulsed from the frontend team.

We need a team of 5 people to mantain this project (and a few smaller ones) because of the architecture (SPA + Go microservices) and the tools (React, rxjs, redux, data loaders, graphql, typescript safe actions whatever, an in-house-built crazy i18n system, custom webpack, some 10s of other open source libraries, and some other 10s of internal custom libraries).

It's crazy. Really crazy.

I’m getting pretty sick of it myself.

Look, I love node and javascript. But I can't deny it is is total mistake to use it in a business context for web dev when you have django, rails or Laravel. Same for Go and many other trendy tools.... Reinventing the well is not a good business unless you're in the wheels business.

I blame the industry who fell for golang's marketing and started shoving golang into places where it doesn't belong.

But people learn it, get hyped, and want to use it for everything.

So now we're spending months doing things that already exist in popular frameworks.

Go is not for web development.You're not Google.

CLI app perhaps, and some simple use case here and there. Databases and infrastructure services need more expressive languages.

I agree with you otherwise.

By infrastructure services I mean things as DNS servers, network queues, etc.

Yes I understand :) golang is still a terrible language for them though. Rust, Java, and C# are strictly superior alternatives.

Which doesn't address the concerns of the author though, because the key is not that you can make the same page in 2021 (sure you can), but that nobody will pay your for making it in 2021.

Whereas if you knew how to make a pair of shoes in 1999, or to use a CS example, how to write good C in 1999, people would still pay you for the same knowledge...

>If for some reason you decide to use the tools meant for complex web apps to make your simple page, you're going to feel like everything has gone horribly wrong. But why are you doing that?

That's not the author's concern. His concern is that the fundamental technologies and best practices get thrown out every 5-8 years, and people in web frontend have to relearn tons of stuff and throw out hard-earned knowledge, plus add all kinds of stuff that was never a thing to stay afloat the current practices...

One could chalk it up to "well, of course you need to read to stay ahead", but the complain goes beyond that, to the volatility of front-end concepts and practices that makes this far more demanding that most areas of development (see also the related "js fatigue").

You can't use Flash, that's fair. But my goodness, you wouldn't want to. The small amount of incidental complexity we've gained from forcing pizza shops to stop laying out their interface in Flash is worth it. And outside of the plugins that were absolutely the correct decision to remove, everything else you want to use is still available.

What we're getting at is that with a few exceptions (HTTPS, Java plugins, Flash), virtually all of the old APIs that you used to use on the web are still supported and are the exact same to use, if not better. This is not the case everywhere with every language and platform. But the web has done a reasonably good job at being backwards compatible.

You're worried about deploy processes, and you want to deploy a free site on Netlify? You don't need to learn Git, you can hand-code your site in static HTML or generate it using any program you want and just upload it as a zipped folder. Your Dreamweaver builds will still run today. Font faces? Still work, you don't need to worry about FOUT. You miss table layouts? Hackernews is using that crud right now. The complexity around build tools, processes, and frameworks is all optional. The browser doesn't care.

If you're missing the old experience of building websites, then just do that. I maintain https://anewdigitalmanifesto.com. It is hand-coded HTML that I wrote in a text editor. It has no Javascript, no build process, no minification, nothing. And it works fine; no one has ever complained about it to me. If you're adding complexity to your engineering process and it's making your job harder instead of easier, then take a step back and ask yourself why you're adding that complexity in the first place. Is it solving a problem? Or do you just feel like you need to do things "properly" based on the current development style? Because again, the browser doesn't care.

The loss of flash is very unfortunate.

There's a technical hole that I still think could be filled by other programs today. But often, I hear people lamenting the loss of community and the loss of universal publishing.

And on that note, aside from the animation-centered workflow, I'm less certain that the rest of that stuff is actually gone. Unity publishes to websites just as well as Flash did, if not better. Unity even lets you publish to Linux, which Flash never really supported well.

And honestly, I'm not sure the community is dead either, it's just moved on to platforms like Scratch, Pico 8, Itch.io, and Roblox. I see very similar energies when I interact with people on those platforms. It's a different community, it's younger kids with different norms, the old generation isn't as welcome anymore. But I'm not sure the reason for that is because Flash died. Sometimes generations grow up and younger generations go act creative in different spaces.

So yes, there is a very specific workflow for a very specific type of game that no longer works on the web. I've used Unity, and I don't really like Unity, I hate it's resource management, I hate that we're still using proprietary software after so many years. But I think more people are making games with Unity today than were making them back then on Flash. It's more accessible.

I'm very, very slowly changing my opinion on this. Part of it is that Flash is still available today under Animate, and while it is still chained to Adobe I've still never heard a really good breakdown of how it's worse or what features it doesn't support anymore. As far as I can tell, you can still use Actionscript 3.0 with Animate. It is proprietary and expensive, but so was Flash -- so if it's purely a technical problem, then I'm not 100% sure that you couldn't still make a Flash website/game today.

I still think there's a hole here that could be better served by Open Source toolchains, but I'm becoming less convinced that it is as big of a deal as I previously thought. If you're trying to make games, now is a really good time to be alive. It could be better, but if you give me the option of making games in 1999 or making games today, I'm not going back to 1999.

And aside from that, even if Flash is a hole, it's still very specifically a hole for games. Even during its heyday, building static websites in Flash was a sin. Almost everything else you want to use to build a static website is still available. Just not that specific sinful part :)

This is more than just games. Basic form based workflows peaked with vba and access. Early 2000's dream of components that you could drag in and then wire up to the side seem to be gone.

Now, in fairness, I lauded their death, to an extent. Jsx is a step up when you don't have a designer you are working with. Css, as a concept, is basically void of you aren't collaborating with users on how to style things.

And I agree that the devops has improved. Within reason. Some things are easier, but that ease brought in a sort of Jevon's paradox where, since it became easier to ship more and more, we now ship way more and more. But, are we delivering more?

And I think that is hard to answer. I think the truth is we are hitting more and more of the tail. Which is good. But individually, nobody takes up now and more of the tail, so it is hard to see.

(Granted, I suspect accessibility is losing to this race. :( Basic affordances that you got with fieldsets, labels, and basic html are commonly a second thought on so many custom components.)

The ease of creating something is just not there in general. The current tools are harder to use for beginner and beginner achieves less with more effort.

And open source have bad track record in terms of creating user beginner friendly tools.

And you can validly complain about the technical quality of tools like Scratch, but as much I personally hate to admit it, Scratch is more user friendly than Flash was. I personally know kids who are making stuff in Scratch that would not be able to handle Flash. It's extremely crude stuff, Scratch is ridiculously limited. But they're still making stuff and sharing it, and getting their friends involved in the process, and sharing hacks with each other to get around its limitations, and finding other projects that impress them and reading their source code.

I do get what you mean about Flash's technical side that made it interesting. I miss an animation-first workflow, I wish someone else would build a tool that experimented with that. There is definitely a hole in my game-dev process that Flash left behind. But in theory, you could still be using Animate today and exporting your games to HTML5. Nobody has explained to me what's broken about it.

But if everyone in the old Newgrounds scene moved to Animate, or if it was magically released for free tomorrow, would that bring back the community? I'm not sure it's that simple.

I don't think that kids stopped being creative when Flash went away. I think that people (myself included) who grew up on Flash got older, and the spaces are different now and we're not being invited to them. Which... I don't know if that's really a technological thing, or even necessarily a problem that needs to be solved. Were there really a ton of 35-40 year olds making stuff on Newgrounds back in the day? I am increasingly learning about community spaces from the kids I know that I would never stumble on by myself on the Internet. And they seem to be pretty vibrant, they're just not my spaces anymore.

That’s true if the web app is a SPA and uses React and doesn’t require much accessibility and uses Redux or doesn’t manage state and, and, and...

Most web developers are limited to those conditions and most currently posted front end jobs are limited to those requirements. Technically what you said is subjectively correct but it depends on a lot of factors and constraints for the average developer.

But then there's also the problem of people relying on JavaScript at all for websites that would've been fine as a bunch of fully static HTML pages. It's as if these days you can't do software development without overengineering everything into oblivion.

IMO it's not the topic here if JS should at all be used. You won't catch me arguing with that -- my answer is almost always "NO!".

The topic was: "but can you make web pages like 20 years ago in the current frontend dev jobs market?" -- the answer that is "no" as well IMO.

React and other frameworks help you manage the state of your UI without having to worry (As much) about efficiently re-rendering the UI.

Redux and other state libraries help you manage the global state of your JS app so your entire app can easily access and update common data.

20 years ago, you could make a complex web app in Java, ActiveX or Flash. (There were also more obscure options.) People would install a plugin for your app.

Now, it all uses Javascript. There are a lot of advantages, but it's difficult for me to say the tooling there is infinitely better. I think a reasonable case could be made that the tooling is worse than any of the three I mentioned.

Clients don't care about what tools you use. They care more about flexibility.

Yes, doing complex things has gotten easier, mostly due to the improved tooling, but the number of things developers are asked to solve (for no real reason other that "it is now doable") have skyrocketed.

Why am I here bitching all the time? Because I don’t have it in me to fight someone at work. The underlying tension can be reduced to me saying ‘you know this is crazy right?’, followed with ‘you don’t get it because you are not a real programmer’, and alas, those are both fighting words from both sides.

To some extent, the tooling does make things harder than it needs to be; it's converged to a very strange local maximum that's very far away from the global maximum. The problem, I think, is a complete lack of integration along the entire stack. You write your code in a programming language whose source code is sent to the user to compile, and there are hundreds of minor variants on how the user will interpret that code. You have to defensively handle it all. But, developers want to reuse code, and those runtimes don't really support code reuse, so you have to bolt it on with a fake "compile" stage, where you concatenate all your dependencies together and split it up into chunks to be served to the end user's compiler at just the right time. The language that is used for these tools is a little on the outdated side, so this compile stage takes 30 seconds on one CPU core, leaving your commodity-grade 32 core workstation 96% idle while you sit around waiting. And, people don't even like this language for writing their code, so they write it in a different language that is compiled to that first language. After all that, you have code that can run on users' machines, but that's only like 30% of the problem. You have to serve that code to them, preferably from a datacenter that's physically close to their terminal. You have to serve them ancillary assets, like instructions for how to format the data your app interacts with, and images. Like the author mentions, there are a million different image formats, and you have to pick the right one for the end user, relying on a single line of text like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36". That's hard, so there is some service you can buy to do that for you, completely unrelated to that aforementioned "build process". The TL;DR is that there are hacks on top of hacks, and moving parts on top of moving parts, that it's a wonder it works at all. But we're in this state where we can't even fix it, because there is no one party responsible for the end-to-end experience. All you can do is bolt on more and more components and hope that you get closer to a local maximum.

The takeaway is that in a distributed system of glued-together components, no one entity is responsible for the success of your users. And, those that manage to build success for their users will do it all through very careful glue, that can come apart and blow up at any time. That means they have a never-ending job that consists only of unnecessary toil. At some point, the person that decides "FUCK IT" and throws this all away and builds some sort of integrated experience is going to make a lot of money. But there are many lifetimes of work ahead to achieve this goal, and you'll be dead before you finish, so why even try? That's where we are. Good luck.

I am sorry to spam, but this is exactly the problem intercooler.js and now htmx were designed to solve:

https://intercoolerjs.org/2016/10/05/how-it-feels-to-learn-i...

90+% of the websites being built (and 90%+ of 99% of the websites being built) could use a much simpler, traditional HTML-oriented REST-ful model at a fraction of the complexity of frameworks being used today.

Edited to add:

Years ago Solaris10 converted the rc boot scripts to what was systemd precursor, SMF. I drank the koolaid, yes! we can build dependencies now, we have service-level kernel events now! I can get rid of daemons and watchdog scripts now! The innards of SMF was indecipherable XML, dependencies grew, you could no longer find a good system view when you ask SMF, and you couldn't easily find and fix what's wrong with the service file. At the time, it was designed to be un-messed-around-with by keyboard-happy warrior greybeard sysadmins, judged to be a source of instability and inconsistency.

Programming in YAML sucks. YAML based solutions will always come up short because you cannot develop proper abstractions so you end up with a big bowl of copy-pasta amd indecipherable work-arounds.

IMO the modern web is all based around adding types to systems because we've realized the extra toil types require make large systems have fewer bugs and more maintainable.

i am still not happy with yaml, but i haven't seen any better alternative than saltstack yet.

cloud development kits seem to target cloud APIs only and don't look like they could work for just a bunch of computers

Wait until you see Spring Boot.

In 2010 I could search a terabyte of logs with grep -F in under a minute. With a "modern" setup you can't even see your logs until you have Elisticsearch up and running.

Or XML, you need to have written a parser (or pay Splunk to do it for you), you have to know how deeply nested your param of interest is. AFAIU Splunk has problems with too-deeply nested JSON, it was written at the time of unstructured logs. I can say this with confidence, for most of my problem cases, a good start to finding the culprit was a good tail -f and grep. I doubt myself and frequently ask if I'm one of those idiots who'd rather have faster horses. I mean, those are brilliant people making money hand over fist with their log analytics and event management tools, they know what they're doing, right? Right?

When you need to spend a few hours just to get the development environment somehow ready before first line of code is written, you know things aren't going the right direction

Nice summary. While I understand that yarn was a good thing to integrate frontend dependencies management just like we do it for the backend, Webpack is still a mystery to me. Just trying to add a simple JS library to make it work is a headache sometimes (DataTable with Rails for example).

It works out of the box, is uber fast, support Vue + React and does everything webpack did for me.

I stopped thinking about my tooling and could go back to spend those CPU brain cycle on solving my clients problems.

Peace of mind.

Thanks Evan You.

Check out parcel! Zero configuration required, just add a couple of commands to a package.json and you’re off.

The whole project of graphic design has the same kind of abyssal qualities as other arts with a technical element - you can always go deeper, more specific. And in a competitive market it's really tempting to sell yourself on one-upping the techniques of others. With a computer in the mix, you can just add specification without end and it will soak everything up like a sponge.

But each layer of that you add gets a little farther away from "creative medium" and a little more towards "bells and whistles production". The essence of it comes from the content, and this is true of everything on the Web too, despite all the interference on and around the platform. So it's more like a case of modern development being "you have to describe the medium you want to work within" because the base layers are this morass of vocabulary that isn't conceptually coherent.

The only problem there is that users have come to expect certain UI elements on any given web page and those things are far beyond "content". For example, let's say you want to allow comments on articles. Now you have opened an enormous can of worms by requiring logins, storing of passwords (hashes! with salts! using modern algorithms!), permissions management, password reset mechanisms, collection of emails (for password reset), and personal data.

You can handle all that the old fashioned way and implement it yourself or you can look into the great wild of the Internet to see what solutions already exist. That's where the rabbit hole begins!

Now you've got a back-end OAuth infrastructure supporting your website. You're using a login module that you were able to "easily" install via npm. You used an oauth2 module in your back end and everything seems to work fine except now your JS code is getting a little crazy with all the "time saving" npm stuff you're using so you start to look at "bundlers" like WebPack...

Welcome to hell, my friend. This is modern "minimal" web development.

Oh but perhaps you could use a static site generator instead! Surely someone has created the perfect Markdown/ReStructuredText tool for generating your perfect web page that has all the features you need!

There happens to be one that's close. It does everything you need except that one little thing. So you reach into the npm bucket... Then you end up having to deal with bundlers again.

It never ends!

Usually I visit pages to see if the content is worth my time. If the 'UI elements' somehow contribute to that content, great. That's rare.

Most pages I hit are hiding poor content in swathes of katchi-vatchi. Do I really care if the headline slides down that big photo? Am I really going to scan those glaring sidebars?

Once again I sigh and mouse-up to Firefox's 'Reader view' to cut through all that bandwidth-wasting crap.

And I think if there's a future here it belongs to targeted protocols that decouple the use case from the UI, and filters like Reader view that reformat content to the medium the user wants to work in.

There are certain things that basic HTML/CSS simply cannot do, or if it can, does so in a very hacky way. For basic websites, you can absolutely get away with more basic templating, but as soon as you enter the territory of clean looking UI components that are both visibly appealing and functional, you are basically required to implement the complexity somewhere the choice of framework then is just determining how you want to structure that complexity. When you try to make a performant web application with a lot of interconnected, moving parts, the reason for a lot of the "bloat" becomes very apparent.

If I need to let a user sort a list of items, is it more UI/UX friendly to make them press a button multiple times until an item is in the right place, or is it better to let them click and drag the item to the right part of the list?

The latter requires a lot more work but makes the experience a lot smoother.

Have you looked at a modern airplane? Have you followed from year to year the evolution of its lines? Have you ever thought, not only about the airplane but about whatever man builds, that all of man's industrial efforts, all his computations and calculations, all the nights spent over working draughts and blueprints, invariably culminate in the production of a thing whose sole and guiding principle is the ultimate principle of simplicity? It is as if there were a natural law which ordained that to achieve this end, to refine the curve of a piece of furniture, or a ship's keel, or the fuselage of an airplane, until gradually it partakes of the elementary purity of the curve of a human breast or shoulder, there must be the experimentation of several generations of craftsmen. In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness. -Antoine de Saint Exupéry

By the time you actually do a redesign that would take advantage of the fact you use mixins, css variables, etc., the whole design language changes, and meanwhile you'll have to change preprocessors anyways.

This sums up how I feel about my entire career as eloquently as possible.

Outside of a few complex SPAs doing interesting things, structurally we're building the same things we were building back then (blogs, brochure sites etc) — it's just that the way we're building them has become (optionally) much more complex.

IE 5 and 6 and Netscape Navigator 4 would all beg to differ. Having made simple websites two decades apart, CSS is much less hassle nowadays.

I know enough of Web FE development to jump in and fix a couple of bugs when needed, and on my own consulting gigs as side job, I only do native desktop development as kind of therapy.

Personally I think of the web as a highway: great place for a billboard, not such a great place to be storing or mutating sensitive information.

Most websites could be a simple WordPress do. Many brochure websites should be static. There are benefits to straying from that, but they come at a cost.

I love articles like this that put into words what I am feeling but am not articulate enough to put into my own words.

As a solo dev I relate to this frustration with over-engineering but I can imagine its benefits for big teams.

They don't have to use compiled, minified and obfuscated css, vectorized graphics, and user-agent detected custom fonts

but if you don't, then you are unoptimized for other realities

websites in the past used system fonts, you can still do that.

websites in the past used low quality raster images, or high quality raster images. those websites don't look good at higher resolutions. conditional logic to fix those sites is messy.

you can still make sites like that.

Exactly how I feel these days.

Back in the day, this probably meant one of a handful of things:

* manually writing all the HTML and putting the inline styles there

* some kind of PHP thingy where you would be essentially rolling your own CSS variables

* some kind of Perl thingy where a verySmart dev is trying to maintain an entire CMS using only regexes

Today, the user could be "having inline styles" in one of 10,000 frameworks-- Vue thingies, React thingies, or perhaps a build flag in a Javascript thingy that spits out a CSS thingy...

On previous projects I remember the frustration of futzing with Webpack and Redux. Now it seems like React has matured and simplified nicely and Next JS is a beautiful framework with a great balance of flexibility + power with some reliable guardrails to work within and boostrap a basic React project.

I have to give him credit though, his web page has zero javascript.

Front-end infrastructure and tools design unfortunately does not attract the cream of the CS graduate crop (and even less so Front-End design work).

For some reason, cream of the crop CS graduates usually veer towards systems, compiler, DB, back-end infra, language design, back-end, ML, etc ...

But not front-end.

The net result: the front-end ecosystem looks like the first BASIC program written by a 10 year-old who just got his first computer: it's a mess, it's unprincipled, it's grown organically, it's driven by fashion and immediate business needs, it's an unmaintainable tarpit, and it's increasingly a nightmare to build with.

I'm just ranting, I don't know what the solution is, but I gotta say: the WEB in 2021 is in a very sorry state.

[EDIT]: and if I try to think of a root cause for this state of affairs, I believe a lot of the blame can be attributed to Javascript, a language which sort of gave the "slapped together quickly because we need something now, damned be the warts" tone for the entire ecosystem.

The difference is that with the backend, you have choice over what technologies to use. There's competition between languages and ecosystems, so a better more elegant one can replace a worse crufty one.

But with the frontend, there is no competition. You have to use HTML, CSS, and (roughly) JavaScript.

If, when the web had started, it had been based on some kind of primitive bytecode for rendering, that HTML+CSS+JavaScript compiled to, then we could have had language competition and better technologies today. But that's not what happened. Front-end is stuck with an old, crufty tech stack that simply can't ever be replaced. Back-end doesn't suffer from that.

Which is WASM! Well, sorta.

HTML+CSS is a soup of overlapping technologies that has accumulated into this tangled ball of mismatched paradigms from nearly 30 years of "generational" improvements.

I grew up with it from the beginning so I understand the reasoning behind it all. But to someone wanting to learn it from scratch, trying to decipher tables vs. floats vs. flexboxes vs. grids must seem like utter madness -- a layout language written by a truly insane person.

Agreed about the tooling, npm and node were basically hacks everyone kept building on - there is zero architecture behind most of it.

Ditto! All in good fun. 0:)

> it's a mess, it's unprincipled, it's grown organically, it's driven by fashion and immediate business needs, it's an unmaintainable tarpit, and it's increasingly a nightmare to build with

Can't tell if you're talking about front-end or back-end here; I've certainly seen both.

> For some reason, cream of the crop CS graduates usually veer towards [back-end]

Setting aside the implication that getting good grades in computer science is the same as being good at creating business value with software, I see two reasons:

1. academic inertia: old professors teach what they know (e.g. lisp) regardless of how useful it is in the industry. I bet a rockstar professor who loved front-end/UX would find the cream of their crop biased toward front-end work.

2. this very bias you're perpetuating: where a bright student looks into the world, sees front-end work derided, and so steers clear of it (and maybe even starts parroting this bias of those they respect, as youngsters so often do).

I don't know what the solution is, but it's definitely not whining. 0:)

I wrote my thoughts about this in a recent article: https://erock.io/2021/03/27/my-love-letter-to-front-end-web-...

>But not front-end.

im going to go out on a limb and guess that it's because non-mobile front-end work sucks. few people who have options would have it as their top pick.

I also miss the days when 10 year-olds wrote BASIC programs and had immediate business needs.

If you take a look at the labor demand for skilled front-end engineering (https://www.levels.fyi/), it's hard to come to any other conclusion than that major companies pay a lot of money for top talent. So if major companies pay a lot of money for that talent, either they're making profit from a very tricky coordination of skilled labor, or you're pulling an argument out of an opinion that is at odds with the reality of the industry.

Why do that? It could be that you're not familiar with how skilled frontend practitioners operate in large companies. Maybe that's why you're extrapolating (incorrectly in my opinion) that a) the web frontend ecosystem is trash and b) that is evidenced by cream of the crop CS graduates (???) choosing backend over frontend. My question is, what does that have to do with the reality of frontend today?

Maybe it once was useful to consider why CS graduates gravitating towards one end or the other, but that division seems a little old in the tooth now. Good CS graduates these days have full-stack chops, and don't have too much trouble crossing devops, frontend, backend -- anything necessary to get the job done. So with that said, it's hard to consider your final conclusion anything than a rant about your own difficulties and preconceptions about frontend web development than anything:

> The net result: the front-end ecosystem looks like the first BASIC program written by a 10 year-old who just got his first computer: it's a mess, it's unprincipled, it's grown organically, it's driven by fashion and immediate business needs, it's an unmaintainable tarpit, and it's increasingly a nightmare to build with.

It's true that there's a lot of the front-end ecosystem that is super messy. But there's a lot of it which works a lot better in comparison to what was available a decade ago. Moreover, it's intrinsically gotten more complicated as mobile compute has gotten more powerful. Mobile has not just become a thing but achieved critical mass on par with desktop. There are enormously lucrative challenges involved with front-end these days, and who knows how much headroom is left in the industry? The modern phone's capabilities today are so far beyond what was possible even four years ago, that it's hard to consider these kind of rants anything beyond a lack of imagination.

How is it that the largest megacap companies of our time are using better frontend experiences it to accomplish increasingly more revenue efficient activities than they ever have before? How is it that newly fledged startups are using the leverage of good frontend experiences to grow to $1B faster than they ever have before? Is it possible that UX and psychology account for far more of technology's value than you may be considering? Just a thought.