7 ms·

Building Fast and Resilient Web Applications

84 points by tim_sw 10y ago

deleted 10y ago
[deleted]
simonw 10y ago
You know what loads really fast and reliably on a cheap mobile phone with a flaky cellular connection? HTML with a little bit of CSS and a little bit of JavaScript. I think it's crazy that web development trends continue to move in the direction of MB+ JavaScript single page apps, while actual device trends are moving towards inexpensive Android mobile phones on cellular connections. The web is getting fatter while the devices are getting less powerful! How much code do you really need to serve to power an interface that fits on a mobile phone screen?
- andyfleming 10y ago
  > trends are moving towards inexpensive Android mobile phones That seems like a bit a of generalization. Even the "inexpensive" phones are getting more powerful. Yeah, a lot of people are buying cheaper androids, but almost all of them are still at least "smart" phones. It's become par for the course. I don't disagree that simplifying can be the solution some of the time, but I don't think it is simple as that in all cases.
- eng_monkey 10y ago
  Maybe for a simple Web site, "HTML with a little bit of CSS and a little bit of JavaScript" is enough. It is certainly not the case for almost any Web application.
  - regularfry 10y ago
    That's the point. Most web applications are unnecessary, and come with significant downsides.
    - Klathmon 10y ago
      So your point is that developers should stop developing because that functionality shouldn't exist?
      - regularfry 10y ago
        If that's all they have to work on, maybe. It's just broken windows if it's not actually an improvement. I like to think that they've got real problems to solve though.
        Klathmon 10y ago
        That's so silly. If people are happily using a site I create (and I some cases paying money for use of that site) who are you to decide it's not worth it?
        regularfry 10y ago
        You might care if you can deliver the same functionality with a fraction of the complexity and better performance. I care because if you're interacting with other developers while building that site, you might be leading credulous hype-followers down a path which means I end up having to maintain yet another pile of useless, overcomplicated JS.
        Klathmon 10y ago
        Well I'm sorry but I'm not going to care about what you like to maintain when I'm making things. Especially when people are paying me to make those things, you are literally the last person I care about, right below those "hype-followers".
        dragonwriter 10y ago
        The people paying you to make things probably are going to end up carrying about maintenance down the road; if you don't care, you are providing the kind of bad service that demonstrates the difference between much of what goes on in software development and actual professionalism -- a doctor it later that didn't concern themselves with, and proactively warn, a client/patient with that kind of down the road consequence would be guilty of professional malpractice.
  - deleted 10y ago
    [deleted]
- dmytrish 10y ago
  To play a devil's advocate, a SPA definitely takes its time to load, but the subsequent requests may be much more fluid, since they only update the existing page, carry only the compressed and necessary information and may be retried, batched, etc. Maybe it's more like the bias of exaggerated self-importance: people believe that their page will be used much more than once (and optimize for that), whereas most pages get their single view and are closed.
  - simonw 10y ago
    Yeah that's definitely part of my frustration here: mobile users tend to load up a site, achieve their goal and move on again in a session that's probably less than 60 seconds total. And since phones have limited caches, the chances are any caches resources will have been flushed out by other activity before they revisit your site or application.
- nickpsecurity 10y ago
  A la Steve Gibson's way of doing things: https://www.grc.com/menudemo.htm https://www.grc.com/menudemo.htm Loads fast with plenty usability and effectiveness. Works very well with NoScript, too. So, it's faster, more secure, and gets the job done? Screw it, let's do a single-page, Coffeescript App instead! ;) Note: That loaded instantly on my smartphone unlike most web apps. I was excited until I clicked the menus. Instead of just opening, it opened and loaded up the page for that menu. Been a long time since I did CSS so I don't know if that's inherent or just a flaw in his implementation. It was done before smartphones. I'm assuming the latter.
ben_jones 10y ago
> Adapt application logic to match the device & network capabilities. Yeah let me just build 4 apps real quick and serve different ones based of the network performance of a given user. That's practical.
- dualogy 10y ago
  "4 different apps" doesn't have to equate "4 separate codebases" obviously. Behold the wizardry of #ifdefs! Just the old idea of graceful degradation. What is done at the GUI level can be done at the feature/functionality level. But you're still right in that it's a lot of extra effort and must be budgeted for.

