Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Root Agreed.
-
@junon good call on the BS meter. I cringed on the first part. We can easily have the opposite analogy: tree-shaking is silly, is hard and error prone to add things piece by piece instead of perfecting a working base.
Take a wooden statue for example it can be made by taking a nice base shape and chipping away the excess. It by glueing chips of wood together. You will end up with a similar result but obviously the first method will be a far more polished result without bus falling off.
Perhaps go is more efficient at it but yeah at compile time is basically still inclusion and with code unlike the dumb analogies the result is the same weather we select or filter. -
@hubiruchi Yes. Also the creator of Rollup and Svelte.
-
@polv IDEs have nothing to do with this.
-
-
Browsers release pretty rapidly these days. As an example, you can now pretty much use all of ES6 without doing any transpiling. "I'm going to write my frontend in pure ES6" was a ridiculous thing to say 4 years ago.
ES6 made many things a bit nicer, but still doesn't help with optimization techniques common to stricter languages.
However, the "we are stuck with JS because of browsers" argument is slowly becoming weaker.
The whole landscape is a huge mess, but I think things will move away from plain or even transpiled JS.
You're seeing stuff like AssemblyScript, and personally I played around a bit with Yew which I really like as a Rust dev (https://yew.rs) -- More and more toolchains & frameworks come into existence which eradicate the need for JS as much as possible.
It isn't weird to think that in 5-10 years, browsers will have better support for DOM manipulation in a form which doesn't need any "JS glue" at all anymore. -
@bittersweet
I'm happy to see wasm coming up for performance, security reasons. Yew and all the other server-side html rendering frameworks running on the client aren't really viable given the current state of DOM interaction. The state of the art is actually a bit paradigmatically disgusting; something sitting immediately adjacent a robust API for UI events and interactions, which then says "no, I prefer my iteration of the wheel" in the pursuit of making development on the web a monoglot endeavour (imo the worst reason to adopt wasm). The wasm side cannot currently (or in the next few years) be as performant or compact as the js engine itself at the task of computing html payloads, and will need to be a 1:1 facade across the message bus on both sides to be where it needs to be in terms of interactivity and events.
I'm convinced that the aggressive pushing of things like Blazor, yew and elmish are setting us up for a big let down and an industry-wide washing of the hands on wasm because of this. I agree with the sentiment and it seems inevitable to me that a natively-supported DOM->WASM event bridge will be standardized in the next few years, which is going to render most of the effort obsolete, to much rage facing.
In the short term, the focus should be on robust code sharing with the server side, and decoupling of state and transaction logic from JS into wasm, with js (and more importantly the engines behind it) still doing what it does best (DOM processing). That's the sweet spot at the moment. The bartleby frameworks need some serious reconsideration, or realignment before they oversell what at this point is an academic exercise as a solution. -
@SortOfTested Thanks for reminding me that I'm not a frontend dev haha.
90% of what you just said sounds like what my wife hears when I talk about implementing an indexed graph DB in Redis.
But Yew is not really backend rendered HTML though? I mean, it compiles Rust to Wasm, and provides a html macro so templated components get injected into the DOM similar to React/Vue/Angular. It still needs some JS glue for WASM initialization and NPM interop, but that's done transparently by the framework. -
@bittersweet
I'm not front end either, I just have a deep understanding of the things I oversee for my teams. Yew implements that backend rendered paradigm, it just executes it in the browser.
That's not how Angular and React work. They compile to routines that programmatically create the elements and substructures, incorporating all the template logic, directives and rules expressed in the template and behavior definitions. This gives you access to all events and properties available to those elements.
Shoving an HTML string into the browser and saying "parse this" isn't remotely the same thing. Simple things like transitions, enter/exit events, complex hover and interactive behaviors oblige you to produce "glue," also know as "reimplement the browser APIs via the previously mentioned facade."
Problems like this appear consistently in all frameworks that adopt this paradigm because they're structurally broken:
https://github.com/yewstack/yew/...
https://github.com/dotnet/...
You'll note on the Blazor issue, sanderson basically ignored the ticket and replied with the equivalent of "it's not an issue, you don't need what you're asking for."
Related Rants
This never gets old...
Exactly
¯\_(ツ)_/¯
Buckle up, it's a long one.
Let me tell you why "Tree Shaking" is stupidity incarnate and why Rich Harris needs to stop talking about things he doesn't understand.
For reference, this is a direct response to the 2015 article here: https://medium.com/@Rich_Harris/...
"Tree shaking", as Rich puts it, is NOT dead code removal apparently, but instead only picking the parts that are actually used.
However, Rich has never heard of a C compiler, apparently. In C (or any systems language with basic optimizations), public (visible) members exposed to library consumers must have that code available to them, obviously. However, all of the other cruft that you don't actually use is removed - hence, dead code removal.
How does the compiler do that? Well, it does what Rich calls "tree shaking" by evaluating all of the pieces of code that are used by any codepaths used by any of the exported symbols, not just the "main module" (which doesn't exist in systems libraries).
It's the SAME FUCKING THING, he's just not researched enough to fully fucking understand that. But sure, tell me how the javascript community apparently invented something ELSE that you REALLY just repackaged and made more bloated/downright wrong (React Hooks, webpack, WebAssembly, etc.)
Speaking of Javascript, "tree shaking" is impossible to do with any degree of confidence, unlike statically typed/well defined languages. This is because you can create artificial references to values at runtime using string functions - which means, with the right input, almost anything can be run depending on the input.
How do you figure out what can and can't be? You can't! Since there is a runtime-based codepath and decision tree, you run into properties of Turing's halting problem, which cannot be solved completely.
With stricter languages such as C (which is where "dead code removal" is used quite aggressively), you can make very strong assertions at compile time about the usage of code. This is simply how C is still thousands of times faster than Javascript.
So no, Rich Harris, dead code removal is not "silly". Your entire premise about "live code inclusion" is technical jargon and buzzwordy drivel. Empty words at best.
This sort of shit is annoying and only feeds into this cycle of the web community not being Special enough and having to reinvent every single fucking facet of operating systems in your shitty bloated spyware-like browser and brand it with flashy Matrix-esque imagery and prose.
Fuck all of it.
rant
idiocy
tree shaking
javascript
read a book