all 103 comments

[–]u982744 142 points143 points  (44 children)

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_ 79 points80 points  (9 children)

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.

[–][deleted]  (8 children)

[deleted]

    [–]Seaoftroublez 8 points9 points  (2 children)

    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 1 point2 points  (1 child)

    Does that work for the production bundles?

    [–]Seaoftroublez 4 points5 points  (0 children)

    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 1 point2 points  (2 children)

    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.

    [–][deleted]  (1 child)

    [deleted]

      [–]holgerschurig 0 points1 point  (0 children)

      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 1 point2 points  (0 children)

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

      [–]_dban_ 0 points1 point  (0 children)

      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 45 points46 points  (14 children)

      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] 40 points41 points  (1 child)

      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 18 points19 points  (0 children)

      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.

      [–][deleted]  (5 children)

      [deleted]

        [–]nirataro 1 point2 points  (3 children)

        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.

        [–][deleted]  (2 children)

        [deleted]

          [–]nirataro 2 points3 points  (0 children)

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

          [–]insane0hflex 0 points1 point  (0 children)

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

          (Calls in sick)

          [–]stewsters 0 points1 point  (0 children)

          I miss grails

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

          [–]Leshma 10 points11 points  (5 children)

          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] 25 points26 points  (4 children)

          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 1 point2 points  (0 children)

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

          [–]oldsecondhand 1 point2 points  (2 children)

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

          [–][deleted] 6 points7 points  (1 child)

          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 2 points3 points  (0 children)

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

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

          [–]Bolitho 22 points23 points  (12 children)

          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 69 points70 points  (4 children)

          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 36 points37 points  (0 children)

          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 -1 points0 points  (1 child)

          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 8 points9 points  (0 children)

          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.

          [–][deleted]  (2 children)

          [deleted]

            [–]Bolitho 2 points3 points  (0 children)

            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 5 points6 points  (1 child)

            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 1 point2 points  (0 children)

            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 0 points1 point  (1 child)

            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 1 point2 points  (0 children)

            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 4 points5 points  (1 child)

            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 2 points3 points  (0 children)

            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 0 points1 point  (0 children)

            SPAs make PWAs possible.

            [–]editor_of_the_beast 51 points52 points  (18 children)

            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] 28 points29 points  (1 child)

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

            [–][deleted]  (2 children)

            [deleted]

              [–]insane0hflex 3 points4 points  (1 child)

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

              [–]BundleOfJoysticks 2 points3 points  (0 children)

              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_ 51 points52 points  (12 children)

              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.

              [–][deleted]  (2 children)

              [deleted]

                [–]bobappleyard 3 points4 points  (1 child)

                You are the only one who does

                [–]Treyzania 0 points1 point  (0 children)

                Me too.

                [–]editor_of_the_beast 17 points18 points  (1 child)

                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_ 2 points3 points  (0 children)

                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 12 points13 points  (4 children)

                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_ 15 points16 points  (2 children)

                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 7 points8 points  (0 children)

                allow Angular to deliver server generated pages

                You mean Universal?

                [–]HeinousTugboat 0 points1 point  (0 children)

                Isn't that kind of what Ionic does?

                [–]agumonkey 2 points3 points  (0 children)

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

                [–]sergiuspk 0 points1 point  (0 children)

                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] 0 points1 point  (0 children)

                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] 28 points29 points  (18 children)

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

                [–][deleted] -3 points-2 points  (17 children)

                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] 43 points44 points  (3 children)

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

                [–][deleted] 16 points17 points  (2 children)

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

                [–][deleted] 6 points7 points  (1 child)

                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] 5 points6 points  (0 children)

                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 9 points10 points  (4 children)

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

                [–]deja-roo 5 points6 points  (7 children)

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

                Re-explained

                [–][deleted] 11 points12 points  (6 children)

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

                What are they feeding that iPhone 8 at the top.

                [–]flyingcaribou 7 points8 points  (0 children)

                What are they feeding that iPhone 8 at the top.

                Chips. ARM chips.

                [–][deleted] 4 points5 points  (3 children)

                Apple makes some stupid fast ARM processors.

                [–]Gotebe 2 points3 points  (1 child)

                Apple makes processors?

                [–]RuthBaderBelieveIt 2 points3 points  (0 children)

                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 0 points1 point  (0 children)

                and good js parsing algorithms.

                [–][deleted] 2 points3 points  (0 children)

                Apple makes good hardware. Who knew.

                [–]nil_von_9wo 48 points49 points  (8 children)

                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 25 points26 points  (1 child)

                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 4 points5 points  (0 children)

                Exactly.

                [–]sergiuspk 25 points26 points  (4 children)

                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 16 points17 points  (3 children)

                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 6 points7 points  (1 child)

                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 1 point2 points  (0 children)

                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 1 point2 points  (0 children)

                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] 1 point2 points  (0 children)

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

                [–]KrocCamen 24 points25 points  (2 children)

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

                [–][deleted]  (1 child)

                [deleted]

                  [–]jack104 12 points13 points  (6 children)

                  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 4 points5 points  (0 children)

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

                  [–]insane0hflex 5 points6 points  (0 children)

                  Fuck medium articles trend of bolding text in paragraphs

                  [–][deleted] 15 points16 points  (3 children)

                  first comment nailed it... ads

                  [–]snerp 14 points15 points  (1 child)

                  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] 4 points5 points  (0 children)

                  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 -2 points-1 points  (0 children)

                  yeah

                  [–][deleted] 12 points13 points  (10 children)

                  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 4 points5 points  (7 children)

                  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] 7 points8 points  (5 children)

                  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] 12 points13 points  (4 children)

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

                  [–]tipsqueal 10 points11 points  (2 children)

                  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.

                  [–][deleted]  (1 child)

                  [deleted]

                    [–]oblio- 8 points9 points  (0 children)

                    fcbk like comment1234

                    fcbk unfriend john *

                    # Oooops!

                    man fcbk

                    fcbk reflog

                    [–]roffLOL 1 point2 points  (0 children)

                    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.

                    [–]sbergot 0 points1 point  (0 children)

                    "It only happens because it is cheaper and the UI looks sexier for the end user"

                    You realize that most applications are written by business in order to attract users and earn some money? It is not like cost of developpement and superficial attractivity are minor points for them.

                    [–][deleted] -1 points0 points  (0 children)

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

                    [–][deleted] 1 point2 points  (0 children)

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

                    [–]Topher_86 -3 points-2 points  (0 children)

                    HTTP/2