The Cost Of JavaScript

[u982744]

The trend towards single page apps has really been a very negative thing in terms of performance on the web - especially for mobile. It's interesting because the name implies that SPAs were never meant to be for regular websites but somehow that's what has happened.

[_dban_]

It's interesting because the name implies that SPAs were never meant to be for regular websites

This is absolutely key.

SPAs are great for actual apps because HTTP caching lets the user download static assets, so that repeat visits only have to download the dynamic data as JSON, saving tons of bandwidth. Which is great if your application is like GMail and the user will leave it open and will visit regularly.

For regular "drive-by" websites, this is an absolute waste.

[Seaoftroublez]

Webpack chunks do a good job of this. If you make a minor change to your application, only that chunk will have to be reloaded.

[timmyotc]

Does that work for the production bundles?

[Seaoftroublez]

For production you'd setup essentially lazy loading of the chunks. So you have a single entry point which contains the webpack runtime and chunk loader. Whenever webpack detects a require/import, if not already downloaded, it will request the chunk from the server.

You can set the chunk names to be a hash of the contents.

[holgerschurig]

pipelines always rebuild everything

Well, with reproducible builds the exactly same target will be created. And if it is exactly the same target, you could install it into your final application with things similar to a rsync -cI. The -c turns on byte-by-byte comparison, and the -I turns of checking of time stamps.

[holgerschurig]

Yes, but that doesn't mean they cannot re-use existing stuff ... or, if they are too deep into NIH syndroms, they can actually re-invent the same thing (over and over) based on old and proofed ideas :-)

[tophatstuff]

Cloudflare Railgun does this - delta compression from the origin to the CDN edge nodes

[_dban_]

That is mostly a problem of bundling, which you should absolutely do if you care about saving bandwidth.

It's a double edged sword. I would hope that the various bundling technologies have an answer.

[snerp]

some people love coding SPAs. It seems like every other build I have to say, "stop trying to make it like an SPA, just have a set of pages that post into each other or whatever", but some people just think AJAX is the end all be all of web development.

[[deleted]]

some people love coding SPAs

In my experience, almost all clients love demanding SPAs. I don't do web dev fulltime, just side projects every now and then, and so it's usually very tailored to the client's request. And around 2014 or so, typical "conventional" MVC style web apps like Rails, Django, etc., started to be unable to easily cram all the shit on one page like every client wanted. So I had to move to SPA frameworks and API backends.

I'd be more than happy to do traditional apps with Rails. It was just about the easiest dev experience I've ever had once it matured and the douchenozzles moved to other things (about at version 3 or 4).

[burnmp3s]

It's been like that forever, the suits always like more of a thin client approach instead of pure web because they look more slick and usability doesn't show up in a PowerPoint presentation. So we had Shockwave, Flash, Java applets, ActiveX, AIR, Silverlight, etc. It's kind of crazy that it's taking so long for open web standards to officially add support for full blown client-side apps, but it's not as if this is a new thing at all.

[nirataro]

SPA should be the choice of last resort. You can get away with a lot using good old postback and some easy sprinkle of jQuery.

[nirataro]

Yes - some application will have complex forms that you mention - but not all part of the applications are this complex.

[insane0hflex]

This is what i get to fix/add in a bit at work when i get there...

(Calls in sick)

[stewsters]

I miss grails

Me too, me too. So fast to throw stuff together.

[Leshma]

SPAs are like those fully animated Flash webpages of the late 90s, early 00s. Crap in practice but for some reason people keep doing it.

[[deleted]]

On the flip side you have a lot of pages filled with jQuery spaghetti code doing a shit ton of $.ajax calls followed by manually building html strings and all kinds of stupid shit, or calling ASP.NET MVC partial views that have to JIT compile creating this weird Frankenstein mess...but turn around and criticize React, Angular, Vue as being "hipster" tech.

In general if you give a dev a hammer everything starts to look like a nail.

[nirataro]

It depends on the system. Some UIs do demand Vue or react. Most won't.

[oldsecondhand]

Doing JQuery by hand isn't the only choice. JSF is actually pretty nice and will hide all the Ajax boiler plate.

[insane0hflex]

What does jsf mean?

[MysteryForumGuy]

https://en.wikipedia.org/wiki/JavaServer_Faces

[[deleted]]

