Live data from Hacker News

Web frameworks are transforming from runtime libraries into optimizing compilers

tomdale.net

181–190 of 231 posts

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#181

"The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate." Those were predated by Closure Compiler, which was started with Gmail, and Closure Compiler in some ways still doesn't have an equal. Besides being a fully optimizing compiler, it also has a module system for code splitting, and optimization passes designed to move code at the method/property level from initia…

The compiler for GWT has done a lot of this for years (and it's functionality might have fed into closure). It's arguably different because it compiles from Java to Javascript as a first pass. It then does a lot of full-program optimization, including dead code elimination, lifting virtual method calls to static, inlining, reordering code to compress better, and analyzing the call graph to split code. (You have to be explicit about the split points in the Java code, so the analysis is mainly for doing the code splitting and for coalescing components that are are small or would force a lot of code into the common segment.)

I believe GWT is moving on to closure for the latter optimization passes in future releases.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#182

"The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate." Those were predated by Closure Compiler, which was started with Gmail, and Closure Compiler in some ways still doesn't have an equal. Besides being a fully optimizing compiler, it also has a module system for code splitting, and optimization passes designed to move code at the method/property level from initia…

This seems to be something of a trend in the software library and tool world: A problem emerges. Some early, sharp thinkers create tools which attack the problem in a high level, abstract, powerful way... but also with the rough edges that come with being early. These tools get a few adopters, but not that many because it is difficult to see the value versus the obvious rough edges. Then other sharp thinkers, put off…

As someone who had some amateur experience with C++ roughly 10 years ago I felt it was sort of deja vu with JavaScript. Transpilers, aggressive optimization, automation scripts it's nothing that was too unfamiliar with me.

Webpack is roughly a library linker. Babel is like GCC Make. Gruntfile ~= makefile. I think it's coming of age but the JS ecosystem is still undergoing growing pains, plus it can be overwhelming to newbies. People are paralyzed by too much choice. Having IDEs like Webstorm would be good at least taming or organizing workflow better.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#183

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. 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."

I don't see this as a problem. They're providing a service, and doing it well. Why should they not be rewarded for that?

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#184

Earlier quoted context omitted.

Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.

People need to stop pulling these "well what about x?" red herrings in an attempt to undermine the discussion.

People also need to stop complaining about things that really are not a problem.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#185
post #141

Earlier quoted context omitted.

Facebook app on iPhone is reporting at 1.02 GB for me. Most space used with the exception of storage-based applications like photos/music.

I knew it was big, but didn't think it was that bad. I'm not familiar with iOS, does that figure include the apps locally cached data and/or embedded resources (I imagine retina images and icons could add up quickly) or is that mostly Facebooks infamously bloated codebase?

No, you're right. His 1GB is mostly cached data. The app is more like 200MB.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#186

Earlier quoted context omitted.

Indeed, we no longer worry about food, safety and survival and instead our sadness is directed at irrelevant application binary file sizes.

> we no longer worry about food, safety and survival Do "we"? You are denying the existence of millions or billions of people who worry about food, safety and survival. Including the ones that work very hard at manufacturing phones so powerful that you don't care about the size of that 40MB app.

The vast majority of people who have the luxury and time to comment on an internet message board on a discussion about the size of binaries are not having to worry about that.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#187
Its funny that companies like Google work so hard to make Javascript interpretation so fast. Yet people write in an abstracted dialect that needs to get compiled down to Javascript because of productivity, convenience, sexiness, or whatever else. So many layers...

A developer spends a lot of time debugging. Its so fun to write Jasvacript in the console. Yet we need source maps to solve the above problem in order to debug the code we wrote.

Some times I feel the amount of engineering we do in defining new frameworks, dialects, transpilers, etc would be better served writing features for our end users. No, we absolutely need that hammer++ to hit that nail.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#188
post #142

Earlier quoted context omitted.

It wouldn't help. If we spent more engineering effort on efficiencies that don't have a substantive effect on consumer response, we're just being inefficient with our time. That will result in less capable software, higher big counts, or higher software prices. Software is written with budgets, and nothing is free.

How would you like it if a car mechanic left extra garbage in your car because he has no time to clean it and you don't know what's underneath the hood anyway so who cares! It's kind of hard to trust someone with that attitude, don't you think? Yet we waste CPU/RAM/Disk space on consumer's devices without hardly giving it a second thought.

Fantastic way of putting it. Developers shirk responsibility too easily

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#189
post #161

> Ember has always been driven by the idea that web apps are becoming more and more like native apps over time. Well, this is what people keep telling again and again, as if it was enough to repeat it to make it real, but I still have to see one web application that I would prefer to use over a desktop one. Sure, we have hugely complex webapps, but the browser is a really a shitty environment to think of it as a "pla…

I think that the Ember community beats this drum because they have no real answer to React Native.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#190
It's crazy to me what amounts to most UI's -- basically forms and buttons, lists of things, images, pages have become so complex.

It's like I've died and woken up in a strange, bizarre world where the laws of physics are different, but I still inhabit the same world.

Does anyone else feel this way? Is this just how technology works?

Post reply on HN