Live data from Hacker News

Web frameworks are transforming from runtime libraries into optimizing compilers

tomdale.net

81–90 of 231 posts

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

#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

I’ll take Svelte as an example. Say, a component written in Svelte is 2 lines long. The compiled JS file of that component is around 200 lines long (verified). Out of these 200 lines of code, almost a hundred lines are repeating units that occur in every component file.

By the time my app reaches a hundred components, this extra 100 lines gets multiplied by 100 times. This bloat is exactly what we want to avoid with runtime frameworks.

So, let’s think of the simplest solution.

Why not ship these repeating units of code as one module/set/block of code, that gets reused in different places? But wait, isn’t that block of code is what we call “Runtime Frameworks” ?

I still think compile-time frameworks are the best bet we’ve got. Would be helpful if somebody can throw light on these aspects though.

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

#82
In 2002, the Laszlo Presentation Server compiled XML with embedded JavaScript to swf (Flash) byte code. [A later version also compiled to HTML. Performant cross-browser dynamic HTML was daunting in 2002.]

We considered HTML's “View Source” feature important, so we emulated this by causing the compiler to place a formatted source file in the output asset directory, and to embed a “View Source” popup menu. You could turn this off, and probably would for a deployed app, but the nudge was there.

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

#83
post #65

Earlier quoted context omitted.

The sadness does not step from the size of a random binary file per se. The sad part is the prevalence of attitudes deemed unprofessional among people of a certain profession. It's sad for example, that with all the technologies available to us, to imagine what we could have, and compare it with what we do have.

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.

That's only true if you believe focusing things with " substantive effect on consumer response" is the right thing to do. It sounds like a good heuristic in theory, but the practice clearly shows that we ought to be able to do better than that.

I mean, if only fraction of the effort that goes towards making things shiny and sexy went towards making them efficient and actually useful, the computing world would be better, for no loss in actual capabilities (and likely great gains).

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

#84

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…

Svelte author here. If you're using a bundler integration like rollup-plugin-svelte or svelte-loader (for webpack), those repeating lines of code are deduplicated across components. There's a bare minimum of repetition, and we're in the process of reducing it further. You'd be surprised at just how well it scales!

Browser inconsistencies are much less of an issue than they used to be. There are only a couple of places (e.g. listening for both 'input' and 'change' events on , to satisfy IE and everyone else) where we need to accommodate differences.

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

#85

Earlier quoted context omitted.

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.

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.

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

#86

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, the Svelte approach would probably be faster than React (at both rendering and updating) and would use less memory (no virtual DOM, no diffing, just fast granular updates).

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

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

#87
post #11

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

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.

Because for many consumers, 40MB where it could be 4MB means e.g. 5 minutes of download instead of 30 seconds, or 4% of their data plan instead of 0.4%.

And waste is kind of like honesty - if you are wasteful with this, you're probably wasteful with everything else. Like with storage usage, which is a hard constraint on anything but top-of-the-line mobile phones. Like with network usage. Like with energy usage, which accumulates over everyone making wasteful software and adds up into lots of unnecessary emissions.

As a consumer, I don't care about who is first to the market. Take extra time to make your application not suck. It doesn't take that much more.

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

#88

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.

That's only true if you believe focusing things with " substantive effect on consumer response" is the right thing to do. It sounds like a good heuristic in theory, but the practice clearly shows that we ought to be able to do better than that. I mean, if only fraction of the effort that goes towards making things shiny and sexy went towards making them efficient and actually useful, the computing world would be bett…

> That's only true if you believe focusing things with " substantive effect on consumer response" is the right thing to do.

I like eating. Which means I like getting paid. Which means the companies I work for have to focus on things like "substantive effect on consumer response" to keep getting money to pay me.

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

#89
post #11

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

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

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

#90
> Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web.

Sure. And then your investor comes knocking on the door, sits down, looks at you judgingly, inhales smoke from his $200 cigar and says that he wants more returns from your startup. And you have no choice and have to put 10+ spy... - errr, advertisement, I meant advertisement! - scripts, and your web app consumes those 40MB easily.

Don't act like web development is some small elitist circle where things are done extremely well, are optimized, and are with attention to technical detail.

They are not. JS is a shit-show still. Compilers help, I agree. You can't go anywhere without reusable code though. Also known as "runtime frameworks".

Post reply on HN