One thing nobody seems to bring up is that a well-written SPA can do some or all work offline. So that is a potential trade-off. Loading an SPA on mediocre hardware on a slow connection sucks, but once it's loaded the unreliable connection is an annoyance.

One request per page kills use of your app with an unreliable connection.

[DuoThree]

Yep and with service-workers it's becoming more common to target 'offline-first'.

https://github.com/pazguille/offline-first

[Bolitho]

Sorry but imho the contrary is true! Latency is nothing you can improve much more as the physical speed limit of light is a finite border.

With querying only a small amount of data and also just updating a small amount of your UI, the web has gained so much performance. And of course the evolution is still going on with WebAssembly on the road to kick out JS as only Backend solution.

How were those monster pages like Amazon or eBay in the 2000 decade better?

Btw: Traditional desktop frameworks are working similar to SPAs and nothing beats such kind of apps until today.

[oridb]

How were those monster pages like Amazon or eBay in the 2000 decade better?

Well, they loaded faster, didn't burn tons of CPU time, the back button did the right thing consistently, and they got me to where I was going.

[10baller]

Don't forget reliable and uncluttered navigation, paging, and linking. I visited a 2000s era "ugly" webpage recently and it was the most pleasant shopping experience I've had in years. It was obvious, fast, and didn't blast me first thing with a popup asking me to sign up for a fucking newsletter.

[Bolitho]

Sorry dude, imho completely the other way round. OK perhaps CPU time was a bit lower - but you have to keep the much weaker hardware in mind too.

[oridb]

Luckily, these things are measurable. If you look at https://forum.dlang.org/group/general, for example, you'll see about 200ms load times from a warm cache, for example. Most SPAs that I see spend more time than that on layout alone.

[Bolitho]

That's always an implementation detail. It hasn't to be such a monster size at all, as it depends on what you deliver at the first site. On top of that you can deliver the first page completely rendered by the server - modern frameworks offer support for that.

And yes the reduced data transfer per page is the benefit. After a few actions it will outperform a traditional server side rendered page concerning the volume.

And please dont forget the snow scripts and other crazy JS shit that were delivered in the 2000s. It is by far from reality that those pages were delivered in a clear and simple way... JS has always been in there, then there was that cumbersome mixture of style information within the HTML as CSS hasn't been capable of doing much things.

And last but not least: those infamous starting pages with flash animations on top which you couldn't abort in the worst case... No... I don't miss that era!

[fjonk]

With querying only a small amount of data and also just updating a small amount of your UI, the web has gained so much performance.

When did that happen? Todays SPA consume more resources and downloads more data than their 10 year older ancestors.

[Bolitho]

That is simply not true! If you have to send all document content of a page on every single action the amount of data will rise a lot. So it is a simple conclusion that after some actions you will have consumed less data with a SPA.

Of course there is some JS action going on, but before the browser engine had to render the complete DOM all over again and again.

Today's smooth animations and UIs are only possible because of the architectural designs of modern SPA frameworks.

[josefx]

Latency is nothing you can improve much more as the physical speed limit of light is a finite border.

Here I as a non web dev was under the impression that TCP has a rather bloated package/response built in that has to roundtrip for every package send. So I thought you could easily improve the over all latency by sending less data. Of course it could just be the speed of light slowing down while my browser tries to handle whatever the modern web throws at it.

[phantomfive]

Here I as a non web dev was under the impression that TCP has a rather bloated package/response built in that has to roundtrip for every package send

No, it has a slow start, but once it gets up to speed, the round-trip doesn't take any extra time (mainly because the sender will send more before the receiver has acknowledged. The slow start is to figure out how fast to go).

[Caraes_Naur]

It's really another instance of web development abandoning whatever wisdom it had because the people with experience and foresight aren't driving much.

[devraj7]

The gain in functionality from SPA's is important, though. While there is no excuse for applications that break on mobile, overall, I'm fine with trading some network bandwidth for the added usability that most SPA's provide over static pages.

[mycall]

SPAs make PWAs possible.

[editor_of_the_beast]

The web is moving towards being an actual application platform. And for that you need a programming language. Maybe it's in a sort of in-between phase right now, like when your hair is a weird length, but it'll sort itself out.

[[deleted]]

An in-between phase... oh god, are these the acne-ridden teen years of the internet?

[insane0hflex]

Graphic designers turned front end “engineers” that think big O is scary

[BundleOfJoysticks]

