Isn't the JavaScript engine itself doing a good enough job of optimizing the JavaScript code !?
Web frameworks are transforming from runtime libraries into optimizing compilers
151–160 of 231 posts
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#152The author mentions WebAssembly, yet writes at the end : " and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day." WebAssembly is designed to run in a sandbox. I suppose that does not by itself make it completely safe, but it can not be much worse than the current situation, can it?
I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR libr…
Yeah. I don't understand why people want this, or why people think it will bring huge performance gains… but someday in the future wasm will get direct DOM access. (And right now it's possible by exposing JS functions to wasm.)
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#153Earlier quoted context omitted.
How do you know the 40MB download wasn't aggressively optimized down from 400MB? Equating larger file size with lower quality is presumptuous. Is there any known correlation? Equating larger file size with lower honesty seems dishonest to me. Optimizing takes time, sometimes a lot of time. I know because I've spent a lot of time optimizing file sizes to fit on game consoles, taking xbox360 games over to the Wii for e…
> How do you know the 40MB download wasn't aggressively optimized down from 400MB? I don't; I thought the context made it clear, that I meant relatively trivial apps that do little but are bloated internally. > Is there any known correlation Possibly, I don't know. But I also learned that heuristic from experience. When large app sizes are justified, you usually see this in functionality. > That's a significant waste…
That's all fair. I don't like bloat either. I'd suggest the ecosystem is more to blame than individuals devs. Apple and Google could do more to fix this problem than anyone else. It's too easy to make a basic app that's large, and it takes too much effort to get the file sizes down. If it were easier to make a small app than a large one, apps would be smaller.
The real problem is economic, which is why I brought up food & gas. We are optimizing them slowly, but it's not happening quickly because it takes too much effort and consumers don't care enough. You're right that not optimizing is externalizing the waste onto consumers, and that user waste happens at a vastly different scale than developer waste. Which is why if consumers made a big enough stink, the problems would get fixed more quickly.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#154If you want to make a pure web app without server side "rendering", you should forget about HTML/XML and only use JavaScript and CSS. Managing GUI state in JavaScript sure is boring at first, but the trick is to use functions and abstractions, event listeners/observers, and plugin patterns. Then it becomes fun again, the performance is good, the source code is small, and it's easy to debug. Stop using in your web app code!
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#155Earlier quoted context omitted.
> How do you know the 40MB download wasn't aggressively optimized down from 400MB? I don't; I thought the context made it clear, that I meant relatively trivial apps that do little but are bloated internally. > Is there any known correlation Possibly, I don't know. But I also learned that heuristic from experience. When large app sizes are justified, you usually see this in functionality. > That's a significant waste…
That's all fair. I don't like bloat either. I'd suggest the ecosystem is more to blame than individuals devs. Apple and Google could do more to fix this problem than anyone else. It's too easy to make a basic app that's large, and it takes too much effort to get the file sizes down. If it were easier to make a small app than a large one, apps would be smaller. The real problem is economic, which is why I brought up f…
I agree with everything you wrote here. I too see the problem as primarily systemic.
The problem here is also that users are kind of "captive consumers" of software; i.e. more often than not, there's no other choice besides either using or not using a piece of software. And even if there is a choice, it's usually between two or three pieces of softare, all competing with each other on shiny features and accumulating bloat at tremendous speed.
The frustration is there though; it shows in the rare cases when there is a partial choice. For instance, I know plenty of people who refuse to use Facebook app because of the battery usage, and instead choose to go to Facebook mobile site (which is objectively more annoying and less user-friendly than the app).
> Which is why if consumers made a big enough stink, the problems would get fixed more quickly.
Which is why I do my part in making the stink, complaining about the bloat and waste in places where both users and developers can hear, besides trying to ensure my own backyard (at work and otherwise) is as bloat-free as possible. I guess that's the best I can think of without going into full advocacy mode.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#156Whilst I am in favour of the optimisation of resources (and use these sources) we are willingly moving the "View Source" model to for profit entities like github. In the way the internet has evolved we really should look hard it the elephant in the room: the DOM is for documents - not for interfaces. IMHO optimisation for javascript is just a short term fad (hopefully) and browsers will adopt a more open approach to…
> Whilst I am in favour of the optimisation of resources (and use these sources) we are willingly moving the "View Source" model to for profit entities like github.
It's not necessarily an either/or. We invented sourcemaps so that we can continue to debug the code we write. There is nothing stopping us from copying our sourcemaps and source files to Production for ourselves (let's face, we all sometimes try to debug Production) and even for those next generation programmers that get curious how we build what we build.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#157> The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate.
No, the Babel trend is decelerating thanks to ES6 being supported practically everywhere. Minifiers (based on Babel :D) are still used but they're not that necessary thanks to HTTP compression.
We have a component model with Custom Elements, encapsulation with Shadow DOM, variables (custom properties) in CSS, JavaScript with classes and modules, and HTTP/2 push to deliver these modules without extra roundtrips. The future is more platform, less tooling.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#158The thing you have to always remember is there is no specific language that is JavaScript.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#159> The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate. Not to be pedantic, but are UglifyJS and Babel "frameworks"? Not a Ember user, so maybe Ember has some sort of built-in source code transformer and that's what the author is referring to? I think the basic idea that JavaScript developers, especially those working in a browser environment, will increasingly wri…
> Not to be pedantic, but are UglifyJS and Babel "frameworks"? The article doesn't make that claim, which kinda invalidates the "pedantry strawman" the rest of your comment is based on.
>...what we call web frameworks are transforming from runtime libraries into optimizing compilers.
I took that to mean that the frameworks are doing the optimization. But the article doesn't give examples of the frameworks. The only examples of code transforming optimizations are Uglify and Babel. So I thought maybe these were the things the author has in mind and not actual frameworks. I was genuinely confused and prefaced with the aside about pedantry because questioning these kinds of semantics can come across as pedantic.
The second half of my comment stands regardless.
Re: Web frameworks are transforming from runtime libraries into optimizing compilers
#160Earlier quoted context omitted.
That's all fair. I don't like bloat either. I'd suggest the ecosystem is more to blame than individuals devs. Apple and Google could do more to fix this problem than anyone else. It's too easy to make a basic app that's large, and it takes too much effort to get the file sizes down. If it were easier to make a small app than a large one, apps would be smaller. The real problem is economic, which is why I brought up f…
I agree with everything you wrote here. I too see the problem as primarily systemic. The problem here is also that users are kind of "captive consumers" of software; i.e. more often than not, there's no other choice besides either using or not using a piece of software. And even if there is a choice, it's usually between two or three pieces of softare, all competing with each other on shiny features and accumulating…
Well, since the problem is economic, the stink has to be economic. For consumers to make a stink, it means they have to withhold their money and stop purchasing wasteful products, not voice their complaints after purchasing.
Despite how much time we all spend solving problems we fear we have but don't really have, most devs don't actually have the option to spend significant portions of their time optimizing, even if they want to. I've been exposed to squeezing large games down onto a Wii console because it was a requirement to ship, but not because we cared about bloat. We did care about bloat, btw, but we didn't spend anywhere near as much time reducing file sizes on the PS3 as on the Wii, even though we could. It was an organizational decision that I had almost no control over.