4 ms·

If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. Sure, we can break up our JS

by ender7 14y ago

If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. Sure, we can break up our JS into modules that only get loaded on-demand (something that is quite hard to do, by the way), but eventually there will be lots of Javascript on the page. Because, you know, it's an app. Any app of decent complexity will involve a lot of code. By definition. (as far as image previews go, I agree, that's stupid. Especially given the performance concerns with large images on mobile browsers)

TazeTSchnitzel 14y ago
Eh, I just find it hard to believe FB honestly needs that much just to load the homepage. Now, the whole mobile site? Sure, that seems reasonable, considering how much you can do. But if that's the case, I wonder why Facebook aren't modularising it.
stcredzero 14y ago
> If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. That doesn't follow. We'd only have to give up if you had to have that to display that amount of content. UX should come first. If you don't take care of your customer, someone else will do it for you.
mikeash 14y ago
It seems like a matter of inadequate tools more than anything. When I write native code, I write apps that are broken up into relatively small chunks, which are then demand-paged off the disk when needed. A freshly launched copy of my app that hasn't touched most of its code takes up very little memory. And of course, all apps work that way, because that's how the system is built. It's actually substantially harder to avoid that lazy loading functionality than it is to take advantage of it. Obviously, the systems used to lazily load machine code stored locally are different from what would be needed to modularize and lazily load source code being loaded over the network, but surely there's some way to improve this without making programmers do a ton of grunt work. If pages are loading huge amounts of JavaScript code that goes unused simply because it's easier to code that way, doesn't that mean the tools are deficient?
lttlrck 14y ago
>If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. Just blame the standard? If you designed an app with a 700KB JS analytics dependency that's your issue.
batista 14y ago
>If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. Sure. Let's. As of NOW they are inadequate for mobile devices, provide a sub-par experience to native apps, and move too much redundant BS over the network (even thin client-side-rendering style ones). Heck, some Canvas/SVG demos even bring a Desktop browser to it's knees and the CPU to 100%.

by ender7 14y ago

TazeTSchnitzel 14y ago

Eh, I just find it hard to believe FB honestly needs that much just to load the homepage. Now, the whole mobile site? Sure, that seems reasonable, considering how much you can do. But if that's the case, I wonder why Facebook aren't modularising it.

stcredzero 14y ago

> If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. That doesn't follow. We'd only have to give up if you had to have that to display that amount of content. UX should come first. If you don't take care of your customer, someone else will do it for you.

mikeash 14y ago

It seems like a matter of inadequate tools more than anything. When I write native code, I write apps that are broken up into relatively small chunks, which are then demand-paged off the disk when needed. A freshly launched copy of my app that hasn't touched most of its code takes up very little memory. And of course, all apps work that way, because that's how the system is built. It's actually substantially harder to avoid that lazy loading functionality than it is to take advantage of it. Obviously, the systems used to lazily load machine code stored locally are different from what would be needed to modularize and lazily load source code being loaded over the network, but surely there's some way to improve this without making programmers do a ton of grunt work. If pages are loading huge amounts of JavaScript code that goes unused simply because it's easier to code that way, doesn't that mean the tools are deficient?

lttlrck 14y ago

>If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. Just blame the standard? If you designed an app with a 700KB JS analytics dependency that's your issue.

batista 14y ago

>If the argument is that "you're using too much Javascript" then we all might as well just give up on HTML5 applications right now. Sure. Let's. As of NOW they are inadequate for mobile devices, provide a sub-par experience to native apps, and move too much redundant BS over the network (even thin client-side-rendering style ones). Heck, some Canvas/SVG demos even bring a Desktop browser to it's knees and the CPU to 100%.