Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly pieced together, barely holding up, fast moving, unnecessarily bloated, and no care for longevity, robustness and discipline. Seems like every thing is on Youtube, no real good books (yeah, go ahead and search for "React JS" books on Amazon and see if you find something solid that is well praised). It's these 8 hour fucking Youtube videos that I need to watch and probably not remember anything. I watched one of those and its horrifying what kind of stuff these people are teaching. I am obviously generalizing, sure there are some really smart people involved in Frontend tech, but boy if you take a sweeping look from ten thousand feet, it ain't pretty.
Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this?
I've worked in front end and backend systems. I've worked with extremely high scale web services at FAANG. I've made videogames, and done data processing pipelines.
In general, I find that people will look at the domain outside of their area of expertise and say, "Holy shit, how do you work like this?" All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
I think the important thing to remember is that engineers are doing complex engineering at every layer of the stack. And that because of environment and targets they are building for, they've made some tradeoffs around their development.
>All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
This is funny because waiting for typescript to build is probably double or even triple waiting for my .NET project to compile at this point. I swear it gets slower every update.
> All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
This is a shocking argument coming from any front end dev. Since when is static type checking, working on serious big repositories that take time to compile, have proper architecture with hundreds if not thousands of programmers working on it comparable to 3 frontend folks working on a web application? There is so much wrong with this argument and haven't scratched the surface.
I think you have a fairly dated understanding of what front end is, it's scale, and the complexity of delivering an experience that's fast and well optimized.
These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.
I believe you might have a slightly biased view of what front-end development largely looks like. What you're describing is the type of front-end development that goes on at the organizations that actually develop these frameworks.
The vast majority of front-end development outside of that world is misguidedly trying to mimic that complexity on their static business informational page they maintain with a duct taped mess of bad practices everywhere.
Now if you take a look at development outside of front-end and go to some large non-tech, mid-sized, or small business you'll probably also find poor practices (from my experience), but nothing like the mess I see in these
same organizations trying front-end development now.
If someone is making a static business informational page, it’s significantly more likely that they’re using WordPress and jQuery than e.g. React [1]. Like, significantly significantly — 20x more likely to be using jQuery (which is on a full 83% of all webpages) than React, and 30x more likely to be using WordPress than Gatsby or whatever.
People on HN talk about React and friends because they’re building client-side apps that deserve full frameworks. But it’s absolutely not representative of most web development.
Perhaps, I've only seen front end projects at FAANG and personal projects. That said, my front projects have at least an eslint config and usually a CI/CD deployment strategy if not full on tests.
Do you ever wonder whether we cause the complexity ourselves. Did we need React? Flux? Graphql? Since we introduced these concepts we needed to rethink a huge amount of other stuff to keep it performant.
Compare the simplicity of jQuery vs a modern tool chain. Like creating a form. It gets pretty insane with React. And jQuery would be dead simple.
You have to stay on the bandwagon because it’s where the community is now. There’s certainly a lot more fun to be had remaking everything in React though.
The main advantage of react in my opinion is the reusability of components. Most developers are not artists and can't design aesthetic and ergonomic interfaces from basic web elements, whereas with react you can install a component library (like material UI) and effectively just focus on business logic.
I'm mainly a backend developer so can't comment on how this tradeoff works out when you have the resources for artistic UI/UX folks and reduced development pace.
If all you’re doing is submitting a form with Ajax, sure, jQuery would be fine. But I’ll venture that most frontend apps are at least somewhat more complicated than that.
My side project is a web app that lets you create music visualizer videos. There’s a ton of UI, state, complex interaction between parts, etc. If I weren’t using React, I’d be using something — but it would surely be another full-on framework, not a simple library like jQuery.
It’s pretty clear you haven’t worked on any modern front end site. Go and try and build any front end site demanded by most business owners in jquery. It’s not just bandwagon, it’s solving problems in the environment in which they are required with the tools that are present. It’s so incredibly naive to think the efforts of tens of thousands is all pointless if they just used this one tool.
The reality is that most front-ends at most companies don't require that level of engineering. Sure if you work at Netflix or Facebook, there may be a lot of "real engineering" going on but most people don't work at those companies. But the guys at these small companies want to feel special, so they reach for whatever the big guys are doing and try to implement it, regardless of need. The same thing happens with (insert your domain here). Like, we have a single webstore with 10k customers, we need a Kubernetes cluster etc etc because Google does it.
It brings a package.json and a lockfile into your repo. There's arguments to be made against NPM but it doesn't bring any diffent "crud" into your repo than Composer, Maven, Pip/Pipenv/Poetry, or any other package manager.
That's an odd comment to make, you just inadvertently proved their point. Most large web products are serious (?), have 'proper architecture' and hundreds of frontend developers working on them. Google products, Spotify, AirBnB, JIRA/Atlassian, Booking.com, Trello, GitHub.. you name it. You may also notice TypeScript in the first paragraph of the report, which is a type checker and has been enjoying massive adoption.
Not 'his', 'their', but yes, I agree that the projects being done on the web are hugely complex these days and have a rich set of building, linting, releasing, testing, etc. tools.
Please note that this is transfer size. So if some script like jQuery 1.X is 90kb minified, but compressed is like 30k.
That's why we shouldn't asking ourselves why some users using a 3rd party tools to disable trackers, ads (like PiHole) or even disable JS using browser extensions.
Javascript tooling is crazy. A couple years ago I tried to build an older Ionic app that nobody had touched for six months, and the build had just bitrotted. Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken.
I feel like the Yarn 2 package manager is a good move towards in making frontend development more stable (The "Plug'n'Play" feature allows you to store your dependencies in your repo as zip files, just in case), but a lot of libraries are still the wild west.
There are "boring" frameworks like Ember and Angular that move slowly and limit breakage, but they're pretty unpopular with many developers, despite being great for building products in an enterprise setting.
I disagree strongly about browsers; having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers.
> having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers.
This is precisely my fear [1]. I need something robust and will continue to work for a good foreseeable future.
Do you recommend Angular for frontend? I've just tried React and Svelte, but I am told to stay away from Angular as a giant beast.
The Angular team at Google can make whatever changes they want, but they are required to update 1,000+ internal Angular applications if they make a breaking change, so it's a relatively stable framework. There's a new major release every six months, and upgrading is usually fairly painless.
It's fantastic for large applications. I've used it in a large product with hundreds of pages and forms and dialogs, and it would have been a nightmare without the sort of structure that Angular provides. It reminds me of Rails a little bit, in that it's opinionated about how things should work and you might feel some friction if you try to do something unusual.
I've found Angular to be more effective than React at companies with a "developers are cogs" mentality. Angular has opinions about how things should be built and there is a lot of supporting material out there on how to do things the "Angular" way. It's much more heavy weight that React because it's a more comprehensive tool whereas React is just the rendering portion. If you're the type of developer who can push the boundaries of what's being done on the web, you'll be happier with React or other tools. If you want to just follow instructions and tutorials online for how to build a website use Angular or even a CMS.
I definitely second these comments. The app that I maintain at work started with Angular 5. We're now on Angular 11, but upgrades have never been an issue!
I also like how Angular can be quite easy to get started with when simply using two-way data binding without rxjs or some complicated state management library.
Not every company has access to devs who are proficient in reactive state management and functional programming. Angular work surprisingly well for the average developer.
> There are "boring" frameworks like Ember and Angular
I honestly don't agree for Ember at least. Enterprise development is prone to having apps untouched for years and once an Ember application gets that out of date, the route to getting it in date again is... difficult. Have seen with with applications on 1betaX versions, 1.13, 2.14 and no route forward without significant rework, which means they're largely incompatible with the ecosystem now.
> Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken.
The package-lock.json file and the `npm ci` command should take care of any issues like that nowadays. Yarn has also always had its lock file. I wonder what was the root cause here? Did your repo have some deps coming from some other registry than npmjs.com?
The situation with Clojure/ClojureScript is a lot more stable. Most libraries are pretty rigorous about backwards-compatibility. When someone comes up with a better approach, they release it as a new library under a different name instead of making breaking changes to the old one. You will probably still need to pull in some npm packages, but you can cherry pick those and keep it to a manageable number.
Unfortunately yes. In all my four decades in tech, code bitrots in the the web front-end environment faster than any other I've yet seen. The Javascript language in particular (and its ecosystem) remains a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and everyone's holed up in the throne room hoping a few trusted paladins will somehow decontaminate the rest.
> How do we get out of this?
Personally, I try to use as little JS as possible. CSS is in better shape and handles a ton of page-level behaviours, HTTP/2 has done wonders for round-trip responsiveness, such that server-rendered HTML still holds the productivity crown for building out MVPs and SaaS application interfaces and the like.
When I absolutely must write JS, I'll tend towards typescript these days, and minimise dependencies to the point where I hopefully have no node_modules/ or bundler at all.
I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!?
Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.
It’s an easy blind alley to blunder down on some platforms. If one’s package manager defaults to edge versions and you’re just getting standard with a new language/framework via a tutorial, for example, this is how you learn there’s an LTS release the hard way. Homebrew users on Mac are common victims, but similarly Arch Linux or FreeBSD may trap the unwary (and for more besides than merely Node)
C# doesn't have non-LTS versions. Java doesn't. C, C++, Haskell, OCaml don't. In OSes, Windows and Mac OS don't. I'm actually struggling to think of anything outside of Linux and Node that has this concept of "here's a major version that is marked LTS and here is a beta, but we're not going to call it beta, we're just going to call it an odd-numbered major version".
When Microsoft calls a version of Windows "LTS", it means "this is an old version of Windows for which we're going to keep releasing security updates for the next 10 years", not "all more recent versions of Windows should be considered beta quality software".
I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.
Debian Sid. Anything with a master, edge, or nightly release. Safari Tech Preview, Chrome Dev Edition, Firefox Developer Edition. FreeBSD-CURRENT vs FreeBSD-STABLE. And every network or storage operating system I ever installed on a switch or router or SAN head or other appliance came in a variety of release trains, from Experimental-Will-Crash to GA(T) and every shade in-between.
> "another offender"
Be careful, it's a nasty fall off that high horse.
and re. these earlier remarks:
> Windows and Mac OS
Windows and Mac OS most definitely have experimental/preview releases and standard releases. Microsoft offer extended support options, and ultra-marathon ESU contract support for products as far back as Windows Server 2008.
Same goes for most commercial RDBMS. Heck, even Oracle has a preview release.
> anything outside of Linux or Node
Linux stopped using alternating version numbers in 2004, so I'm afraid your information there has passed even Microsoft's extended support period. For the curious, though, GNOME still uses the even/odd versioning as a lifecycle indicator, but has plans to abandon it this year. I hope Node will do the same, because of all the numbering styles this is certainly the most confusing.
As for Java, only a dyed-in-the-wool government bureaucrat could possibly love Java's approach to ecosystem engagement. "Let's have seven years of committee meetings and experimental feature flags for the new GC". Ugh.
Standing back, this just sounds like a grumble about terminology, because almost _everyone_ has some kind of leading-edge release and some kind of stable release, the only difference is the naming, and that doesn't seem to me the basis of a substantial complaint. If the core issue is inconsistencies about which one is installed by default, then that is a complaint I'd suggest best leveled at package managers, because there is no universe available in which every software project is going to somehow magically converge on a single lifecycle policy.
You are missing the point entirely. All of those examples you've listed are clearly marked in some notion of "prerelease". Even in the FreeBSD example, you're going to see that one version is labeled in such a way to make it sound safer. "Long-Term Support" labelling of one version says nothing openly about the unlabeled version.
It's exactly the lack of label on non-LTS versions I'm talking about. It has a real impact on people, looking at which version to install, and having no guidance that "this version not labeled in any special way, yeah, probably don't use that". And no, digging into the developer mailing list to figure out what the versioning malarkey a particular project is using is not a documentation of it.
Oh, no, I see the point, I just think it's an unproductive nitpick about an ultimately superficial complication. Labels aren't irrelevant, but they're pretty lacking in substance, and there are plenty of aphorisms about people who make assumptions based on surface details.
What's more, this gripe alone won't solve anything, since no-one is going to conform to anyone's expectations but their own in regards to release policy.
I work front and back end, I've seen frontend done the "simple" way but not often. The syndrome I'm observing is that guys are chasing the next thing so they can bump up to a better paying job, and nobody is ever worried about maintaining their flaming pile of garbage long-term. When new guys come in to find someone else's trash code, they always need to rewrite it in the new thing. It's really no that hard to use modern tools tastefully and with restraint, but it's so rare to see.
I consider myself to traditionally be a backend engineer, though this has more been something I fell into rather than chose.
I admit I feel I share some of your frustrations. In the past I have written production frontends in Angular and experimented with Vue and React. Out of all of them I found React to be the most enjoyable, but even then I still struggled with project setup and found the tooling confusing. I even quite like TS as a language, but I feel it's still quite limited by the fact it transpiles to JS.
Recently, I discovered yew [0]. It is a Rust framework for building frontends using wasm. I really appreciate the robustness that Rust brings such as ownership checks and ADTs. I don't think it's for everyone, but it may be worth looking at if you perhaps find modern frontend development confusing frustrating. I've found it to be quite the breath of fresh air.
If you do decide to have a look I found the examples [1] and getting started guide [2] very informative.
I think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.
Maybe,but it's not the kids who sit at the top of the food chain in places like language committees, standard agencies, or even the CTOs of this world ( the real ones,not those of 5 person startups) where things get decided for years or even decades ahead.
I'm not blaming kids. And the constant churn is not a bad thing.
Next time I build a team, I might consciously choose a mix of stable experienced senior devs, and perhaps a couple of young ignorant-but-brave junior devs. Horses for courses.
How is JS and it’s ecosystem any less mature than Go or Rust? There’s a plethora of mature frameworks, build tooling and patterns on the frontend as well as a lot of cutting edge competition that creates a lot of noise.
The point is though that there’s just a lot going on in JS world. Doesn’t mean it’s any less than any other language and it’s ecosystem.
The bar for participation is dramatically lower for JS. I think that's unequivocally a good thing, but it does lead to explosions of libraries and toolchains of questionable quality which iterate rapidly. There is SO MUCH JS stuff out there that even just the bad stuff greatly outnumbers what you have in Rust or Go. It's the same reason why PHP has such a bad reputation. It was used and abused by non-developers just getting shit done for years that if you casually looked around the PHP world 10 years ago everything looked like crap. Quite frankly I'm over the elitism that so often accompanies these discussions where people ignorant about how other domains work make huge assumptions about the quality of said ecosystem. It's classic Dunning Kruger.
If you’re developing a library that people use, it’s not because the bar is “low”. An amateur engineer doesn’t develop popular or useful technology overnight.
Do you remember when you could rent a physical machine somewhere and have something running in 5 minutes? We moved to something more verbose to support the new volume of the internet.
The same has happened on the front-end. I consider some front-ends, like Twitter’s, applications just as I do iOS or Android.
You can get out of this by using jQuery. It still works.
I can't make any promises, but many js engineers have found that clojurescript together with a framework like re-frame seems to offer a different mental model they find useful
I think at its core, the issue is that the code has to run in many different types of hostile environments. At least now we can sort of assume what features of the language are available, but you still have no control over the browser, OS, memory, or bandwidth available. There's no getting out of it :)
Sure, there are a lot of warts. But it feels less mature because it is less mature. Consider that you’re coming from a domain that’s three decades old into one that really only started gaining steam in the 2010s.
Yep, I've resorted to that. But, there is more to docs that's needed to get wisdom from others who've built large apps and getting that in a concise book format would be nice. Otherwise, we can all throw away all books written about any programming topic, right?
Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this?
/rant