The Cost of JavaScript Frameworks
timkadlec.com
timkadlec.com
Leaving bytes and bundle weight aside, in 2020 JS frameworks like React are far and away the best approach for front-end engineering from a large organizational standpoint.
1)Not difficult to hire for. JS frameworks are currently in the sweet spot where they're both widely popular and "cool". Consequently it's not hard to find good candidates. That wasn't the case 5 years ago where React/Angular developers were still uncommon.
2) The HUGE and helpful community of developers. There are so many excellent resources for learning and solving problems with JS frameworks. JS developers are eager to show off on medium and similar sites. I've never seen such a large and enthusiastic community. This will inevitably subside as JS fall out of favor but I hope it doesn't for a long time.
2)Rapid UI development. The JS ecosystem make it easy to build UIs quickly that don't completely suck and look good for the ever-important demos to senior leadership.
3)Opinionated frameworks naturally enforce best practices and ensure relatively consistent architecture. This makes it easy to move engineers from one team to another and make grokking new codebases a lot easier. New engineers are productive quickly and begin creating value for the company. This was not the case with the inevitable jquery monstrosities that resulted after a critical mass of code or # of engineers.
4)Fewer bugs. JS ecosystem makes it very easy to write unit and integration tests.
Companies with IT budgets that are 9+ figures will happily pay for extra bytes across the wire in exchange for those benefits
At my office, we've somehow ended up with a critical graphql server that's written entirely in Kotlin, which is cool but completely impossible to hire for or get any kind of community support for it. It feels like absolutely everything you want it to do, you have to do build yourself, whereas if we'd used a normal off the shelf graphql server it all already exists.
I'm so sick of maintaining old weird forks and unnecessary custom code that doesn't need to exist.
Of course you shouldn't be doing that, is the thing, but that's how most job ads read.
Kotlin is fine, and GraphQL is fine, but when you combine those, you have a very small niche.
GraphQL and (Kotlin or C# or Java or Scala) probably isn't that small of a niche.
Edit: Also, Kotlin does have near total compatibility with Java and can use any Java library (aside from the most magical bytecode-rewriting annotation processors) so I don't understand what you're saying about having to rewrite things that exist.
Recently, I've been spending it on Vuejs/TypeScript (with Go backend) at a company that uses React/TypeScript, GraphQL, Rails/Ruby, and Go.
A 3MB bundle size instead of 1MB does make a difference, and if you're working on the kind of site that relies on conversions/purchases to succeed then you're absolutely leaving money on the table. Not to mention that Google factors in page load time to rankings.
> our UX was worse than our competitors
If your competitor has a < 1MB bundle and yours is 3MB then any user on a low end Android phone is absolutely going to have a worse UX experience. Maybe stakeholders aren't aware of all this. Maybe you should tell them.
It's like all engineering: use the right tools for the job. If low-end Android users are a significant portion of your target audience you have to design your system around that.
SEO. Google also takes into account page / paint times.
These are the things your stakeholders probably don't know about but you should.
It's all about picking the right tools for the job. If low latency is a business requirement by all means don't use a framework.
But otherwise, I think you tend to be right, in a lot of areas even an extra second of latency doesn’t matter, and more features will move the needle more.
T1's maximum data transmission rate is 1.544 megabits per second. [0] While 3G's theoretical maximum is 21.6 Mbit/s for HSPA+. [1]
[0] https://en.wikipedia.org/wiki/T-carrier#Transmission_System_...
As cloud costs become tougher to swallow, this is going to change.
At a guess, I'd say that a webapp for a financial services company is going to be loaded once then interacted with heavily? Single Page App model. In that instance the time taken to download, parse and execute JS upfront isn't a big deal. Same as Gmail: when it loads, it takes a couple of seconds, then I leave the tab active for who knows how long. Plus in this situation the audience is relatively monolithic: a lot of desktops, and most of them fast.
The problem is people taking lessons learned in that environment and applying them elsewhere. Shopping sites, news sites, essentially anything that people arrive to from a Google search pay a much bigger price for a giant payload. Users can and will leave your site if it's taking too long to load. They'll be running on all kinds of devices, including low-end Androids with very underpowered CPUs.
Whenever I see a site like that implementing a full React page with Redux and who knows what else bolted on, I cringe. It's not an appropriate use of tools. But these days people only look at developer productivity (we can add so many more features so much faster!) rather than focusing on the experience in the user's hand.
I don't think JS will fall out of favor for a long time.
Languages that compile to wasm are unlikely to be competitive until native dom access has broad browser support, which could be years. On top of that, compilers will have to be written to do code splitting and compile times will have to drop.
Languages with strong type systems are unlikely to be competitive because TypeScript is good enough that JS projects are now manageable.
If someone is good at JS why not hot hire him? Wouldn't a professional be up & running with ANY framework you throw at him in a month or less?
But, I wouldn’t work for any company crazy enough to hire me as a modern front end developer.
Tech like Blazor and related asm.js type thinking will eventually replace JS when it bypasses asmjs completely and ships bytecode that the browser executes directly.
I doubt these frameworks will be much different compared to what we are doing today, because we will still need to deal with layouts, alignments, the color and shape and proportion of things, event handlers etc. The usual stuff.
Ragging on React, Vue, Angular is misguided. These frameworks allow developers to write front-ends as if they are applications, because in a lot of cases, this is what the modern "website" really is. They are training the next generation of front-end developers much like how jQuery did in mid 2000s.
Why not use JavaScript itself for this? That is the strategy employed by Next.js/Nuxt.js/Sapper/etc. Your React/Vue/Svelte components are rendered on the server and then hydrated on the client.
Same reason we didn't settle with everyone coding in C. Or C++. Or Java. Or Python.
The web is just a method of distribution. Not every problem or domain takes equally well to each programming model or language. It would be nice to be able to pick a tech stack that works for my domain and the characteristics of my project, rather than picking a tech stack because of how users access it.
Unless the other thing you target instead is similarly well-developed, you're gonna have real trouble with accessibility.
I think you are looking for Nim. It compiles to assembly (through C), javascript, wasm and more.
Start-up times are an issue. But once warmed-up the JVM is very performant provided tuned well.
> Except Java is extremely performant and if your engineering team doesn't know exactly what they're doing there's often a good chance they'll both use more time and create a slower product with a low level language as far as I know.
So agreed that it'll probably take more time if the team doesn't know what they're doing. But as for slower product? Ehh I think that was the point GP was making; Yeah, its' an overenginnered product that results at times, but it's got just enough guardrails that you hopefully just get a slow, or at worst buggy product, versus a product that doubles as a loot box of future CVEs.
There are absolutely times when Java doesn't cut it but at that point your options are getting increasingly limited in many ways: who can build and maintain it, what kind of languages and libraries you can use, the hardware you use, tuning etc.
I want to pick on the up front assumption though. He lists 4 costs that are paid -
---
The cost of downloading the file on the network
The cost of parsing and compiling the uncompressed file once downloaded
The cost of executing the JavaScript
The memory cost
---
What isn't mentioned is WHO'S paying those costs. And I think that generally matters when you're trying to convince companies with a profit motive that they're doing the wrong thing.
My issue is that of his 4 costs, 3 are all paid by the consumer of the product. The ONLY cost paid by the company is the extra network traffic to download the JS bundle. Even that can be optimized to a VERY small number if you're using good caching and have a cdn in place. The individual consumer might still wait for that network payload, but the company's objective cost is still going down.
So in general, what's the compelling argument that I should care about the rest of the article? None of it is bad advice. It just seems that the only real benefits I might get are two user features
- Faster sites
- Better battery usage
Users like those things, but they don't put them anywhere close to the top of the priority list for most products.
So I'm really walking away from this seeing a savings still. As a developer, I don't really love that opinion (I want to make good products that are fast and and small), but as a company stake-holder with a lot of possibly things to prioritize... This sounds like bad advice.
As a user I thank you.
If you think you're better off without a product, don't use it and let the market work itself out.
Frankly, I mostly even agree with you. I rarely install more than 5 or so apps on my phone these days, and I visit a pretty paltry number of sites consistently, but that doesn't mean someone, somewhere, isn't getting value from those products.
One man's trash is another man's treasure.
I just checked, my boss is making me use slack, and nobody is writing a non-electron competitor to slack...
On Wednesday night, Anna (9 years old) said that Epic Books wasn't displaying properly (Chrome v49, WinXP). She wouldn't even have a computer if it weren't office trash a few months ago, and I brought it home to give to her. Now she depends on it for homeschooling during the lockdown.
Epic Books tech support insist that they will not provide support for old browsers. Anna has homework to do. Should the school district provide laptops? Someone has to make a decision about what hardware is needed for thousands of students.
Why does the school district need to spend $100k on brand new iPads? Because Epic Books want to use the latest JS framework.
>Why does the school district need to spend $100k on brand new iPads?
Because the school chose to use Epic Books.
But the child will be punished if they don't do their homework. I think that's a grave injustice. It's not her fault that the school didn't provide the tools. We should be encouraging people to learn when they want to, not making it hard for them!
Healthcare is another area where there's a complex client relationship between doctors, insurance companies, and patients. I really think that developers in education and health are doing important work to save lives, but the capitalist approach of prioritising the person who pays isn't that simple.
With those fields, it shouldn't be just about money. On that note, I liked this comment yesterday: "hey, will you help me move? I'll pay you $21.58 for your time," I'd probably bristle. Even though that might be the equivalent price of a few slices of pizza and a beer" https://news.ycombinator.com/item?id=23106932
The decision that harmed the child was made by the school. The entity that has the power in this situation is NOT company selling the product, it's the purchaser that chose to use them.
The school is the immediate and obvious place to resolve the issue, and that's why the school is responsible for the new costs (or alternatively - Choosing a new provider).
I think it's an incredible oversimplification to assume that a company is updating "just because", and that they've done it without any consideration.
I'm not bullshitting when I say I've seen multi-year discussions about when/where we can afford to drop support for a particular devices/system.
It's a constant analysis of
- What does the upgrade buy us?
- What does losing those users cost?
- What relationships will be damaged?
- What impact does it have on company morale?
And the answers to all of those questions vary over time, as the user base changes and new systems are released.
Basically - I promise the company acted in a way that they believe will help themselves and their customers most. They might be wrong, but who cares? No one is omniscient, we're humans not gods.
So does updating happen to hurt this one kid on an older device? Yes. No on is happy about it, but they believe that the compromise was justified by the benefits it brings to all their OTHER users. Who they are also responsible for thinking about.
----
Now, I strongly agree that products that are purchased by people who don't use them tend to be inferior. But again, I find it hard to blame the developers of those products because the unfortunate reality is that when the person buying and the person using are different, usually the buyer just comes in with a checklist of "features" and selects the product that checks the most boxes. That means the company selling the product is forced to act in a way that checks boxes instead of making happy users.
But again, the solution to that isn't to blame the developer - The solution is to make actually using the damn product a requirement of the purchasers job description. And again, only the school can do that.
Now, the final ugly bit of this is as follows - You cannot wave a magic wand and make all problems disappear. There will always be better/worse outcomes for different parties after a decision is made. Maybe the school purchaser DID actually use the product, and DOES actually want the features a new upgrade brings, and has done exactly the same calculations for their school district that the company made, and has STILL decided to use that product even though it happens to hurt you, because they believe it helps more folks.
I can't help you with that, but it does bring to mind the quote from Churchill
>Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.…
It's a shitty situation and if you know how to make it better, let me know...
The problem is that - as currently structured - your ideology demands that another party enter into an exchange or agreement that they don't believe is beneficial to them.
I don't actually give a flying fuck whether the "developer" you've outlined in your post is right or wrong with their opinion. They have the right to make and sell the product they believe will benefit them the most. Could they be wrong? SURE! And if they're wrong often enough or long enough they usually go out of business (usually... some caveats here around monopolies/markets/regulation/etc).
So I'm not really sure why you see an ethics problem. If it truly is self-serving and invalid reasoning, why not put your money where your mouth is and do it better?
Basically - Step up or shut up.
If you honestly believed that you would advocate for more qualified data oriented decisions about your software to ensure the decisions at present aren’t wasteful and inefficient.
And that’s what makes software unique: ethics aren’t of value in this line of work. Developers frequently make unqualified decisions for their own self interests in conflict to their employers profit motive and in conflict to their user’s experience. If ethics were important you would serve as an advocate for your product as qualified with evidence.
Consider the difference if your medical doctor acted primarily in their own self interest for profit instead of primarily in the interest of your health. Consider how that same reasoning can extend to software developers who produce poorly tested medical equipment.
Yet somehow this reasoning seems to have offended you. I am unclear as to some ideology that you speak of.
Good luck with life buddy.
users don't care because they can't. the can pick battery life when they buy their phone (at the expense of important features), but they cannot optimise at any time thereafter. most people who would care are rational and since they can't they don't
therefore, it is browser and os developers who need to act to stop these costs being externalised. show current battery consumption rate for this app/page in the status bar. then, people will start complaining about dirty webpages
On the job, most developere care about shipping on time and spending less time rewriting things as they learn via experience.
Anyone who avoids frameworks is going to be in for a world of hurt when they have to explain to their boss "I know the project is 3 months late but I saved 100kb in bundle size"
- people not being familiar w/ the chosen framework and being unable to figure out how to accomplish some of the deliverables
- wrong framework for the job
- analysis paralysis figuring out which frameworks to use
- using the framework wrong and then drowning in code debt
The point of the article, I think, is that there's a tangible difference in performance between _similar_ frameworks, but which isn't often considered when choosing frameworks.
You'll often see developers say that they prioritize developer experience over things like runtime characteristics of a framework and there's a lot of handwaving about "maintainability". This despite there being extremely complex apps out in the wild written in obscure frameworks (e.g. lichess uses mithril.js and the code looks just fine).
There's clearly a disconnect somewhere when, for example, facebook announces a homepage redesign using the latest and greatest tools and immediately people start complaining about its performance.
I would not buy a slightly wobbly table from a carpenter that wants to use a more ergonomic hammer, over a not wobbly table from a carpenter that uses a cheap hammer. Similarly, I think what the article illustrates is that a developer should also act like a craftsman and critically think about the effectiveness of their tools in terms of end results, rather than blindly accepting tool marketing/status quo and disregarding the quality of the end product.
Would customers be willing to buy a cheaper table that's wobbly vs a more expensive table that's not?
At the end of the day, the wobbliness of the table is a result of whether the carpenter cares about table wobbliness more than which hammer they use. However, it may say something about the level of craftmanship and competence of the carpenter if they got suckered into buying a well advertised x-titanium-3000(tm) to compensate for an unwillingness to put in the effort to master core carpentry skills.
Another similar analogy is an audiophile buying gold plated HDMI cables for better sound quality, oblivious that the reality is that the signal going through said cable is using a digital protocol with error correction.
If you don't like it, stop using it.
You can't win, and there will always be a developer ready and willing to kick you while you're down.
Instead what happens is that the old developers built big things on-time so they were "good developers," and then the new developers struggle with the code and so management assumes the new devs are less competent.
Perhaps they failed to educate management on the consequences.
3 billion people in the world have slow Internet access and pretty old phones and PCs.
Many websites can be too slow for every day use and this leads to increasing digital divide and inequality.
https://github.com/tastejs/todomvc/blob/gh-pages/examples/va...
this.$todoList = qs('.todo-list');
const listItem = target.parentElement.parentElement;
input.value = target.innerText;
this.$todoList.innerHTML = this.template.itemList(items);
const elem = qs(`[data-id="${id}"]`);
if (elem) {
this.$todoList.removeChild(elem);
}
listItem.className = completed ? 'completed' : '';
target.dataset.iscanceled = true;
This is just one file. The point I'm trying to make is that this direct DOM manipulation makes for brittle code and only works for very simple cases. Once you have even a small amount of behavior, any sane developer will want to abstract it out a bit and you'll end up with a framework anyway. Better to choose a low overhead one from the beginning.
A randomly sampling is better.
I am more curious how much frameworks cost at development time. Framework advocates always claim their pet framework makes development so much faster and cheaper but there is no data on that. That begs a few questions:
Do frameworks reduce hours of labor to build an application? If so how much?
Do frameworks lower the maintenance expense of a given application? If so how much? That number should include any sunset or revisions due to changes in the framework not associated to changes in the business requirements.
Do frameworks reduce the team size or business support staff to ship an application? If so how much?
Do frameworks lower developer hiring expenses and wages? If so how much?
It would be good to change this, yet, software engineering is a very hard field to study.
By the way, that argument that something being difficult is not a business justification is flawed on every level.
I love writing vanilla js, but the problem that the frameworks are really solving for is stripping away the history of HTML/CSS/JS for a 'document oriented web' and present a "re-abstraction" for an crossplatform 'application oriented web' that just happens to live in the most dominant VM platform (the browser).
In the analogy, Assembly is WebAssembly, and C is C. We just don't have the frameworks and libraries written for them yet!
--- Edit: ...but yeah you're right it's Svelte. Although I hear that Angular also compiles down to something pretty "close to the metal" these days.
I know it's unrealistic to impose strict dependency criteria, framework choices, and bundle-size limits on the job. But if you're the one in charge, even if it's in your hobby project, please consider your consumers who may not have the latest in greatest hardware. I find it absurd that a phone from not 3 years ago struggles to run most popular sites.
I just wanted to say that, because I've been holding it in so long.
The real trick was something I call Source Derivation (SDx). I'm certain it will be a language level feature 10 years from now.
I'd like to release it soon, but I'm afraid of doing it alone. It's depressing to put a project out there, then have to be alone as nobody cares.
I released some solo albums a long time ago and learned the hard way that sometimes it's better to just keep your passion projects to yourself.
https://codepen.io/SephReed/pen/gOaeQLv?editors=1010
--------
I made it up, but MobX has some rudimentary implementations of it:
Unless you need IE support. If so you need a different version that is quite large.
I'm certainly not going to suggest you stop using it if you've already pulled it in (like you said, it's pretty tiny these days), but most times I just don't think it's worth it. More so if you're not already familiar with it.
Also vue, backbone and many others provide two way data binding. React is the cool pure kid.
Some people might think of meteor js from your description.
I should have been more exact.
AngularJS uses two-way binding between scopes, while Vue enforces a one-way data flow between components. This makes the flow of data easier to reason about in non-trivial applications.
It's "ok", but doesn't play nicely with any 3rd party anything.
The data is comparing frameworks along percentile, which is misleading, __when you realise that performance is a function of total payload,__ not relative percentage.
If the data of various frameworks was compared against total userland code & Toal size (user +framework), then we could have some meaningful data.
As it stands, I can say with confidence, that most of the larger and bigger apps use Angular, or react combination because they are most popular.
Considering that angular itself is heavier than React, angular apps will be heavier than React ones.
While smaller apps (or pages) will use Vue, because:
1. Vue is the only one of top 3 which can scale down to a script tag. So, for large classes of Web Apps, Vue is the only option.
2. Vue (&vuex) is smaller in size. And does not require boilerplate like react and redux. So I would expect Vue apps to be generally smaller than alternatives.
Given these situations, I would be surprised if Vue apps (on both average, and relative percentile) do not perform better than Angular & React
A big issue with big sites operators and compagnies is that everyone is looking at his own site consumption and performance, but look at that alone, on an empty computer. But, the issue is more the impact on their single page, on a computer that is already loaded with a few applications and tabs. Suddenly, a website using 5% of cpu and 250 MB of memory, starts to have a very huge impact on the user.
Is this gzipped or uncompressed bytes?
Article doesn't specify, but based on the word "Served", I'd assume gzipped? As in bytes over the wire? Would love clarification.
So _most_ of that weight is gonna have gzip or brotli applied. (Last I looked, around 17% of JS requests recorded by HTTP Archive are uncompressed.)
If you haven't already figured out, everything old is new again. This was an old pattern when someone taught it to me at my first job. It felt like it wasn't happening for a few years but only because everything was new to me. Then I started seeing people win arguments arguing for the things that we had just finished replacing, and the most I've ever seen since is brief respites as the pendulum approaches the apex on each swing.
Old-school AJAX shipped HTML to be dumped straight into the document. I suspect that was much faster than the modern approach of sending, typically, JSON, which then requires deserialization, a bunch of transforming, memory allocation, shifting data around, template application, et c before any DOM changes are handed over to the browser engine, at which point you've just finally caught up with the approach of shoving HTML into the DOM directly.
https://spectrum.chat https://vercel.com https://gatsbyjs.org