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

91–100 of 151 posts

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

#91

Post by Rusky »

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…

The current iteration of WebAssembly was always an "MVP." It's got the core instruction set and memory model to run, essentially, C programs safely and efficiently, and just enough interop with the host to get data in and out.

But it was always the plan to expand on that, and make a wider set of use cases easier and more efficient. Working directly with the DOM really requires some amount of integration with the GC that manages the DOM, for example.

The thing that makes this interesting outside the browser is the security model. Unlike typical environments used for FaaS or whatever else, it's capability based and starts from literally zero- everything a WebAssembly module can touch has to be passed in explicitly when it's instantiated. That's a lot narrower, lighter weight, and more flexible than things like containers.

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

#92

Post by low_tech_punk »

A microcosm of the wasm issue was captured in this thread:

https://github.com/isomorphic-git/isomorphic-git/issues/268

The community had good reasoning around implementing a web based git in JavaScript from scratch instead of compiling libgit2 to wasm.

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

#93

Post by im3w1l »

hinkley wrote: post #33
titzer wrote: post #2

Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…

Proving yet again that there aren’t enough gardeners in computer science. The metaphor we use for optimization is “low hanging fruit” which no orchard owner would ever do. It’s massively wasteful, be you a programmer or a farmer. It’s what amateurs do. I do tree shaking. Pick a tree (subject matter in the code) and get all of the fruit that’s willing to fall off before moving to the next. It’s more efficient, more ef…

You think of orchard owners, but that's not the image it conjures for me. I remember the neighborhood of my childhood. The fruit trees there were 90% decoration. Usually someone would pick one (1) fruit whenever they felt like getting one. Most of the fruits would never get picked at all. The ground would be full of overripe and rotting fruit, until someone could be bothered to clean it up.

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

#94

Post by lelanthran »

azornathogron wrote: post #22
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…

> browsers have various popular language runtimes (and perhaps even popular libraries) preloaded, so that all web pages requiring that runtime can share the same (read-only) copy of that code. That sounds a lot like the idea from some years past that commonly used JavaScript frameworks would be served from a few common CDNs and would be widely enough used to be almost always in cache in the browser, and therefore won…

Maybe not so tricky.

What's wrong with having package management for dynamics libs built into the browser, using signed packages?

Any dynamic lib that is referenced, say /glibc.6.0.2, is downloaded only once, ever.

This is a problem Linux distributions more or less solved ages ago for distribution packages.

Why does a new, more complicated and over-engineered thing need to be invented when a tried and tested mechanism exists?

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

#95

Post by naasking »

HumanOstrich wrote: post #79
naasking wrote: post #63

Earlier quoted context omitted.

> if you break of the dead branch, nothing happens to the tree, just like when you remove unused code, nothing happens to the program. Indeed, and this has been known since the 80s as dead code elimination. So why are we using a new, less descriptive, more confusing term again?

Language and terminology evolve over time. It can be uncomfortable and challenging to adapt. Some new developers might be introduced to the concept initially as "tree-shaking". It's not wrong; it just differs from your preference.

I learned of tree shaking first, and DCE is clearly superior as a term: 1) it's actually descriptive, 2) there's a large literature using this term to look for further information, and 3) as the original poster noted, it's not actually a misnomer. There is literally no advantage to the new term that I can think of.

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

#96

Post by FrustratedMonky »

wizzwizz4 wrote: post #75
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…

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.

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

#97

Post by FrustratedMonky »

ben-schaaf wrote: post #30
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.

> So compile down to a 'byte code' like thing, that does not run on a VM, but runs on the underlying HW. I think you may be confusing "system" virtual machines and "process" virtual machines. The VM here is the thing executing the WASM bytecode; it works the same was as .NET and JAVA VMs.

I understand it is a VM like Java. I was just under the impression that it was somehow better, more streamlined, that would offer enough performance improvement that you could start treating it like running a 'native' local app. Like if I build a 'native' app, a 'thick client', I could now run it on WASM in a browser. Thus not need any local installs, but have same performance.

I've seen some apps doing that. But guess it isn't considered 'the way' for the future?

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

#98

Post by mrob »

dwoldrich wrote: post #58

My philosophy is to work hard at optimizing my javascript with algorithms and design simplifications for size/performance to make room (in bundle size and CPU) for parts of my code that require brute force compute to solve. In my ClubCompy project, I use WASM to implement a FAT filesystem atop local storage, which has proven to be very computationally expensive. And, I plan to use WASM for pixel-perfect sprite collis…

>pixel-perfect sprite collision detection

This is something that sounds like a good idea when you first hear it, but feels unpleasant when you actually play it. Most 2D games use rectangular collision hitboxes for good reason: it's easier for the player to predict if sprites will collide or not. With pixel-perfect collisions, the same movement will collide or not depending on the phase of the animation cycles. It feels bad to fail a movement that always worked before just because the animations happened to line up poorly. And pixel perfect isn't even realistic in many cases; small details on sprites can represent things like cloth or hair that in reality wouldn't cause a hard collision. And sprites often move multiple pixels per frame, so colliding individual pixels increases the chance of them clipping through each other. Simple, predictable collision detection is generally best.

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

#99

Post by neonsunset »

AtNightWeCode wrote: post #45

I have Blazor apps running on Cloudflare pages. They download fast and the performance is great. The load time is terrible though. I think it is unsolvable with .NET. I think the core issue is how everything is entangled by design in oo langs. Also, the amount of money put into js is hard to compete with. Then to also have copy/paste as a lang feature in js is like cheating. Third. With Blazor at least you still need…

Blazor...is not great at this. Currently, the packaging model does not do the justice to capabilities of .NET trimming because of the limitations of how the WASM is currently packaged on top of Mono. If you want to see how well it can actually trim (which everyone seems to like calling tree-shaking, even though it's not exactly right), it is better to try out building regular applications with AOT - they produce small binaries.

The experimental support in runtimelab for NativeAOT-LLVM targeting WASM provides much smaller bundle sizes and much better performance but given that it still is under dotnet/runtimelab rather than dotnet/runtime, I don't know when it will be available.

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

#100

Post by paulddraper »

naasking wrote: post #64
paulddraper wrote: post #49

Earlier quoted context omitted.

Have you... Ever seen a tree? And what happens when the wind blows? Shaking and raking are hardly different in kind.

> And what happens when the wind blows? And wind blowing has what to do with compiler optimizations again? > Shaking and raking are hardly different in kind. The only way they're similar is that they're both kinda dumb names for this optimization that has had a standard name for 40 years.

> And wind blowing has what to do with compiler optimizations again?

The wind blowing shakes the tree.

When the tree shakes, the dead branches and loose leaves are removed.

---

This is similar to when a bundler will traverse the connected code graph and remove the things that are not attached.

Post reply on HN