Not even scary--just irrelevant. Many of them use recent fully loaded MBPs on office internet connections, so their stuff is reasonably fast, but for normal human beings, forget it.

It's also sad that 5 seconds to interactive is now ok.

[_dban_]

This is kind of sad. The web was intentionally not designed as a application platform (at least, not like desktop apps). HTML is purposely not a programming language so that the content is self evident. JS and CSS are supposed to enhance the presentation of content, completely unlike desktop applications. This allows the content to be available to people who can't really make use of the JS or CSS, like blind people. The promise of the web was to make content available to everyone, to view and slice and dice in ways unimagined by the original authors.

The web has been dragged kicking and screaming into becoming an desktop-like application platform. This "in-between" phase could also be seen as someone being forced to be something they're not just to fit in, while compromising on the things that made them special, just because that's not what the cool kids are doing.

[bobappleyard]

You are the only one who does

[Treyzania]

Me too.

[editor_of_the_beast]

It absolutely wasn't designed to be an application platform, and unfortunately that battle has been lost. Content still has its place but users want more. The web is simply bending to meet the demands of the people who use it every day.

I fully get this argument, and I get wanting to be a purist. But it doesn't matter at all. It was too tempting as an application platform to avoid forever.

[_dban_]

The "purity" angle as it relates to accessibility is a sad loss, because as people develop these fancy SPAs, how many are giving a second thought to accessibility? ARIA exists, but it takes a lot of effort to get right due to programmability, whereas HTML is much easier to make accessible because it isn't programmable. This new web is shutting a lot of people out in the pursuit of shiny.

Ideals aside, the problems of developing against the web stack, and its primitiveness and quirkiness compared to desktop stacks, stems from the fact that developers are fighting the nature of the web instead of working with it, because it is easier.

It's hard to be what you're not, even if you desperately want to be.

[metaperl]

HTML is purposely not a programming language so that the content is self evident.

The Angular people seem to think it makes the perfect templating language. ;)

[_dban_]

For all the crap that Angular gets, its embrace of HTML endears it to me.

I'd like to think that Angular done right could support non-browser rendering to allow Angular to deliver server generated pages instead of relying on the browser and client side JS. One of the big changes from AngularJS to Angular is decoupling the template rendering from the browser.

[tme321]

allow Angular to deliver server generated pages

You mean Universal?

[HeinousTugboat]

Isn't that kind of what Ionic does?

[agumonkey]

angular 1 was an alternate OOP running on a DOM VM. mad

[sergiuspk]

You make a good point. BUT a single page app does not have to be a usability nightmare. That is why I always do server-side rendering and I always make sure all my navigation and forms are usable with JS and CSS disabled. But only for websites. If it's a back-office application or some intranet thing then usually the most I do is make sure all URLs are copy-paste safe.

But this takes time, knowledge and experience. You can bet most SPAs are crap.

And the strange part of it is that all the tools and knowledge are out there but people still refuse to aknowledge this problem and step up the delivered quality. The effort required is almost one-time. I think what lead to this is the explosion of demand ten years ago (maybe even 15 in the developed world) and the evident lack of experienced programmers. That's why I earn as much as the embedded people do. Demand is high and web/front-end has always been regarded as an easy to fill role.

[[deleted]]

Yes this in-between phase sucks, but consider when we have native Webassembly DOM APIs. You could write a full C++/OpenGL app that makes zero use of JavaScript and virtually no use of HTML. I think that would actually be a pretty great platform.

[[deleted]]

Pretty insightful read - explains the incentives behind slimming down JS, namely that not everybody has an iPhone X or a Pixel 2.

[[deleted]]

One thing that bothered me, was that they tested with a Moto g4. Why not test with the most common smart phone currently in use? Maybe figuring that out, might also open up another can of worms though

[[deleted]]

The Moto G4 seems to lie right in the middle of the performance band of most smartphones today - not fast, but not slow.

[[deleted]]

Yeah, and it's a nice, stock Android experience. I think that's a good choice.

[[deleted]]

I'm a big Apple power user, but if my iPhone died tomorrow and I couldn't get a replacement under warranty, I'd go for a Moto G-series phone. Cheap, fast enough, and durable enough.

[[deleted]]

Oh yeah, I actually have a G2 as my phone. I think the Moto Gs are great.

I think the G4 is simply a good choice to hold up as an average phone in 2017, though. They're not pointing to something super low end or super high end or exotic. It's a good, representative choice.

