5 ms·

Jesus christ. The solution to "our webpage has 7.1 MegaBYTES of javascript" isn't "lets use a more compact representation of the code", it's STOP FUCKING ADDING

Jesus christ. The solution to "our webpage has 7.1 MegaBYTES of javascript" isn't "lets use a more compact representation of the code", it's STOP FUCKING ADDING MORE JS SHIT. ------ It's basically: Users: "My house is on fire!" These devs: "Ok, we're here to help, we cleaned your windows. You can see the fire from outside so much better now!" ------ Maybe they should solve the problem of their website being a bloated javascript blob-monster, rather then just trying to fit it into a smaller box.

rtpg 9y ago
I feel like this is an unfair criticism unless you know what the page is doing. People are building entire vector editing programs on the web. How can you be fine with Photoshop being several hundred megs but not with this person having less than 10 megs of code to achieve something similar? The web isn't just Hacker News and CNN. People write real programs on it. Obviously shipping less code is Good(TM). But isn't an across the board improvement also good?
- chroem- 9y ago
  >People are building entire vector editing programs on the web. This is the exception rather than the rule. There is no reason why it should take more than ten seconds to load a static news article with text.
  - spoiler 9y ago
    In which you—and the original starter of this comment thread—completely missed the point. The linked page clearly uses complex applications as examples. Whatever anyone's opinion of them are, they are quite complex. This proposal is aimed at web applications, not a simple website with image/text content, and minimal javascript.
    - mirko22 9y ago
      Yet Google Sheets and Gmail are applications, Facebook and LinkedIn are websites which might as well be fully static and are twice the size so his point is kinda correct. Mind you, Gmail also has features like Chat as do Facebook and LinkedIn.
      - djeric3 9y ago
        Facebook.com does a lot more than show a newsfeed, profiles, and notifications. - It contains a fully-fledged messenger application that supports payments, videoconferencing, sharing rich media etc - The newsfeed supports interactive 360-degree video, a live video player, mini-games in the newsfeed, and lots of other rich/interactive media - It's a gaming platform for 3rd party games - It's a discussion forum, groups management system, event planning UI - Photo sharing and editing platform, as well as live video streaming tool - A platform for businesses to have an online presence (Pages) - A peer-to-peer online marketplace (called "Marketplace") And a dozen other things I can't think of right now. You might say "but I don't use all of those things". That's another tricky part, the fact that every user has a different "configuration" and different types of content in their newsfeed at any given moment, requiring them to be served different sets of JavaScript code.
        codedokode 9y ago
        Most of these features are unnecessary until the user tries to play a video, a game, opens a dialog etc.
        djeric3 9y ago
        Right, and that's what happens today, the JS for the secondary functionality is loaded on demand. Here's what I have in my FB homepage during a random load: - Search bar for searching people/groups/posts/pages - News ticker - Friend requests, Notifications - Sidebar ads - A rich text editor for sharing my status - A newsfeed story with a special "memory - 3years ago" feature - Comments & commenting UI under newsfeed stories - Suggestions for "People You May know" - A video auto-playing a clip from a friend, with capability to auto-select between tracks of different video quality based on bandwidth (including bandwidth estimator code) - And probably a dozen different A/B experiments that I'm a part of It takes a lot of code just to render all these UI elements. If I interact with any of them, additional code is loaded (you can see this in the Network monitor). This homescreen UI is as rich as any desktop application and requires no less code to render. The problem being addressed in this proposal is that a native version of this app would start a lot faster than the web version. And that's because a browser will parse all the code files loaded on startup in an app (inefficiently, by necessity), but a native app will only read the code for the code paths that are actually executed. Basically, O(code executed) is a lot better than O(all files containing code that is executed). And this proposal features a more parser-friendly encoding and change to the parsing semantics.
  - lewisl9029 9y ago
    I think the point was, the premise of the OP's original "solution" was a sweeping generalization that doesn't apply to non-trivial web _apps_ that have a large amount of inherent complexity, which is then necessarily reflected in the size of their codebases. This proposal aims to provide a real solution to tackle problem.
  - codedokode 9y ago
    That should take less than one second, not ten.
- seanwasere 9y ago
  fb et al are creatively siphoning up your data, it's legal for them to do it of course
