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

131–140 of 231 posts

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

#131

Post by atonse »

grondilu wrote: post #76

The 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 library or a JS based audio-engine that runs at near-native speeds)

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

#132

Post by bananicorn »

JBiserkov wrote: post #27
bananicorn wrote: post #14

Earlier quoted context omitted.

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

That's actually really amazing - and I didn't know that, thank you!

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

#133

Post by bpicolo »

kylecordes wrote: post #117
bpicolo wrote: post #111

Earlier quoted context omitted.

Angular 4 does code splitting, but it's bundle size carries a pretty big baseline

Beyond code splitting, I wonder if a future Angular version may do more aggressive compilation as the linked article and much of this discussion describes, to reduce that baseline. I have written quite a lot of Angular code, and I don't think there is really all that much from and application point of view that absolutely requires a large baseline run time. Much of the same experience and application code base (perha…

They're definitely aiming to make use of the closure compiler (which is why they went with Typescript as a default)

https://github.com/angular/tsickle

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

#134

Post by mbrock »

andy_ppp wrote: post #33

Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent…

I once wrote an app that worked by sending diffs, not DOM diffs but JSON diffs which were then applied by the client and rendered by React.

The data store was a repository, and so a client could ask "please give me the diff between states X and Y", and the server would make a diff between those trees in the repository.

Most of the time the client would be long-polling for a new revision with the diff based on the previous one, which could be cached efficiently, but sometimes a client would come back from "hibernation" and ask for a diff based on an older revision.

It was a nice system, I never tried to make it "scale" though.

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

#136

Post by wutwutwutwut »

hhjkjhkjhhlkj wrote: post #89
wutwutwutwut wrote: post #71

Earlier quoted context omitted.

What is sad about this? Small sizes are nice but as a consumer I don't care much. If a larger file size means that apps can be produced easier then I have zero objections.

I had to upgrade my phone because it ran out of internal memory and I had to keep removing apps I valued, as they all grew in size. So bloat cost me real money. Just because you don't care doesn't mean others don't. This is one of my pet peeves. Developers building things on high spec machines with fantastic network connections. Your website is impossible for others to use as it is so slow and cumbersome but the devs…

So you think the world is sad?

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

#137

Post by yorwba »

hhjkjhkjhhlkj wrote: post #89
wutwutwutwut wrote: post #71

Earlier quoted context omitted.

What is sad about this? Small sizes are nice but as a consumer I don't care much. If a larger file size means that apps can be produced easier then I have zero objections.

I had to upgrade my phone because it ran out of internal memory and I had to keep removing apps I valued, as they all grew in size. So bloat cost me real money. Just because you don't care doesn't mean others don't. This is one of my pet peeves. Developers building things on high spec machines with fantastic network connections. Your website is impossible for others to use as it is so slow and cumbersome but the devs…

Network connections can be artificially limited (even to localhost): https://stackoverflow.com/questions/130354/how-do-i-simulate...

To simulate a lower-spec machine, you can just run some resource-hungry processes in the background.

The problem is of course that almost nobody bothers to run these tests unless they already care about performance on low-end devices.

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

#138

Post by izacus »

kuschku wrote: post #97
izacus wrote: post #68

Earlier quoted context omitted.

Android code goes through ProGuard on release usually, which is an optimizer (and obfuscator if enabled). It usually makes a lot of optimizations on bytecode level which makes decompiled code noticably harder to read.

If you disable the obfuscation, ProGuard code still looks basically the same. I never enable the obfuscation, as my apps are GPL anyway, and I want users to be able to just decompile any version.

Not really - ProGuard does several optimizations (finalization, removal of redundant bytecode instructions, pulling up methods into superclasses, removing needless sublcasses, some fixes to handling exceptions and several other things depending on optimization settings) which change the bytecode output to the point where you don't have a two-way mapping from Java to compiled code anymore.

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

#139

Post by noshbrinken »

> 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 write source code that compiles to JavaScript "bytecode" is not a recent idea. A much more nuanced reflection on that idea can be found here: http://composition.al/blog/2017/07/30/what-do-people-mean-wh....

With all the hand-wringing about "JavaScript fatigue", it's a little bit sad that prominent JavaScript developers use titles like "Compilers are the New Frameworks". The tone of this title is the tone of a bell ringing for the next round of JavaScript fad musical chairs.

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

#140

Post by eeZah7Ux »

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.

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

Post reply on HN