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

91–100 of 231 posts

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

#91

Post by rich_harris »

hectorlorenzo wrote: post #86
lewisjoe wrote: post #81

Svelte( https://svelte.technology/ ) is one similar idea. It’s a framework that compiles down to plain JS before being shipped out to browsers. There’s a couple of concerns though: #1 How are we going to manage browser inconsistencies? We are very much better than what we were when jQuery came out. Yet we aren’t 100% there either. Browser inconsistencies, still do exist and runtime frameworks try to deal with it. #2…

Some of these concerns were already mentioned in HN when Svelte itself got discussed ( https://news.ycombinator.com/item?id=13069841 ), and the suggested solutions for problem #2 were (kudos to user callumlocke): - Bundling and gzipping several Svelte components together might compress well – a lot of their size comes from repetitive substrings like `.parentNode.removeChild` and `.setAttribute` etc. - Once downloaded…

According to js-framework-benchmark (http://www.stefankrause.net/wp/?p=431) it doesn't just use much less memory than React, it uses less memory than any other framework, because we don't have the overhead of a virtual DOM. And yes, it's significantly faster.

I answered the deduplication point in another reply to the parent, but you make a great point about code-splitting. If you're using a convention runtime framework it doesn't matter how aggressively you code-split — your smallest chunk will be at least as large as your framework. Self-contained components solve that problem.

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

#92

Post by osteele »

nathell wrote: post #11

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

According to https://sweetpricing.com/blog/2017/02/average-app-file-size/, the average iOS app file size is 38MB. It's much higher for more highly downloaded (and feature-rich) apps; it's probably higher for recent apps.

So 40MB for an iOS app may or may not count as “small”, depending on the comparison set.

But it is small compared to the historical size of applications.

40MB is 0.5% the RAM of an 8MB iPhone.

My first computer, circa 1978, was a TRS-80 with 15KB RAM (+ 1KB for the screen). An application that used 0.5% of its RAM would have taken 75 bytes. I've written but not distributed functionality in programs of that size. I would classify it as small.

An application that used 0.5% the RAM of the original 128K Macintosh would have taken 640 bytes. An application that used 0.5% of its 400K removable storage would be 2K. I suspect there were a lot of 2K applications (bundled as Desk Accessories), but this was considered small at the time.

During my lifetime there's been an explosion in the number, functionality, and quality (as measured in every way other than absolute byte size) of applications, that may be hard to appreciate if you either haven't lived through it, or are focused on one metric. It's pretty cool.

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

#93

Post by TeMPOraL »

pjmlp wrote: post #85
harwoodleon wrote: post #79

Earlier quoted context omitted.

How do non-nerds become nerds? "View source" can be the lid of the pandora's box for lots of young people who become inspired to be developers. Alos the web is not just for nerds! HTML is a language that lots of everyday people can write now - it is empowering.

We were already nerds for a few decades before the browser was invented.

And we (my generation) weren't!

"View Source" is not the only way to start on your way to nerddom, but it is, or at least was at some point in time, an important one.

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

#94

Post by osteele »

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.

I wonder whether the idea of “waste” is triggered by different things for different people, and evokes a moral response.

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

#95

Post by TeMPOraL »

madeofpalk wrote: post #29
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.

Besides the educational value mentioned elsewhere, by browsing the web you're promiscuously executing code sent by random strangers, with whom you have no long-term relationship. It's important to be able to review what comes from them. View Source and dev panel are, and forever should be, an important part of the browser.

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

#96

Post by chii »

grondilu wrote: post #78
chii wrote: post #77

Earlier quoted context omitted.

but isn't wasm something that is supposed to be compiled into native binary? Which means if there's a way to trick the compiler to compile something that looks innocuous, but when run (or somehow exploited) that it does something it's not supposed to? In chrome, the process sandboxing is supposed to protect you - it doesn't matter if it's wasm or not. Does other impl. of wasm does similar security-wise?

> but isn't wasm something that is supposed to be compiled into native binary? No, it compiles into a binary code of its own. That gives it near-native speed, but it's no "hardware-binary" code.

ahh, i thought that the binary format is effectively something you (the runtime) translated into actual assembly (to be then executed).

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

#97

Post by kuschku »

izacus wrote: post #68
TazeTSchnitzel wrote: post #36

OT, but this jumped out to me: > In the same way that a compiled Android binary bears little resemblance to the original Java source code From what I recall, Java binaries actually look a lot like their source code. They're not human-readable of course, but you can decompile them very easily and get fairly good code back out. This made Minecraft an easy game to mod: just decompile a class, change a line or two, recom…

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.

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

#98

Post by curveship »

Just throwing my side project, Surplus, out there as another example of this strategy (https://github.com/adamhaile/surplus). Surplus compiles JSX into optimized code that produces real DOM elements. The combination of an ahead-of-time compiler plus no virtual DOM layer means that the runtime code only has to do the minimal, truly dynamic work.

As a result, Surplus is the fastest framework in Stefan Krauss's latest js-framework-benchmark (http://www.stefankrause.net/wp/?p=431).

DSLs are powerful, compiler support can make them fast.

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

#99

Post by krptos »

hectorlorenzo wrote: post #86
lewisjoe wrote: post #81

Svelte( https://svelte.technology/ ) is one similar idea. It’s a framework that compiles down to plain JS before being shipped out to browsers. There’s a couple of concerns though: #1 How are we going to manage browser inconsistencies? We are very much better than what we were when jQuery came out. Yet we aren’t 100% there either. Browser inconsistencies, still do exist and runtime frameworks try to deal with it. #2…

Some of these concerns were already mentioned in HN when Svelte itself got discussed ( https://news.ycombinator.com/item?id=13069841 ), and the suggested solutions for problem #2 were (kudos to user callumlocke): - Bundling and gzipping several Svelte components together might compress well – a lot of their size comes from repetitive substrings like `.parentNode.removeChild` and `.setAttribute` etc. - Once downloaded…

Thanks for sharing!

That's a lot of good news. Yet, I find it unsettling, that there's always going to be a minimal(after compressing/gzipping) amount of repeating code for every component.

>The self-contained nature of Svelte components makes it easier to treat them as atomic downloads and use them as needed. For example, you could get to a working UI extremely fast, and then download more components for below-the-fold or other pages in the background. This could work well with HTTP/2.

This is a huge win though - if I can load the first component extremely fast with no extra code.

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

#100

Post by hectorlorenzo »

rich_harris wrote: post #91
hectorlorenzo wrote: post #86

Earlier quoted context omitted.

Some of these concerns were already mentioned in HN when Svelte itself got discussed ( https://news.ycombinator.com/item?id=13069841 ), and the suggested solutions for problem #2 were (kudos to user callumlocke): - Bundling and gzipping several Svelte components together might compress well – a lot of their size comes from repetitive substrings like `.parentNode.removeChild` and `.setAttribute` etc. - Once downloaded…

According to js-framework-benchmark ( http://www.stefankrause.net/wp/?p=431 ) it doesn't just use much less memory than React, it uses less memory than any other framework, because we don't have the overhead of a virtual DOM. And yes, it's significantly faster. I answered the deduplication point in another reply to the parent, but you make a great point about code-splitting. If you're using a convention runtime frame…

That is fantastic, thanks for the clarification. The problem with calling self-contained components on demand is more of a mindset one: we've grown too used to compiling everything into one single file and calling it a day.
Post reply on HN