deleted 9y ago
[deleted]
abritinthebay 9y ago
This is quite mean. There is nothing wrong with doing both this and cutting down on bloat.
- chrismorgan 9y ago
  There’s nothing wrong with it, but it won’t happen. If no one had ever cared about performance in browser engines, we wouldn’t have the problem of massive pages that we have now. Things like Facebook would have to be more efficient about how they do things. By making loading faster, you reduce the incentive for them to reduce their own bloat. Of course, on the other hand, if browsers were still slow, there are various things that people can do now which they wouldn’t have bothered with before. A vector graphics engine or sound engine, for example, would have been impossible with the browser functionality of now but the performance of ten years ago, because they would have been unbearably slow. You win some, you lose some. Mostly you just end up with an unhappy balance that keeps no one really happy.
  - abritinthebay 9y ago
    I agree it won’t happen but that doesn’t make the original comment any better.
Yoric 9y ago
As you probably know, building a sophisticated application can easily become quite complex. This is the case even if the application is designed to look non-sophisticated, as Twitter or Facebook, for instance. Now, when we are discussing desktop applications or mobile applications, people typically do not care all that much about the codesize, because it is essentially invisible to the user. For instance, who cares that the Steam binary (just the binary, without resources or dynamic dependencies) weighs 3.1Mb or that the Gimp binary (again, without resources or dynamic dependencies) weighs ~9Mb or that the Telegram binary weighs ~11Mb? On the web, of course, since the application is downloaded dynamically, rather than being installed, people don't expect to wait and they start noticing. In some cases, web developers can fine tune their JS to make sure that less of it is shipped. Very quickly, however, this becomes horribly expensive, because it's a complicated problem with any language and JS is really not suited to static analysis and static code optimizations. Of course, another part of the problem is that the delivery format of JS (i.e. the source code) is optimized for small files. For larger files, we can do much better. This is the objective of this project.
- deleted 9y ago
  [deleted]
- codedokode 9y ago
  > or that the Telegram binary weighs ~11Mb? The memory footprint of a native and JS app is very different. While 11Mb Windows app won't require more than 11Mb of memory for the code, JS 11Mb app might require some 50-100 Mb of memory only for keeping the code, different caches and internal structures.
  - Yoric 9y ago
    I'm more than happy to discuss memory footprints, but since this proposal is about parsing speed and file size, that might be a little off-topic :)
kalleboo 9y ago
We're not stopping until facebook.com is the same 240 MB download that Facebook for iOS is. ...but service workers so users will love it!!! ...right?

rtpg 9y ago

I feel like this is an unfair criticism unless you know what the page is doing. People are building entire vector editing programs on the web. How can you be fine with Photoshop being several hundred megs but not with this person having less than 10 megs of code to achieve something similar? The web isn't just Hacker News and CNN. People write real programs on it. Obviously shipping less code is Good(TM). But isn't an across the board improvement also good?

chroem- 9y ago
>People are building entire vector editing programs on the web. This is the exception rather than the rule. There is no reason why it should take more than ten seconds to load a static news article with text.
- spoiler 9y ago
  In which you—and the original starter of this comment thread—completely missed the point. The linked page clearly uses complex applications as examples. Whatever anyone's opinion of them are, they are quite complex. This proposal is aimed at web applications, not a simple website with image/text content, and minimal javascript.
  - mirko22 9y ago
    Yet Google Sheets and Gmail are applications, Facebook and LinkedIn are websites which might as well be fully static and are twice the size so his point is kinda correct. Mind you, Gmail also has features like Chat as do Facebook and LinkedIn.
    - djeric3 9y ago
      Facebook.com does a lot more than show a newsfeed, profiles, and notifications. - It contains a fully-fledged messenger application that supports payments, videoconferencing, sharing rich media etc - The newsfeed supports interactive 360-degree video, a live video player, mini-games in the newsfeed, and lots of other rich/interactive media - It's a gaming platform for 3rd party games - It's a discussion forum, groups management system, event planning UI - Photo sharing and editing platform, as well as live video streaming tool - A platform for businesses to have an online presence (Pages) - A peer-to-peer online marketplace (called "Marketplace") And a dozen other things I can't think of right now. You might say "but I don't use all of those things". That's another tricky part, the fact that every user has a different "configuration" and different types of content in their newsfeed at any given moment, requiring them to be served different sets of JavaScript code.
      - codedokode 9y ago
        Most of these features are unnecessary until the user tries to play a video, a game, opens a dialog etc.
        djeric3 9y ago
        Right, and that's what happens today, the JS for the secondary functionality is loaded on demand. Here's what I have in my FB homepage during a random load: - Search bar for searching people/groups/posts/pages - News ticker - Friend requests, Notifications - Sidebar ads - A rich text editor for sharing my status - A newsfeed story with a special "memory - 3years ago" feature - Comments & commenting UI under newsfeed stories - Suggestions for "People You May know" - A video auto-playing a clip from a friend, with capability to auto-select between tracks of different video quality based on bandwidth (including bandwidth estimator code) - And probably a dozen different A/B experiments that I'm a part of It takes a lot of code just to render all these UI elements. If I interact with any of them, additional code is loaded (you can see this in the Network monitor). This homescreen UI is as rich as any desktop application and requires no less code to render. The problem being addressed in this proposal is that a native version of this app would start a lot faster than the web version. And that's because a browser will parse all the code files loaded on startup in an app (inefficiently, by necessity), but a native app will only read the code for the code paths that are actually executed. Basically, O(code executed) is a lot better than O(all files containing code that is executed). And this proposal features a more parser-friendly encoding and change to the parsing semantics.
