5 ms·

The cambrian-explosion of frontend frameworks you mean is mostly about patching up the web browser to do something it wasn't born to do though. The endless cycl

The cambrian-explosion of frontend frameworks you mean is mostly about patching up the web browser to do something it wasn't born to do though. The endless cycle of solving things that are solved elsewhere won't stop as long as the browser keeps being pushed as an application platform.

jarek 13y ago
Nevermind things that are solved on other application platforms, we now have frameworks that solve things that are solved in the browser. Moving boldly beyond reimplementing page loads with custom Javascript, Youtube now reimplements page load progress bar with custom Javascript.
- woah 13y ago
  You sound dismissive of Youtube's page loading. I believe they are loading only those parts of the page that change, which is much faster than re-loading the whole thing. It makes the user experience faster and uses less bandwidth. Do you do much front end development?
  - fphhotchips 13y ago
    I think they were being dismissive of the need to reimplement the page load indicator rather than page loading itself. I could be wrong though.
  - hcarvalhoalves 13y ago
    I believe his point is not that YouTube's implementation isn't useful, but rather, that it's insane, at a conceptual level.
    - woah 13y ago
      What's so insane about it? I would say that the logic for which parts of the page to reload should definitely be in the frontend code, rather than the browser itself.
  - jarek 13y ago
    I do enough front-end to understand why Youtube does what it does. I don't do enough to think that every site implementing its own way to reload parts of pages is a sane idea. The beautiful thing is that the progress bar in question comes from one of the companies that pioneered lack of a progress bar in the browser. But hey, Javascript.
    - woah 13y ago
      Google pioneered a minimal browser that left most things up to the sites inside it. Seems to have worked out for them. If Youtube finds that a progress bar is good for their user experience, more power to them. They can make sure it works as well as possible with their site, and change and remove it if necessary. It seems that you know more about Youtube's design than Youtube's designers.
      - jarek 13y ago
        Next up: have browsers ignore hyperlinks, Youtube designers can come up with a beautiful way to represent and interpret intent to navigate to a different resource and delight users - and change and remove it if necessary
      - blt 13y ago
        Out of curiosity - I'm not a web person - what about Chrome is minimal? Which things does it leave up to sites that other browsers don't?
dllthomas 13y ago
So what we need is a permian extinction event?
- jarek 13y ago
  So the next funding crunch. Instead of making Snapchat but for dog yoga and building the next great JS framework of the month in the process, developers will have to go back to making boring things that keep working for more than 18 months.
  - dllthomas 13y ago
    Wouldn't that just be an end to the explosion, rather than an extinction event?
    - jarek 13y ago
      The extinction will come when Github starts removing inactive free projects
matthewmacleod 13y ago
That's a rather negative take on it. I'd argue instead that the explosion in frameworks is a result of a broad interest in developing and experimenting with new approaches to providing applications. Web applications are typically network-aware, real-time, cross-platform and easily-updated; the basic technologies (HTML, CSS and Javascript) are easy to start using, and in some ways extraordinarily flexible. I don't think that these are actually solved problems, and the web as an application platform can play a part in changing that. Further, the whole concept of "patching up" a platform to "do something it wasn't born to do" is misleading. Every computing device you use has it's roots in older software that was developed without being intended to perform the tasks it currently is - we stand on the shoulders of giants. The web as an application platform is still in its infancy, and we're currently playing around with a lot of different approaches - some will live, and some will die. It's how we make progress, after all.
- hcarvalhoalves 13y ago
  I agree that's a rather negative take on it, but I can't help. Working on web development for almost 15 years has washed away my sugarcoat ;) Frontend web development is still absolutely painful and ugly. It's based on a broken paradigm (hypertext vs. interactive interfaces); relies on hacks for fundamentals (XMLHttpRequest is probably the best example); multiple standards pushed by organizations with special interests (remember having to encode video in 4 different formats?); is labour and time-intensive; tooling is still catching up with the 80's. None of those, in isolation, are big problems though. The big problem is that, because you can always patch everything up with some javascript, there's no drive to have a platform that rests on top of more sound fundamentals - condemning ourselves to an endless cycle of frameworks.
sanderjd 13y ago
Is there really an application platform that does everything the joint browser-as-application-platform and browser-as-hypertext-viewer can do? Please enlighten me if I'm wrong, but I don't think there is, and I think that's why so many people have been working on improving the experience of the browser-as-application-platform.
_greim_ 13y ago
> the browser keeps being pushed as an application platform Grumpy nitpick. The browser-as-platform hasn't been so much pushed on the rest of us, as if by some narrow conspiracy. It's been pulled along by mass economic force. Its ubiquity, extensive reach across OSes and devices, and freedom both in terms of beer and speech make it the best bang for buck a high percentage of the time, all things considered. I agree though that the hypertext-browser and application-platform paradigms haven't always been easy to reconcile.
- hcarvalhoalves 13y ago
  When I say pushed, I don't mean anyone in particular (although big players like Google do it), but rather, pushed by economic (no licenses, no app stores taking chunks) and political forces (availability of professionals, open standards). So, yeah.

