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

Tree-shaking, the horticulturally misguided algorithm (2023)

wingolog.org

Post reply on HN
Print view View original

101–110 of 151 posts

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#101

Post by wizzwizz4 »

FrustratedMonky wrote: post #96
wizzwizz4 wrote: post #75

Earlier quoted context omitted.

Wasm doesn't let you do that unless the native bindings are exposed. The web is really not a bad interface for building GUIs: Microsoft reckoned it was the way forward, back in 1999. https://learn.microsoft.com/en-us/previous-versions/ms536496...

I'm aware web pages exist. I don't think there is much argument that HTML+JavaScript was actually a set backwards that we've been trying to build out of for 20 years. What the web solves is mass distribution. But for programming it is awful.

Are you familiar with the WAI's Authoring Practices Guide? https://www.w3.org/WAI/ARIA/apg/patterns/

"Old-fashioned" desktop GUI systems, like Win32 MDI, are built out of composeable widgets. HTML is built out of composeable widgets. Whatever you do with Wasm and direct pixel rendering? That isn't.

The travesty that is modern web development is, absolutely, a step back from what we had back in the day. But that's not inherent to the web: it's a deficiency of practice. Many web APIs are delightful, and while they're all clunky, Win32 MDI also has its footguns. https://devblogs.microsoft.com/oldnewthing/20120213-00/?p=83...

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#102

Post by troupo »

wizzwizz4 wrote: post #73
kentonv wrote: post #36

Earlier quoted context omitted.

These are good questions and I think there's more than one answer that's worth exploring. I think that the privacy problems caused by shared caches could be solved, without simply prohibiting them altogether. Like, what if you only use the shared cache after N different web sites have requested the same module? But if we really can't get around that problem, then I think another approach worth exploring is for there…

> Like, what if you only use the shared cache after N different web sites have requested the same module? That would still let websites perform timing attacks to deanonymise people. There's no way to verify that "N different websites" isn't just the same website with N different names. Though, we could promote certain domains as CDNs, exempt from the no-shared-cache rules: so long as we added artificial delay when it…

The problem is the libraries. Browsers are still mostly incapable of delivering usable workable building blocks especially in the realm of UI. https://open-ui.org/ is a good start, but it will be a while before we see major pay offs.

Another reason is that the DOM is horrendously bad at building anything UI-related. Laying out static text and images? Sure, barely. Providing actual building blocks for a UI? Emphatically no.

And that's the reason why devs keep reinventing controls. Because while details/summary is good, it's extremely limited, does not provide all the needed features, and is impossible to properly extend.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#103

Post by troupo »

FrustratedMonky wrote: post #8

Maybe off-topic. But can't you use WASM to create GUI's like Photoshop, with no JavaScript or DOM? Isn't the bigger goal of GUI's on WASM is we can jettison JavaScript/DOM and go back to writing GUI's like 10-20 years ago, with simpler libraries. Like SKIA, or something. Using non-web GUI libraries, since they could be compiled to WASM and run in web. EDIT: Native. I mean pre-web, when GUI libraries were native, ever…

> But can't you use WASM to create GUI's like Photoshop, with no JavaScript or DOM?

Yes, you can. If you have the time and the money. To quote Figma: "Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.": https://www.figma.com/blog/building-a-professional-design-to... And that's just for the canvas part. Figma's UI is React.

you need a good UI library if you want to do it like native. And native platforms have those. There's nothing of the sort for any of WebGL/Canvas/WebGPU

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#104

Post by troupo »

FrustratedMonky wrote: post #23
skywhopper wrote: post #16

As things go along, I’m more and more mystified by WASM’s apparent design. It feels like 1996 Java for applets, but without the built-in GC, stdlib, or even the most basic hooks into the browser. Which means it’s basically useless for what I assume its goal is, of letting you use languages other than JavaScript to code a web page. Without trivial DOM access, what’s the point? Other proposed usages like for FaaS-style…

I might not be understanding. But I thought WASM was to replace .NET and JAVA VM's. But, without a VM, to be more a pass through to the underlying CPU. So much faster. So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the underlying HW. So goal was speed. And to allow other languages to compile to it.

> But I thought WASM was to replace .NET and JAVA VM's.

It's name is literally web assembly. It's goal was never and still isn't to replace those VMs. It was literally an idea to create a faster code sandbox for the web based on the idea's from Mozilla's asm.js

> to be more a pass through to the underlying CPU. So much faster. So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the underlying HW.

wat.

> So goal was speed. And to allow other languages to compile to it.

Yes, it was. Has nothing to do with the fantasy of replacing JVM and .Net VM or running directly on hardware.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#105