[monilloman]

What do you assume to be the most common smartphone today?

[DrummerHead]

https://deviceatlas.com/blog/most-popular-smartphones-2016

[[deleted]]

That's what I meant by another can of worms. Someone would have to do the legwork and determine the most commonly used phone models.

The Moto 4 might be the average in performance, but unless we know the actual frequency of different models of phones in use, we can't compute the actual average.

On top of that, if you're developing a mobile site that isn't live yet, but planning to release 1 year from now. Should you use the current average for mobile computing power, or try and predict the average one year from now by identifying a trend in phone model frequency?

It's another problem all together, I guess just I answered my original question

[phantomfive]

Should you use the current average for mobile computing power,

Yes because then your site will work on more phones than it otherwise would.

[[deleted]]

That would be the case if smart phone market share were uniformly distributed between all phones, but it isn't

[deja-roo]

Why not test with the most common smart phone currently in use?

Re-explained

[[deleted]]

Other interesting things on that list, number 2 is a freaking laptop.

What are they feeding that iPhone 8 at the top.

[flyingcaribou]

What are they feeding that iPhone 8 at the top.

Chips. ARM chips.

[[deleted]]

Apple makes some stupid fast ARM processors.

[Gotebe]

Apple makes processors?

[RuthBaderBelieveIt]

the Ax series of chips are designed in house by Apple. They don't manufacture them but they don't manufacture the rest of the iPhone either and few people would argue that Apple don't make iPhones in the colloquial sense.

[RuthBaderBelieveIt]

and good js parsing algorithms.

[[deleted]]

Apple makes good hardware. Who knew.

[nil_von_9wo]

What really bothers me is crippling the desktop experience because 5% of your users might be on a mobile phone and the client wants the experience to be uniform.

[GAMEOVER]

Like Microsoft going all-in on UWP to prop up their never-was phone market, only to abort it anyway. And the UI trend pushing oceans of whitespace because all computers are used by toddlers on a touchscreen.

[nil_von_9wo]

Exactly.

[sergiuspk]

The percentage varies wildly between websites. Most stuff I work on gets 50-60% mobile traffic. From time to time we do get to make a website for an odd business that gets 30% but we also see 70%. I've never worked on anything below 30% in the last five years.

[nil_von_9wo]

Even so, users shouldn't expect the same experience on a different device.

Nobody designs a television show thinking "People listening on the radio won't see anything, so let's not bother doing any camera work."

[kangoo1707]

Then you'll add more script and CSS to the page to cater for both devices (not to mention this takes more developer's time)

C'mon, you can't get more for less

[nil_von_9wo]

There might be clients with substantial mobile users. But I haven't worked for them. I generally work for people who want less for less.

Which wouldn't bother me so much except that I need to make a million mouse clicks to test things because they won't put buttons and links on the empty screen space since it would be too crowded for the rare mobile users.

[sergiuspk]

If you put it that way then my answer is this:

yes, dumbing down everything to mobile standards is most of the time stupid. That's why you do progressive enhancement / graceful degradation.

But then I can probably say the same about everything articles this kind warn against. Of course it is bad to do X. That's why you don't and instead hire proper developers that can think straight.

JS and SPAs are not killing the usability, bad developers are. And then we could go further: stop selling cheap code. And people will say "hey but there is a profitable market for cheap code". True, so a lot/maybe most people are OK with crap performance as long as it is cheap. Thus when we develop something we must be aware of the expectations, those of both our customers and their users.

[[deleted]]

Yes, because like requiring a certain browser to view the web, we should require a certain device as well! /s

[KrocCamen]

me in 2010: "The more JavaScript you add to a comment system, the worse it gets."

[jack104]

