Responsible JavaScript: Part I
alistapart.com
alistapart.com
I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent. There seems to be a very strong "if it's not new it's bad" sentiment[1], and as a result, the amount of churn is also extremely high. What's so "exciting" about doing more with less?
As an aside, it is good to see that this article is completely readable without JS.
[1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough" --- despite it working in more browsers and being over an order of magnitude less code than their proposed "proper web development" solutions. They are correct, I am not a "real web developer", but when I write JS it's usually because I have a problem to solve and don't have any other choice.
More on topic I think more context is needed on your anecdote. Was you developing a small tool that's likely to balloon into a suite of tools etc? There may have been a variety of other factors to consider whether it may be worthwhile investing into a framework in the long term
I'm not saying that your sentiment isn't at least a little true - but creating complex modern web applications is hard and frameworks CAN be the right decision depending on requirements.
I often hear the following versions: "that's not the current paradigm" or, "that's not recommended"
When I see these words, I think these are followers. They don't truly understand why they are doing what they're doing, but "everyone else" is doing it, so it must be good.
For example I went through software developer job listings in my area. Of 100 listings, 40 of them are React specific, 2-3 Angular while maybe 5 mention any kind of frontend development like html/css/jquery. The rest is classical back end positions. There is a HUGE demand for frontend expertise these days.
If you as a consultant want to sell yourself as a kickass rockstar frontend developer, you want as much React experience as possible on your CV. Some will even turn you down because of the fear of damaging their CV by just doing vanilla javascript work.
Thank you. As someone who only allows JS to run very, very sparingly (and even then only on sites that are, for one reason or another, actually indispensable to me), I appreciate this very much.
If a site requires JS to work, and if that site is something that is optional for me, then I won't use that site.
What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
1. you get a json object which you pass to a javascript function which re-renders the row's html and re-binds all interactive elements. 2. You get server rendered html from the server, which then leaves you to call a js function to re-bind all interactive elements.
some classic problems with this approach: 1. some rows data may depend on the data of other rows... now you have to sync client and server side state! (huge problem). 2. Remember that initial server-side view? guess what, all interactive elements had to be bound to the javascript handlers initially. Now you need code to initialize the view which is different to the one you use to do the partial updates. 3. Yes, I dind't even mention that we could send server rendered html full of inlined handlers as in "onClick=myClickHandler()". Because this leads to problem #2 right away.
I'm not saying React and friends are perfect, but it does solve all of this, at least IMHO.
> I wonder if there is a common
> mindset that the majority of
> web developers have which
> causes them to love
> overcomplexity so much
Another problem is the web is inherently complicated, and people expect more and more from the web. We’re still working out how to best manage the complexity and increased demands.
You now get to experience all bugs and side effects for all projects you now took on "due to ease."
You now effectively maintain all those projects, instead of your own. You cannot go to your customers and say "well this library isnt working so neither is our website, and we can upgrade without it."
And more importantly, NIH leads to on-boarding issues. Many, many people are React/Angular/Vue developers, but how many are $INTERNAL_RECREATION_OF_REACT developers? By creating a new framework, you waste money (not just on reinventing the wheel and fixing bugs in your new wheel, but also on having every new-hire take even longer to get productive)
The extreme aversion to "reinventing the wheel" leads to things like left-pad.
For developers want to solve a problem quickly, you are correct - and more power to you because no one else (mostly) can understand your code. Job security FTW there. I think most of companies starting to realizing they can't keep people like you very long. You are both capable and stubborn (most likely). That's why job market is shifting towards mediumly skilled team and process oriented developers. Hope that makes sense.
This is, in turn, is a weird mindset. Are you suggesting that web developers are somehow unique in the software development space? Here's a hint: they aren't. The problems that web developers have to solve are relatively unique to the platform. When is 1MB of code a lot? This is not amount of code written, this is amount of code used. In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat? Because it doesn't have to be downloaded over HTTP like javascript. That is a unique feature of web development. What do you think would happen if developers around the world started complaining about using `numpy`? It's the same thing with libraries like `react`: they have no credibility because `react` is useful. It has nothing to do with web developer mindset, everyone wants to bring in libraries that make their lives easier.
Because some random Joe Schmoe can't replace numpy with a few lines of vanilla Pyton.
Because numpy has a governing organization and isn't just an arbitrary library some unknown developer dumped on NPM.
Because numpy is over a decade old and isn't any in danger of being superseded on the basis of not being fashionable.
Is this really unique to (frontend) web developers? I've heard plenty of stories of people building tangled webs of microservices when a monolith would be fine, using Kubernetes to run their weblog, using Hadoop with small datasets, etc.
I've said this in code reviews a few times. In ever case, it was because someone was using some construct that would have been needed in older Javascript versions, but was no longer necessary in whatever deployment we were supporting as a minimum. Sometimes it was from taking old Javascript conventions into Typescript. In ever case, the original code was a workaround for old bugs.
Can you cite an example?
He was in a leadership position.
This way of thinking isn’t restricted to our industry. I see it in other areas as well. People naturally equate complexity with quality and actually have a hard time appreciating the beauty of a well-designed, well-thought out, efficient system. Why that is is beyond me.
Which is weird because, generally speaking, higher code complexity is a signal of lower quality.
Let's say your page has the following: - Custom form validations - Custom styled <Select> tags - Forms that should show full lifecycle on submit without page refresh (form accepted, form error, sometimes API's return a 200 that is actually a failure :-/ ) - Inline editing of some user data. - Badges based on your users activity. - Notifications of new items. - Navigation styling that is JS powered in some way, or un-achievable or kind of a schlep with CSS (maybe the links are API powered :-/ ). - A table with sorting/filtering - Drag and drop reordering - Some type of chat window
Now let's increase complexity and say all those things respond in some way to changes in the other things.
I've built that page. That page is no longer a website. That page is an app and apps need structure.
The developer alone didn't decide the page needed all that. Chances are the business thought doing everything on one page made a strong business case. The UX team backed it up. The developer maybe agreed because they want a challenge.
There's no way this trend abates until complicated UI's fall out of fashion.
If you have a site delivering mostly static content, obviously use the bare minimum JS.
However if you have a lot of reactive forms, interactivity etc, while it can be done with plain Javascript and HTML, I've seen way more buggy DOM manipulation/jQuery soup than not, even from experienced devs. Add in a large team working on separate features and code quality and UI consistency goes in the toilet. The frontend libraries at least can bring some structure and common patterns that can slow down this debt, at a library size similar to jQuery.
It's also important to remember you don't have to go all in. If your site is mostly static with a few highly interactive components, you don't need a SPA Webpack setup with a 50MB node_modules directory. Tools like VueJS can be dropped incrementally on a server rendered application, and you can "step up" in terms of libraries, common components and build process only as needed.
The React infrastructure ended up with more than 10000 lines of code, more bugs, and he spent at least twice the amount of time to deliver.
The main reason he failed, was that he over-engineered his solution.
It's just inaccurate to take the most complex thing you can create and act as though that's the norm; it's not. Websites still exist, and people are using the most complex tech to create those too.
A) The desire to use the right tool for the right job
B) The desire to have fewer, more versatile tools
It's understandable that people don't want to learn dozens of different languages, frameworks, and libraries. There is a real cost to gaining knowledge and experience with all those tools, and a real benefit to knowing a single tool really well.
On the other hand I often find more tailored tools can be much more powerful for their suited tasks. But then again it's also true that the scope of projects is always shifting, so sometimes you can outgrow the specific use case of a tool.
Anyway, I would say it isn't clear (to me at least) that our industry has a "problem."
I'm hard pressed to imagine WordPress having login forms done in a JS Framework, and that's a big chunk of the web. If they are doing that, then you're right, it's totally unnecessary. But I'm guessing the folks at Automattic are optimizing this stuff for their clients (but I concede that I could be wrong here).
As far as blogs in these tech stacks, if they're developer blogs then that makes total sense. A dev blogging about React would probably choose React for their blog since that's a live production laboratory for any React code. I had a website in Ruby on Rails for years because I was a Rails dev and it was easy to try stuff out.
Are there any concrete stats on actual mismatch? Do we know how many recipe blogs are using Angular or React? My guess is their bloat is from tons of scripts and not from a developer using a tool that is wrong for the job. That bloat is at its heart a UI/business problem. Analytics, pop-ups, sharing links, referrals and that entire class of web objects IMO opinion are UI/business concerns, and they'll continue as long as folks find those things valuable.
For data, look up often reported stats on JS size.
It's this type of detail that's really difficult to get right when you choose to opt-out of decades of iteration and do everything yourself.
Now, you said that by layering a SPA on top that an "even better experience" is provided. What exactly is the better experience? Just navigating around the site a bit I don't see anything particularly dynamic about it at all.
As for the better experience: faster loading and dark theme?
This paragraph has surprising links. "Managing text overflow" links to Shave, a library for truncating multiline text[0]. Last time I checked, CSS was capable of truncating single-line text, but could not truncate multiline text (the line-clamp rule is still not universally supported). The first link in that paragraph is to a flexbox polyfill, and obviously, there's a reason why people use polyfills.
I get the feeling that most of the time when people are complaining about unnecessary libraries they simply haven't personally run into the problem that the library solves yet.
Edit: (I rephrased this post) I understand that logic often makes sense to break out between presentational and container components, and I understand that sometimes api / service calls should be broken out into their own files, but everything I've read states that api logic should be called from ComponentDidMount.... you are saying that you shouldn't make api calls, from component lifecycle methods whatsoever?
I'm not sure what the alternative is?
Any links would be greatly appreciated.
I prefer redux-sagas because generators fit the bill perfectly, and they test easy, and I'm not a huge fan of Observables.
The components dispatch an action, and the heavy-lifting is done by the side-effects library that listens for that action, and does any API calls, as well as dispatching any more actions.
When I ask this question I'm just looking for any answer that displays some knowledge of separation of concerns. Surprisingly, so far only a few out of dozens of applicants have been able to do so. I should also point out that these applicants are not applying for junior positions and all have ~5 years of front-end experience on their resumes.
I'm also curious why my comment above has been attracting downvotes. Did I say something rude or controversial? (I'm not complaining, just curious)
That's just as shit imo, adding unnecessary complexity for the sake of adding it. If you are choosing a framework, you are betting on it, why complicate things. Might as well write in Vanilla JS at that point.
React has always been about making an abstraction layer of its own; to remove focus away from the underlying platform. A metaplatform, if you will. That explains the problems described in this article, it explains the desire for CSS-in-JS (which despite arguments for, is only popular in React and no where else).
So what we've wound up with is a generation of developers who are really good at the lego-block building aspects that React provide (which are valuable) but know next to nothing about HTML or CSS.
CSS-in-JS still requires knowledge of CSS, albeit a subset usually. The same could be said for JSX and HTML.
If you can work with React you can work with raw HTML/CSS. It's just you have all the problems that come with those that maybe some developers haven't had the misfortune to deal with.
The React workflow gives you a right sense of direction, where usually you'd be left on your own.
There are many developers who don't really know anything about the head element because its something their tools generate and they don't touch.
Yes, and what many developers started to realize is that this separation is not very useful (at least for proper web applications, as opposed to websites with mostly static content). Conversely, separating the building blocks of application into components where structure, layout and logic commingle is very useful.
I realize not all developers agree with eschewing structure/styling/logic separation. But many do and it's important to realize that they do so consciously and not because they don't know what they're doing.
Angular was one of the first (perhaps the first, not sure) libraries to move towards this direction. It brought a lot of accidental complexity with it, which is understandable as these concepts were only starting to be fleshed out in the web world.
Not saying this specific framework is going to be a success, but so far it both:
- Is mostly "batteries included".
- Indeed does create pretty small bundles.
That's a big IF right there.
You're dismissing the author's point simply based on one hypothetical. In general, the author is right. JavaScript frameworks are being abused and developers don't care about the download size of their web pages, and it's terrible.
If you're on a desktop with a wired internet connection, then yeah, it's not really going to matter. But if you're on a 3 year old low-end mobile device on a spotty 3G connection, it's significant.
https://medium.freecodecamp.org/a-realworld-comparison-of-fr...
So, if your state machine is complicated, the web app is also complicated. As it's so hard to modify even a small portion of a mess.