- lewisl9029 9y ago
  I think the point was, the premise of the OP's original "solution" was a sweeping generalization that doesn't apply to non-trivial web _apps_ that have a large amount of inherent complexity, which is then necessarily reflected in the size of their codebases. This proposal aims to provide a real solution to tackle problem.
- codedokode 9y ago
  That should take less than one second, not ten.
seanwasere 9y ago
fb et al are creatively siphoning up your data, it's legal for them to do it of course

deleted 9y ago

[deleted]

abritinthebay 9y ago

This is quite mean. There is nothing wrong with doing both this and cutting down on bloat.

chrismorgan 9y ago
There’s nothing wrong with it, but it won’t happen. If no one had ever cared about performance in browser engines, we wouldn’t have the problem of massive pages that we have now. Things like Facebook would have to be more efficient about how they do things. By making loading faster, you reduce the incentive for them to reduce their own bloat. Of course, on the other hand, if browsers were still slow, there are various things that people can do now which they wouldn’t have bothered with before. A vector graphics engine or sound engine, for example, would have been impossible with the browser functionality of now but the performance of ten years ago, because they would have been unbearably slow. You win some, you lose some. Mostly you just end up with an unhappy balance that keeps no one really happy.
- abritinthebay 9y ago
  I agree it won’t happen but that doesn’t make the original comment any better.

Yoric 9y ago

As you probably know, building a sophisticated application can easily become quite complex. This is the case even if the application is designed to look non-sophisticated, as Twitter or Facebook, for instance. Now, when we are discussing desktop applications or mobile applications, people typically do not care all that much about the codesize, because it is essentially invisible to the user. For instance, who cares that the Steam binary (just the binary, without resources or dynamic dependencies) weighs 3.1Mb or that the Gimp binary (again, without resources or dynamic dependencies) weighs ~9Mb or that the Telegram binary weighs ~11Mb? On the web, of course, since the application is downloaded dynamically, rather than being installed, people don't expect to wait and they start noticing. In some cases, web developers can fine tune their JS to make sure that less of it is shipped. Very quickly, however, this becomes horribly expensive, because it's a complicated problem with any language and JS is really not suited to static analysis and static code optimizations. Of course, another part of the problem is that the delivery format of JS (i.e. the source code) is optimized for small files. For larger files, we can do much better. This is the objective of this project.

deleted 9y ago
[deleted]
codedokode 9y ago
> or that the Telegram binary weighs ~11Mb? The memory footprint of a native and JS app is very different. While 11Mb Windows app won't require more than 11Mb of memory for the code, JS 11Mb app might require some 50-100 Mb of memory only for keeping the code, different caches and internal structures.
- Yoric 9y ago
  I'm more than happy to discuss memory footprints, but since this proposal is about parsing speed and file size, that might be a little off-topic :)

kalleboo 9y ago

We're not stopping until facebook.com is the same 240 MB download that Facebook for iOS is. ...but service workers so users will love it!!! ...right?