JavaScript archives
Compatibility
Thidrekssaga
QuirksBlog
Donations
CSS book
Politics
Mobile
About
COH
Via Bruce I stumbled upon this interesting Hacker News discussion under the ominous title “Is web programming a series of hacks on hacks?” Thingy’s law applies, so the answer is No, but it’s a qualified No, and we need to understand what we should do in order to avoid a future Yes.
Rather to my surprise the discussion was civilised and made good points. I decided to quote it extensively and jot down some of my thoughts as an old-time web developer who is a declared opponent of the framework craze.
Getting older is not much fun, but it has two perks. One is that you finally have some money, and the other is that you can complain about the youth of today. And I’m not going to let anyone take that fundamental right away from me! Also, my sense of humour is an acquired taste. You have been warned.
The user who asked the question laments:
Lately I've been doing some web development on a fairly long-lived and large code-base, but I'm finding it MUCH harder to wrap my head around than application development ever was. I think my difficulty is that the whole environment feels so... HACKISH... everything is a horrible hack on top of a horrible hack. [...] just the fact that it really feels like there's no consistent way to do anything, there are 1000 different frameworks, all with their own way of doing the most basic tasks, and my experience is that they all ... well... suck.
https://news.ycombinator.com/item?id=12477190
Promptly, people stumble upon the entirely wrong line of reasoning.
JavaScript - Dynamically typed, does not scale what so ever.
https://news.ycombinator.com/item?id=12477385
My apologies for the weird sound you just heard: that was me yawning heavily and straining my jaw muscles. Fortunately someone else was on hand to give the only proper reply:
What does this even mean? I see the phrase "does not scale" bandied about all the time. In what way is a language supposed to scale? It seems like its just the latest semi-technical hand-wavy way to disparage something.
https://news.ycombinator.com/item?id=12480787
This is followed by the usual discussion:
JavaScript sucks because it doesn’t copy some parts of your favourite languages. Therefore web development as a whole sucks. That is not the web’s fault; it’s yours. Get back to programming beans or something. (Or count them. I don’t care.)
Another user puts it more politely:
Javascript has never really been the language for programming in the large. But make no mistake about it, it's slowly getting there [...]. The issue from what I've seen is that people think it as if it's a class based language instead of the prototypical language that is.
https://news.ycombinator.com/item?id=12477563
I disagree that JavaScript cannot be used for large programs, but this user is spot-on when it comes to the issue. Class! Or rather, the lack thereof. Or the wrong kind. Of course this is answered by the same tired old argument:
This always gets trotted out as the issue. "It's not JavaScript that's bad for building large applications, it's just everyone is using it wrong." Prototype inheritance is even more brittle and hard to follow than class-based inheritance which is why developers, for their own sanity, try and shoe-horn it in.
https://news.ycombinator.com/item?id=12477590
My programming style is so much more classy than yours. (Did you get that pun? Did you? Did you? Cle! Ver!)
I saved the best advice for last:
JavaScript is both amazing and ridiculous all at once. Deal with it.
https://news.ycombinator.com/item?id=12480051
JavaScript! The most amazing and ridiculous language you’ll ever encounter!
I like it.
Of course the discussion also touched on frameworks.
"A framework to make Foo bearable" seems like a huge portion of the issue here. We have a bunch of tools so hideously unfriendly to everyday development that we have to pile framework on framework in an attempt to actually get something built in a timely manner.
And the result, of course, is an unmaintainable stack of dependencies and inefficiencies. Any time anything changes, anywhere, the whole thing falls apart again.
Security folks talk about "threat surface" - I wonder if it would help to have an idea of "development surface" to signify the risks of bloat and dependency chaining?
https://news.ycombinator.com/item?id=12480133
Sanity restored! I couldn’t agree more. The problem is not the frameworks themselves (though I dislike them), but the unconscious assumption that one must use them. Just learning CSS and JavaScript does not seem to be a valid option. Of course the root cause is people’s dislike of JavaScript because it has no class and the wrong kind of objects.
Also, there are way too many frameworks. Anyone who feels that front-end tooling is sane and grown-up hasn’t looked at it recently.
There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things. When first approaching this world you get confronted with alphabet soups of packages all combined to "make front end development sane". Everybody seems to have their own soup, though, and many claim that theirs is the way to do development.
https://news.ycombinator.com/item?id=12480418
Solution: ignore them all and learn some actual CSS and JavaScript. Of course nobody’s actually going to do that — shiny framespilekits! and web dev sucks! — but you and I feel a lot better now that I said it.
Also, an interesting counter-argument:
I really don't get this argument [...] I love the JS ecosystem and its Cambrian explosion - lots of ideas (good and bad) being tried out by other people[2] and the good ideas tend to be adopted by the more mainstream projects.
2. This is important - don't be the guinea pig and don't jump onto the latest and greatest.
https://news.ycombinator.com/item?id=12486035
The footnote is important. And I admit that something good might come from this Cambrian explosion of tools.
That set me wondering. The JavaScript frameworks of ten years ago led to innovation in web standards — querySelectorAll, for instance, was the standardization of especially jQuery’s custom of using CSS selectors for DOM selection.
What kind of innovations are the current frameworks bringing to the table? Turns out, when I asked on Twitter, there are a few. Web components, the concept of a virtual DOM, they were pioneered by frameworks. (Or libraries. I never understood the difference. Which is a mortal sin in some circles, so you’d better figure out which is which and why.)
So... is it possible that this Cambrian explosion leads not to more or better frameworks, but to more and better standards? Is it possible that this, and not the tooling itself, is frameworks’ major contribution?
I hope there’s an original (or just a good, non-original) idea here. Currently I’m not sure.
(Brownie points if you know what browser this header refers to.)
If not JavaScript, then what’s at fault? Web development as a whole?
Compared with other languages and technologies used for similar purposes, none of JS, CSS or HTML is particularly powerful or efficient, nor do any of them provide particularly good tools. [...] Suffice it to say that best-in-class programming languages [...] have all been doing everything JS/CSS/HTML can do and much more for a long time.
https://news.ycombinator.com/item?id=12477660
What a complete load of crap. HTML, CSS and JavaScript are best-in-class programming languages because they’re the only ones in their class. So deal with the entire class or go away. (Also, do you see how this comment managed to sneak object-oriented terminology back into the discussion? These people just have a one-track mind. And not even a dirty one.)
That’s not to say there aren’t any problems. But which ones exactly? This user knows.
The target environment is undefined. In most programming problems we start with with a well defined target environment (or at least the language semantics are well defined and we quickly learn where the platform-specific hacks are). In web programming each of the browsers is slightly different in about a hundred different ways.
https://news.ycombinator.com/item?id=12477967
Yes, a thousand times yes. I wrote about this ages ago, and it remains true today. The main reason back-end developers don’t understand front-end is that they expect a well-defined environment.
Instead, they get browsers. And browsers are the most hostile (and misunderstood) development platforms in the world. Not to mention being undefined.
This is exactly why I've always been puzzled by the urge to move more and more logic to the frontend. In backend development you have a choice of many mature languages, tools and frameworks which are fairly sane. I'll take that environment as the foundation of a web application any day and apply the mania of client-side javascript to it selectively in cases where we need to minimize server roundtrips.
https://news.ycombinator.com/item?id=12477659
But if browsers are terrible development platforms, why bother writing complicated client-side apps? Here are some reasons:
This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application.
https://news.ycombinator.com/item?id=12478419
- Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important [...]
- Responsiveness: the more that you can do client side the quicker your application will feel to the user [...]
- Partition resilience: if the client can keep working for a while without needing to talk to other hosts [...] your application can keep functioning.
The scaling argument is awful. What you’re basically doing here is offloading your server resources to every individual user of your site — who may be on mobile devices with a nearly-spent battery. That’s not front-end development, it’s dangerous nonsense caused by disdain for browsers, users, and front-end in general. These people should be banned from making websites. (And will they be banned? Hah! They’re considered best-of-breed rockstar turtle blahs.)
The responsiveness argument is what caused Jesse James Garrett to coin Ajax ages ago, though nowadays we add the offline capabilities that weren’t around eleven years ago, and that’s a good idea. (And note that they’re called “partition resilience.” Learn those big words, or people will laugh at you!)
I have never seen anyone make those arguments. I've seen people vaguely reference them in a hand wavey "I don't understand this but google facebook I am right" way. But that's as close as it gets. It is usually about following trends.
https://news.ycombinator.com/item?id=12479055
As was the case eleven years ago, there’s something to be said for this argument. But front-enders don’t say anything resembling arguments and have no clue why they need to do everything on the client. Instead, they’re too busy npmming the latest dependency thingies to their workflow setup module blah, because that’s how we roll, baby!
So let’s stop the framework madness. Let’s especially kill off all the fanboys. Extinction event, anyone?
I run into a fair share of developers out there who look at basically any proposed web app and say, "Oh yeah, this needs to be a SPA built with React." Why? "Because it's better" and then a rattling off of generic reasons that SPA and doing everything client-side are superior. This is basically the modern version of the Lisp fanboy, they find a good hammer they want to work with more and now everything they see is a nail.
These are often the younger guys who have not yet seen this pattern carry itself out over a generation or two of developers -- if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).
https://news.ycombinator.com/item?id=12477815
And why don’t we learn from older and wiser minds? I’ll get back to that later — and it’s partly the fault of said older and wiser minds.
This brings us to the root cause of the problems: front-enders themselves and their obsession with shiny.
What I found harder to manage is the young FE devs themselves: for them it seems every new project, or every new view in the same project, is the opportunity to use a completely different, new toolset. Oh, and some new syntaxic sugar candies supposed to "save" a couple of keystrokes (which is the worst reason you can find to use a new syntax requiring its own tools). I find this very dangerous, especially when the github repos holding these tools are 3 months old.
https://news.ycombinator.com/item?id=12477579
Perfect thumbnail sketch of today’s rockstar ninja web developer. Let’s hang a few to encourage the others, shall we?
Another user puts part of the blame on the employers.
This is because employers are demanding that candidates know the latest and greatest technologies (eg. looking for 5 years of experience in 1 year old technology). I'm an FE dev, and during my last round of interviewing 3-4 months ago I was asked about my thoughts on Redux, CSS Modules, Radium, Docker, GraphQL/Relay, ClojureScript/Om, etc.
If I need to be experienced with this stuff to stay employable because just doing my job isn't enough, then I'm going to learn it.
https://news.ycombinator.com/item?id=12480192
Maybe look for a job at a sane company where front-end knowledge is actually appreciated instead of buzzwordified? Granted, that may not be easy for some. Still, it’s at least part of the solution.
An employer reacts:
As an employer I would be negatively surprised if a candidate for FE never heard of react, angular, etc. But I also see a red flag of the candidate were to assure me to be knowing all of them bottom up. That would mean a lot of toy projects and unstable personality, if not plain lies. I'd be looking for someone able to work for some years on a code base, grasp its stack, improve the overall structure, quickly find and fix bugs in a sustainable way, etc.
https://news.ycombinator.com/item?id=12484588
But what would this employer think of me? I’ve heard of Angular and React — I even wrote a well-read piece about the problems with Angular 1.x. I never use them, though, and can explain why. Would this employer accept my application? Is knowing about them and having an opinion on them enough, or do you actually need to know how to use them? In the latter case employers may carry part of the blame after all.
Also, there’s an argument missing here. The main reason front-enders are in love with shiny is that they feel inferior to back-end developers with their mature environments and toolsets. In order to prove that front-end is also mature and serious we must concentrate on toolsets — the environments are not going to get sane any time soon.
So: Toolsets!
Tool! Sets!
Ninset toolja rockpile transstarrer is best in CLAZZ!
Shinyyyyyyy!
Another user points in another direction: money and people.
I don't really understand why is this hate against web development goes on HN. I'm building web apps for lots of years now and the major obstacles were never really the technology, but money or people.
Building UI-s in the browser with CSS is not a rocket science; a JS app is easily scalable to 100k lines of code; backend wise you need some good team and a sane PM who don't want to immediately scale your app to Death Star level. Projects does get fucked from time to time, but if you picked your stack well, you'll be fine. I admit it takes experience to identify the crap tools, but what profession doesn't?
https://news.ycombinator.com/item?id=12477980
That’s true as well. If you’re a brilliant front-end developer who can do without frameworks, but the project is on a crazy tight budget and deadline, what can you do?
Another user has ... not quite a conspiracy theory, but he starts with a valid argument and takes it a bit too far for my liking.
It does require huge companies like [Facebook, Google and Microsoft] to work with the web stack painlessly and they're behind initiatives to make it even more cumbersome. You could say that they have an incentive to hamper competition by screwing up the web and they're doing it well.
https://news.ycombinator.com/item?id=12478128
It’s true that Google, especially, is betting heavily on front-end, and that front-enders love to work at Google or other big companies because front-end development is being taken seriously as a discipline. Smaller companies who struggle to find good front-enders might try that as well, instead of treating front-enders as glorified designers or very junior developers whose main job is roasting Java beans for Real Programmers.
But alleging Google and the others are out to screw the web is a step too far. I’d go for “smothering with love” instead.
it's probably fair to say that the state of the art in front-end web development is between one and two decades behind the general programming community, and that many relatively inexperienced people working in the web field are slowly but surely learning the same lessons (and repeating the same mistakes, and repeating them again) as the rest of the programming world did before. One of the biggest problems, IMHO, is that quite a few of those people now work for influential businesses like Google and Facebook, which means quite a few even less experienced developers assume they know what they're doing. And that's how you get framework fatigue, left-pad, "living standards", sites and apps written more than a year or two ago no longer working in modern browsers, and other such madness.
https://news.ycombinator.com/item?id=12477660
This is interesting and insightful. For instance, Google acquired the habit of taking excellent ideas and over-designing them to a stunning degree — see Web Components, for instance; and let’s hope progressive web apps don’t go the same route.
Still, I think this comment misses the mark. It leaves out the main reason why front-end is so behind: Real Programmers With A CS Degree don’t do front-end. Front-end is for script kiddies and pixel pushers, it’s not to be taken seriously.
Also, front-end is hugely successful, and it’s easy to find jobs. Does that hurt the Real CS People? Does it give them one more reason to look down on front-end?
In any case, if you agree with this last comment and want front-end to become more mature, start helping us out. We’d love to learn about good programming practices.
Unfortunately Real Programmers don’t know anything about browsers and have no desire to learn. That makes them useless as front-end teachers. This problem, more than anything else, is what perpetuates web development as a hack of hacks.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
