Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web frameworks are transforming from runtime libraries into optimizing compilers

tomdale.net

Post reply on HN
Print view View original

21–30 of 231 posts

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

#21

Post by inian »

devveppev wrote: post #15

> When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns. Are you saying that web developers are writing the best code that they can? That future gains are going to come from more advanced js preprocessors instead of more informed developers? I strongly disagree that we have reached any sort of diminishing returns when it c…

> I think the author would benefit from learning about how web frameworks work, or perhaps how web specs mandate that your browser works.

Haha, he is the creator of Ember.js. I think he knows a thing or two about web frameworks ;)

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

#22

Post by hectorlorenzo »

harwoodleon wrote: post #13

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…

> If the whole community effort was spent creating a better UI/UX standard (a standard web front end)

What do you mean by standard? HTML already has a UX/UI standard (technically standard and with some deviations in terms of design implementation depending on the browser). A is always a button and looks like a button in any browser.

The problem is that it looks awful if you are not Stallman. Both Android and iOS have been improving and refining (visually!) their UI elements, but this has not been done in the web, basically because there isn't a huge company calling the shots behind it.

If you want to improve that, we are heading in that direction with Web Components, but at the end of the day it's just an abstraction layer over the DOM elements. And I'm not sure I want Google leading the way (with Polymer).

EDIT: Some grammar.

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

#23

Post by cromwellian »

kolme wrote: post #10
cromwellian wrote: post #4

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

Those features are supported in Webpack and other bundlers. Code splitting: https://webpack.js.org/guides/code-splitting/ Tree shaking: https://webpack.js.org/guides/tree-shaking/

It's not quite the same. It has some aspects of Google's module system in terms of de-duping (our internal version automatically splits up all code referenced in more than one place into a tree of synthetic modules) But Closure's optimizations go far beyond the "tree shaking" described here, which is really about pruning unused module dependencies.

Closure does pruning of methods, properties, etc at a fine grained level, moves code at a per-method level between modules, it computes whether functions have side effects and elides unused side-effect-free code, it does type-based optimizations (https://github.com/google/closure-compiler/wiki/Type-Based-P...), the list goes on and on. It's really like having GCC or LLVM for Javascript code. That's one reason why it's slow, because it does far more than the transpilers and minimizers out there.

(As many in another, GWT does many of the same things, being a fully optimizing true compiler)

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

#24

Post by lennelpennel »

cromwellian wrote: post #23
kolme wrote: post #10

Earlier quoted context omitted.

Those features are supported in Webpack and other bundlers. Code splitting: https://webpack.js.org/guides/code-splitting/ Tree shaking: https://webpack.js.org/guides/tree-shaking/

It's not quite the same. It has some aspects of Google's module system in terms of de-duping (our internal version automatically splits up all code referenced in more than one place into a tree of synthetic modules) But Closure's optimizations go far beyond the "tree shaking" described here, which is really about pruning unused module dependencies. Closure does pruning of methods, properties, etc at a fine grained le…

I want to add that you can easily write your own compile pass for the closure compiler as well. All the optimisations described above are just compile passes.

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

#25

Post by cromwellian »

hbbio wrote: post #17
cromwellian wrote: post #4

"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 was also predated by the Opa "framework" which is indeed a compiler for the web platform, announced in 2009 and released a bit later. At the time, people didn't want to hear about a new language so we had to hide behind a framework. But one of the ideas was that there is no sense in bundling libraries at runtime instead of generating exactly the application code that should run. Cf. http://opalang.org (disclaime…

Yup, Opa is pretty nice. It just highlights the differences between "compilers" and "transpilers" which came up in another thread recently. There's a number of transpilers that are fairly simplistic transforms of source languages, or JS->JS translation (lowering ES7/6 to ES5, etc) which do limited whole world optimization, and mostly consist of peephole passes.

Closure, Opa, GWT, Dart, and a few others (ScalaJS?) run fully optimizing compiler passes like a traditional old school compiler. For example, IIRC, Dart transforms (or used to) to Hydrogen IR/SSA internally, runs lots of optimizations, and then transforms back before JS output.

This is not to bash transpilers, but I don't consider Webpack/Babel/Uglify in the same category.

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

#26

Post by JBiserkov »

cromwellian wrote: post #4

"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 Google Closure compiler and library are used as targets by the ClojureScript compiler https://clojurescript.org/about/closure

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

#27

Post by JBiserkov »

bananicorn wrote: post #14
cromwellian wrote: post #4

"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 Closure Compiler is the only reason I have Java installed, it's that good. And IMHO, a lot of the bloated JS projects nowadays would really profit from its dead code removal...

In case you haven't heard, you can now use it without Java https://developers.googleblog.com/2016/08/closure-compiler-i...

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

#28

Post by albertgoeswoof »

nathell wrote: post #11

> a small 40MB iOS app What a sad, sad world we find ourselves to live in.

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

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

#29

Post by madeofpalk »

harwoodleon wrote: post #13

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…

Honest question: apart from nerds, what reason do we have for valuing 'View Source'?

I mean, you can't 'View Source' anything of the computer the browser is running on, or the browser itself.

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

#30

Post by vim_wannabe »

albertgoeswoof wrote: post #28
nathell wrote: post #11

> a small 40MB iOS app What a sad, sad world we find ourselves to live in.

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

Drop every other issue right now! /s
Post reply on HN