Post by nextaccountic »

01HNNWZ0MV43FF wrote: post #10
__s wrote: post #3

I've kept openEtG's wasm blob (card game engine) 1. avoid floats (fixed point arithmetic saved quite a bit of space) 2. avoid hashmaps (originally used hashmaps since it was easy to port JS maps to, have since ported everything to vecs) 3. avoid strings (for awhile there were no strings, but eventually brought it in for display logic) 4. use a small allocator, like talc 5. avoid dependencies. I only use rand & fxhash…

Wow! Do you have numbers anywhere showing the space saved? Especially for step 6, using a Vec as a Box, I would not expect that to save much.

he meant Box (aka fixed-size vec or heap allocated array) rather than Box (a single heap allocated element)

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#106

Post by FrustratedMonky »

troupo wrote: post #104
FrustratedMonky wrote: post #23

Earlier quoted context omitted.

I might not be understanding. But I thought WASM was to replace .NET and JAVA VM's. But, without a VM, to be more a pass through to the underlying CPU. So much faster. So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the underlying HW. So goal was speed. And to allow other languages to compile to it.

> But I thought WASM was to replace .NET and JAVA VM's. It's name is literally web assembly. It's goal was never and still isn't to replace those VMs. It was literally an idea to create a faster code sandbox for the web based on the idea's from Mozilla's asm.js > to be more a pass through to the underlying CPU. So much faster. So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the und…

Of course, that is where it started. I'm probably being loose in terminology.

I assumed that to gain this speed, that it was a little closer to the metal than a VM like Java. That it must have some kind of pass through to allow commands to run on the local HW, not just emulated in a VM. So like a VM in that you can compile to it, but it would execute natively.

From the FAQ.

"WebAssembly aims to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms. It is a low-level assembly-like language with a compact binary format that runs with near-native performance"

And when looking at the Use Cases, it seems to be trying to do a lot more than javascript.

https://webassembly.org/docs/use-cases/

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#107

Post by avodonosov »

screcth wrote: post #34
kentonv wrote: post #15

This article is very correct: Wasm has a code size problem. This is a problem in browsers because all that code has to be downloaded to start the site. It's also a problem for serverless architectures, where code is often loaded from cold storage to a specific server on-demand while a client waits. Tree-shaking might help, but I feel like it's only an incremental optimization. Fundamentally the reason Wasm programs a…

Could it be possible to do "profile guided tree-shaking" to build a small module with all the code that's necessary for the application and pull-in less used functionality on-demand using dynamic linking? If tree-shaking was done based on production information it may be possible to prune a lot of dead/almost-dead code without having to implement sophisticated static analysis algorithms.

I experimented with that for javascript: https://github.com/avodonosov/pocl

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#108

Post by FrustratedMonky »

wizzwizz4 wrote: post #101
FrustratedMonky wrote: post #96

Earlier quoted context omitted.

I'm aware web pages exist. I don't think there is much argument that HTML+JavaScript was actually a set backwards that we've been trying to build out of for 20 years. What the web solves is mass distribution. But for programming it is awful.

Are you familiar with the WAI's Authoring Practices Guide? https://www.w3.org/WAI/ARIA/apg/patterns/ "Old-fashioned" desktop GUI systems, like Win32 MDI, are built out of composeable widgets. HTML is built out of composeable widgets. Whatever you do with Wasm and direct pixel rendering? That isn't. The travesty that is modern web development is, absolutely, a step back from what we had back in the day. But that's not…

I agree. Still looking for something that bridges that gap, to make modern web pages as simple as old WinForms.

The only web based tools that I've come across that seem to hide all the JavaScript/html, and be 'simple' are tools like Elmish, or some of the other functional programming 'DSL's. Where the page is kind of composed by functions that compile into the JavaScript. With JavaScript, by the time I'm manipulating the DOM, I keep thinking some tool should be handling this for me.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#109

Post by avodonosov »

kevindamm wrote: post #52
screcth wrote: post #34

Earlier quoted context omitted.

Could it be possible to do "profile guided tree-shaking" to build a small module with all the code that's necessary for the application and pull-in less used functionality on-demand using dynamic linking? If tree-shaking was done based on production information it may be possible to prune a lot of dead/almost-dead code without having to implement sophisticated static analysis algorithms.

There is a substantial risk there unless you can hit all the edge cases and error conditions when profiling. Even a good fuzzer can miss a very rare state. Then when you hit it in real use there's no code to handle it! Profile-based optimization and JITting is plausible because the corner cases are still there, just not optimized.

"less used functionality on-demand" - so the code to handle the rare case remains available, on demand.
Post reply on HN