Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
fuckyouall3242305dSorry, slight correction since I know someone will comment about it (I should really proofread these before I post):
DoddyDigital4305dYeah, JS is weird... Let's rewrite React using C?
Root78129305dI’ve said it before, and I’ll say it again.
Web development is the bastardization of programming.
SortOfTested24395305dI suppose the bright side is it's at least slightly better than bootcamp kids worshipping Dan Abramov for the same reason late 90s kids worshipped Seetharaman Narayanan.
Oh wait, no, sorry, it's for exactly the same reason. 🚬
aviophile4057305d80% of articles on medium is stupid. Tech ones included.
hjk1013532305d@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.
hubiruchi2182305dWho tf is Rich Harris? I find the graphics editor of the NYT? Is this the same person?
AvyChanna815304dFlutter does tree shaking. But the catch is, you are not allowed to(?) make those kind of references (say, runtime reflections).
* My knowledge on flutter(dart) might be a bit rusty. Don't judge *
polv37304dSo what? What's a proposed solution?
Smarter IDE, like Java's?
polv37304d@junon But then again, what's the proposed solution for smaller data sent?
bittersweet44773304dBrowsers 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.
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.
bittersweet44773304d@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.
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:
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."
d4ng3r0u54609304dJS is made by infinite monkeys with infinite typewriters.
Fast-Nop36328304d@junon The main performance reason of C over JS is that C devs have to understand how a computer even works.