84 points by tim_sw 10y ago

deleted 10y ago

[deleted]

You know what loads really fast and reliably on a cheap mobile phone with a flaky cellular connection? HTML with a little bit of CSS and a little bit of JavaScript. I think it's crazy that web development trends continue to move in the direction of MB+ JavaScript single page apps, while actual device trends are moving towards inexpensive Android mobile phones on cellular connections. The web is getting fatter while the devices are getting less powerful! How much code do you really need to serve to power an interface that fits on a mobile phone screen?

andyfleming 10y ago
> trends are moving towards inexpensive Android mobile phones That seems like a bit a of generalization. Even the "inexpensive" phones are getting more powerful. Yeah, a lot of people are buying cheaper androids, but almost all of them are still at least "smart" phones. It's become par for the course. I don't disagree that simplifying can be the solution some of the time, but I don't think it is simple as that in all cases.
eng_monkey 10y ago
Maybe for a simple Web site, "HTML with a little bit of CSS and a little bit of JavaScript" is enough. It is certainly not the case for almost any Web application.
- regularfry 10y ago
  That's the point. Most web applications are unnecessary, and come with significant downsides.
  - Klathmon 10y ago
    So your point is that developers should stop developing because that functionality shouldn't exist?
    - regularfry 10y ago
      If that's all they have to work on, maybe. It's just broken windows if it's not actually an improvement. I like to think that they've got real problems to solve though.
      - Klathmon 10y ago
        That's so silly. If people are happily using a site I create (and I some cases paying money for use of that site) who are you to decide it's not worth it?
        regularfry 10y ago
        You might care if you can deliver the same functionality with a fraction of the complexity and better performance. I care because if you're interacting with other developers while building that site, you might be leading credulous hype-followers down a path which means I end up having to maintain yet another pile of useless, overcomplicated JS.
        Klathmon 10y ago
        Well I'm sorry but I'm not going to care about what you like to maintain when I'm making things. Especially when people are paying me to make those things, you are literally the last person I care about, right below those "hype-followers".
        dragonwriter 10y ago
        The people paying you to make things probably are going to end up carrying about maintenance down the road; if you don't care, you are providing the kind of bad service that demonstrates the difference between much of what goes on in software development and actual professionalism -- a doctor it later that didn't concern themselves with, and proactively warn, a client/patient with that kind of down the road consequence would be guilty of professional malpractice.
- deleted 10y ago
  [deleted]
dmytrish 10y ago
To play a devil's advocate, a SPA definitely takes its time to load, but the subsequent requests may be much more fluid, since they only update the existing page, carry only the compressed and necessary information and may be retried, batched, etc. Maybe it's more like the bias of exaggerated self-importance: people believe that their page will be used much more than once (and optimize for that), whereas most pages get their single view and are closed.
- simonw 10y ago
  Yeah that's definitely part of my frustration here: mobile users tend to load up a site, achieve their goal and move on again in a session that's probably less than 60 seconds total. And since phones have limited caches, the chances are any caches resources will have been flushed out by other activity before they revisit your site or application.
nickpsecurity 10y ago
A la Steve Gibson's way of doing things: https://www.grc.com/menudemo.htm https://www.grc.com/menudemo.htm Loads fast with plenty usability and effectiveness. Works very well with NoScript, too. So, it's faster, more secure, and gets the job done? Screw it, let's do a single-page, Coffeescript App instead! ;) Note: That loaded instantly on my smartphone unlike most web apps. I was excited until I clicked the menus. Instead of just opening, it opened and loaded up the page for that menu. Been a long time since I did CSS so I don't know if that's inherent or just a flaw in his implementation. It was done before smartphones. I'm assuming the latter.

ben_jones 10y ago

> Adapt application logic to match the device & network capabilities. Yeah let me just build 4 apps real quick and serve different ones based of the network performance of a given user. That's practical.

dualogy 10y ago
"4 different apps" doesn't have to equate "4 separate codebases" obviously. Behold the wizardry of #ifdefs! Just the old idea of graceful degradation. What is done at the GUI level can be done at the feature/functionality level. But you're still right in that it's a lot of extra effort and must be budgeted for.