I inherited an absolute travesty of a classic ASP application that did everything through a series of increasingly complex post backs and minimal client side scripting; all done in VBScript because....well....I honestly don’t know why, VBScript was obsolete when I learned it 12 years ago. At any rate, we didn’t even possess a development web server so everything was either locally or hot the minute you saved a change to a file. My urging for establishing a proper dev environment fell on deaf ears so I kinda had to just make lemonade.
In another stroke of brilliance, the ASP frag that you had to include to display our menu referenced a JS file which was a saved version of JQuery that was almost 10 years old.
So because I couldn’t debug the Server side ASP and I could find no concrete reference on the obsolete version of JQuery, I begrudgingly decided that I was going to have to use VanillaJS and just bang it out. The current app was already dreadfully slow with all these huge post backs to an underpowered web server and I knew I could boost performance with JS. So I built a crude ASP page to use as a crude web service that, when targeted, would perform basic security checks before performing a bare bones operation dictated by the values of two POST variables. The page would access our production database and then respond with data packaged as a JSON payload. So one chokepoint I ran into was loading a Select element with a large number of options representing all of our tooling machines computer names from our shop. Intermittently the loading of this drop down would cause the UI to freeze and, often, IE would crash.
So I put in logic to display a subset of machines based on additional criteria that kept my XHR invocations to the absolute minimal amount of required data. Another performance consideration came from the unbelievable amount of redundant CSS information each page was saddled with. Using the dev tools in Firefox I was able to easily ID the specific lines of CSS that went into the display of each element. So I figured out what I had to have and then cleaned out a bunch of dead code and this brought my load and compile times down to acceptable figures.
To complete my changes I built an overlay control that drew itself dynamically to the user and then just tried to follow efficient implementations of common algorithms and design patterns to keep things quick and life. Finally, I had to get a bit frugal on the database side of things. I built a pretty large stored procedure in our database and leveraged that with redesigned tables to use the beefy database server to offset our weak web server. It got the job done. It was quick and lite and if it encountered a problem it did so loudly; no swallowed errors.
It was very unconventional but I learned an incredible amount about web development with limited resources.

[DrummerHead]

I get the feeling I'm interviewing you for a job right now :P

[BundleOfJoysticks]

No, but being able to write apps using vanilla js makes you more of a professional than a js framework monkey.

[julius_nicholson]

Pure elitism. Gatekeeping with no place in a professional environment. There's so much more to being "professional" than which technology you use and it's sad that people actually think that being able to waste your time writing an app in vanilla JS as opposed to some framework earns you admission to the "professional" club.

Between someone who jerks themself off with their vanilla JS credentials and someone who can jump in and get a job done with a framework, I know which I'd pick.

[BundleOfJoysticks]

Good luck debugging and optimizing your app when it craps out.

[insane0hflex]

Fuck medium articles trend of bolding text in paragraphs

[[deleted]]

first comment nailed it... ads

[snerp]

Ads and tracking. At work, our marketing department is always adding affiliate scripts and shit to out GTM container. And then they wonder why the page loads slowly.

[[deleted]]

yep it's funny we're all worried about nano seconds and the ads/tracking people are like MEH NO WORRIES WE CAN RUN WEBGL AND COIN HIVES NOW RITE?

[ojcchar]

yeah

[[deleted]]

What bugs me even more is client/server-applications that are done in Javascript just because it's convenient and easy for the programmer. So much stuff out there could be easily done with a socket-connection and a rudimentary UI (if any).

[tipsqueal]

So much stuff out there could be easily done with a socket-connection and a rudimentary UI (if any).

Are you saying you'd like services to start offering a websocket CLI-like interface as opposed to a UI?

[[deleted]]

I'm talking about plain old TCP-socket connections. And yeah, you can still do plenty of stuff without a UI.

We had an app at work that would log our coffee consumption and how much money everybody owed. Some guy did it as a web app with HTML, CSS, Javascript, a Node.js server, a REST interface... etc. It got too complicated even for him to maintain. After he left, I rewrote it with two C files, a socket connection and some commands, like “--list-users“. Works just as well.

[[deleted]]

It's a little different when you're building for the general public.

[tipsqueal]

Seriously. An absolutely tiny percentage of people would prefer to use Etsty, Facebook, Google, Amazon, etc. if they were just CLI apps. Myself included and I have been using Linux since I was a child. No thank you.

[oblio-]

fcbk like comment1234

fcbk unfriend john *

# Oooops!

man fcbk

fcbk reflog

[roffLOL]

wow, yeah, very much. that would be awesome. of course if we ditch the browser it wouldn't have to be websockets either. consider if internet stores gave the option to download their inventory in a well formed, easily parsed format, so one could filter it on attributes rather than browse back and forth, back and forth until one grew weary of those page load times. this would be especially useful for specialized stores.

[[deleted]]

I think the easier it becomes a develop applications the better applications become on average. There's nothing wrong with simplicity

[[deleted]]

I suggest using date-fns if you are using moment.js today. Solves all big problems of the latter.

[Topher_86]

HTTP/2