jarek 13y ago

Nevermind things that are solved on other application platforms, we now have frameworks that solve things that are solved in the browser. Moving boldly beyond reimplementing page loads with custom Javascript, Youtube now reimplements page load progress bar with custom Javascript.

woah 13y ago
You sound dismissive of Youtube's page loading. I believe they are loading only those parts of the page that change, which is much faster than re-loading the whole thing. It makes the user experience faster and uses less bandwidth. Do you do much front end development?
- fphhotchips 13y ago
  I think they were being dismissive of the need to reimplement the page load indicator rather than page loading itself. I could be wrong though.
- hcarvalhoalves 13y ago
  I believe his point is not that YouTube's implementation isn't useful, but rather, that it's insane, at a conceptual level.
  - woah 13y ago
    What's so insane about it? I would say that the logic for which parts of the page to reload should definitely be in the frontend code, rather than the browser itself.
- jarek 13y ago
  I do enough front-end to understand why Youtube does what it does. I don't do enough to think that every site implementing its own way to reload parts of pages is a sane idea. The beautiful thing is that the progress bar in question comes from one of the companies that pioneered lack of a progress bar in the browser. But hey, Javascript.
  - woah 13y ago
    Google pioneered a minimal browser that left most things up to the sites inside it. Seems to have worked out for them. If Youtube finds that a progress bar is good for their user experience, more power to them. They can make sure it works as well as possible with their site, and change and remove it if necessary. It seems that you know more about Youtube's design than Youtube's designers.
    - jarek 13y ago
      Next up: have browsers ignore hyperlinks, Youtube designers can come up with a beautiful way to represent and interpret intent to navigate to a different resource and delight users - and change and remove it if necessary
    - blt 13y ago
      Out of curiosity - I'm not a web person - what about Chrome is minimal? Which things does it leave up to sites that other browsers don't?

dllthomas 13y ago

So what we need is a permian extinction event?

jarek 13y ago
So the next funding crunch. Instead of making Snapchat but for dog yoga and building the next great JS framework of the month in the process, developers will have to go back to making boring things that keep working for more than 18 months.
- dllthomas 13y ago
  Wouldn't that just be an end to the explosion, rather than an extinction event?
  - jarek 13y ago
    The extinction will come when Github starts removing inactive free projects

matthewmacleod 13y ago

That's a rather negative take on it. I'd argue instead that the explosion in frameworks is a result of a broad interest in developing and experimenting with new approaches to providing applications. Web applications are typically network-aware, real-time, cross-platform and easily-updated; the basic technologies (HTML, CSS and Javascript) are easy to start using, and in some ways extraordinarily flexible. I don't think that these are actually solved problems, and the web as an application platform can play a part in changing that. Further, the whole concept of "patching up" a platform to "do something it wasn't born to do" is misleading. Every computing device you use has it's roots in older software that was developed without being intended to perform the tasks it currently is - we stand on the shoulders of giants. The web as an application platform is still in its infancy, and we're currently playing around with a lot of different approaches - some will live, and some will die. It's how we make progress, after all.

hcarvalhoalves 13y ago
I agree that's a rather negative take on it, but I can't help. Working on web development for almost 15 years has washed away my sugarcoat ;) Frontend web development is still absolutely painful and ugly. It's based on a broken paradigm (hypertext vs. interactive interfaces); relies on hacks for fundamentals (XMLHttpRequest is probably the best example); multiple standards pushed by organizations with special interests (remember having to encode video in 4 different formats?); is labour and time-intensive; tooling is still catching up with the 80's. None of those, in isolation, are big problems though. The big problem is that, because you can always patch everything up with some javascript, there's no drive to have a platform that rests on top of more sound fundamentals - condemning ourselves to an endless cycle of frameworks.

sanderjd 13y ago

Is there really an application platform that does everything the joint browser-as-application-platform and browser-as-hypertext-viewer can do? Please enlighten me if I'm wrong, but I don't think there is, and I think that's why so many people have been working on improving the experience of the browser-as-application-platform.

_greim_ 13y ago

> the browser keeps being pushed as an application platform Grumpy nitpick. The browser-as-platform hasn't been so much pushed on the rest of us, as if by some narrow conspiracy. It's been pulled along by mass economic force. Its ubiquity, extensive reach across OSes and devices, and freedom both in terms of beer and speech make it the best bang for buck a high percentage of the time, all things considered. I agree though that the hypertext-browser and application-platform paradigms haven't always been easy to reconcile.

hcarvalhoalves 13y ago
When I say pushed, I don't mean anyone in particular (although big players like Google do it), but rather, pushed by economic (no licenses, no app stores taking chunks) and political forces (availability of professionals, open standards). So, yeah.