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

201–210 of 231 posts

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

#201

Post by naasking »

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've built some prototypes like this, predating web sockets though. Web sockets are simply an optimization over standard form submission.

The problems of state management are the same though. If your protocol isn't stateless, then you're restricted in how you can manage the server, ie. no live upgrades without breaking all clients.

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

#202

Post by leeoniya »

paulddraper wrote: post #171
kevmo314 wrote: post #164

Earlier quoted context omitted.

It's extremely slow compared to the Java version though.

I think it's about 2x slower.

they're the same in name only. but not in perf and not in output.

https://github.com/Rich-Harris/butternut/issues/35

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

#203

Post by nickpsecurity »

Drup wrote: post #199
hbbio wrote: post #173

Earlier quoted context omitted.

It is not really alive as of now. But there is still space for a full stack language and Opa is relevant today. MLstate, the startup behind Opa, shifted to secure communication platforms (built with Opa) and was acquired last year but without Opa itself. Many things we did became hype later (implemented in OCaml, a functional language, JSX before React - I know Jordan played with Opa before building React) and we sti…

Tierless programming languages did not started nor ended with Opa. Eliom is very well alive and kicking (disclaimer: I'm finishing my PHD on the topic), as well as Hop, Split.js, Ur/Web, Links, Websharper, ... I was always very disappointed by the fact that the inner workings of Opa were never described in any way. I can't even really cite it in my PHD thesis, because the documentation for the early (and more interes…

The first I saw was Curl from MIT:

https://en.m.wikipedia.org/wiki/Curl_(programming_language)

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

#204

Post by tannhaeuser »

atonse wrote: post #131
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 libr…

Thanks for putting the discussion back into the realm of reality.

For as long as I'm in IT, there has always been the story of an upcoming holy grail of technology that'll change everything aka the silver bullet. Reading through this thread, that role seems currently occupied by WASM, with wild projections of all kind of perceived problems of frontend development and beyond onto WASM.

The reality is I have yet to see a single app making use of WASM on the web. And even when, if, there eventually is a WASM app, it won't be able to do anything that other (native) development environments haven't been able to do for ages. I'm not sure the world needs a new bytecode format, when only the ARM and x86_64 ISAs are still around. OTOH, what's new with WASM is that the browser and the internet acts as a gatekeeper for starting apps on your device, which I'm not sure will be met with enthusiasm by users. Furthermore, since WASM lacks APIs for even the most basic things, it would take ages to establish a platform, with all the fragmentation this entails.

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

#205

Post by zachrose »

kylecordes wrote: post #120
kuon wrote: post #31

elm is a good example.

Elm is a very good example of a compiler, but (as I recall, unfortunately without information in front of me) it's not that great of an example of doing maximal work at compile time to minimize the size of a runtime support library. I don't remember the kilobytes but they are significant. That said though, since the Elm language is nicely constrained, it seems possible that a future version of the compiler could keep…

The latest thought on this from the Elm community is that dead code elimination should be done after compilation[1] and that this should be easy[2].

I don't think the OP's main point was about file size optimization though. Elm's killer "optimization" is to remove the mutable parts of JavaScript and add a strong type system that can prevent practically all runtime errors. To achieve that goal the source language is significantly different than the target language.

[1]https://github.com/elm-lang/elm-compiler/issues/1453#issueco... [2] https://github.com/elm-lang/elm-make/issues/91#issuecomment-...

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

#206

Post by psyc »

zimpenfish wrote: post #88
TeMPOraL wrote: post #83

Earlier quoted context omitted.

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.

I like at least making the attempt to earn the title "engineer".

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

#207

Post by cdata »

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.

Hardly irrelevant. It's the very people who do worry about food, safety, survival for whom app binary size matters the most. Your users live everywhere on Earth that has a network connection, and in some of those places there are millions or more who consider that connection a scarce, valuable resource.

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

#208

Post by TheAceOfHearts »

TeMPOraL wrote: post #147
dahart wrote: post #124

Earlier quoted context omitted.

How do you know the 40MB download wasn't aggressively optimized down from 400MB? Equating larger file size with lower quality is presumptuous. Is there any known correlation? Equating larger file size with lower honesty seems dishonest to me. Optimizing takes time, sometimes a lot of time. I know because I've spent a lot of time optimizing file sizes to fit on game consoles, taking xbox360 games over to the Wii for e…

> How do you know the 40MB download wasn't aggressively optimized down from 400MB? I don't; I thought the context made it clear, that I meant relatively trivial apps that do little but are bloated internally. > Is there any known correlation Possibly, I don't know. But I also learned that heuristic from experience. When large app sizes are justified, you usually see this in functionality. > That's a significant waste…

Applications become increasingly bloated when they need to support lots of different environments and runtimes.

To give a modern example: if I want a web app to run on a wide range of browsers, I have to include shims and polyfills to handle missing functionality, API differences, and implementation bugs.

But it's not a problem limited to the web, it exists with native applications as well. This is why Electron apps are huge energy and memory hogs. It abstracts every native layer in order for the application to run pretty much everywhere.

IMO, it's not such a horrible thing in some cases. I usually prefer native applications for anything that I'll be using regularly... But electron apps can be incredibly handy for one-off utilities. To give an example I'm personally familiar with: I occasionally use Etcher [0] to burn images to USB and SD cards. I've used it on macOS 10.12, Windows 10, and Ubuntu 17.04 without any issues! The most famous native alternative I'm familiar with is UNetbootin, which didn't seem to work on macOS when I last tried it. Of course, on macOS and Ubuntu I also have the option of using the terminal, which requires me to look up or remember the platform-specific way of listing all disks, identifying the target, unmounting it, and copying the image.

[0] https://etcher.io

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

#209

Post by devveppev »

inian wrote: post #21
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 ;)

And he has come to the conclusion that he is making an optimizing compiler.

Perhaps the reason he thinks web frameworks will help us 'approach native performance' is because he doesn't know what native performance is? Could you really understand web performance if you don't understand native performance?

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

#210

Post by flukus »

zimpenfish wrote: post #88
TeMPOraL wrote: post #83

Earlier quoted context omitted.

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.

> I like eating. Which means I like getting paid.

I'd love to pay you (by buying your app), but because everyone was focused on things that generate a "substantive effect on consumer response" I simply don't have the space on my phone to install your app.

Post reply on HN