3 ms·
> todoList.Root.Set("innerHTML", string(newTree.HTML())) Using examples like this are really unconvincing when it looks like old jQuery or vanillaJS. Yes, I
by gedy 8y ago
> todoList.Root.Set("innerHTML", string(newTree.HTML()))
Using examples like this are really unconvincing when it looks like old jQuery or vanillaJS. Yes, I appreciate that folks like whatever they are familiar with and JS is not elegant, but web assembly doing old school DOM manipulation, but now in N number of different languages sounds terrible for maintenance.
- woah 8y agoThose are some good points, but it looks like the author is mostly just injecting a React-like framework into the root element.
- gedy 8y agoAh thanks, I missed that
- MatthewPhillips 8y agoCriticizing a language that just got wasm support last week for not having mature high level solutions yet is a bit ridiculous.
- gedy 8y agoWasn't exactly my point, it's the criticism of JS the language and the tooling, but then just repeats the same difficult to maintain approach seen in a lot of JS, but now in a new language and even more tooling
- MatthewPhillips 8y agoYou know something has to perform low level DOM operations, right?
- klibertp 8y agoSure, but I was under impression that it's best left to the C++ the browsers are written in?
- ecnahc515 8y agoThe browsers written in C++ are not doing DOM manipulation, they're providing the DOM abstraction itself.
- twic 8y agoUsing innerHTML kind of is leaving the DOM manipulation to the C++ the browsers are written in!
- orange8 8y agoUsing innerHTML is leaving the DOM manipulation to the C++ the browsers are written in. Using createElement is leaving the DOM manipulation to the C++ the browsers are written in. Using HTML is leaving the DOM manipulation to the C++ the browsers are written in. Using your framework (react/angular/etc) is leaving the part of the framework thats using innerHTML/createElement to leave the DOM manipulation to the C++ the browsers are written in. Whichever path you take, the browser must do some DOM manipulation to render anything.. because that is what browsers are built to do.
- cirgue 8y agoThis is what exploring the envelope looks like. New wasm stuff is going to look like hot garbage until new sets of abstractions and new conventions start to shape up. There’s a lot of ground to re-explore and re-cover before wasm starts punching at its weight.
- curun1r 8y agoYou'll see much more mature looking code once Web Assembly Host Bindings [0] land. Until then, using non-JS languages require crossing the WASM-JS boundary to manipulate the DOM. There's a performance penalty to that, so it makes sense that current solutions create a massive HTML blob and send it to JS to inject as innerHTML. That doesn't mean those languages are repeating JavaScript mistakes, it just means that there's still a technical barrier to doing it correctly. [0] https://github.com/WebAssembly/design/issues/1148 https://github.com/WebAssembly/design/issues/1148
- orange8 8y agoAt the end of the day, if you look under the hood of your favorite front-end tech stack, its doing the exact same thing. Everything end up as vanillaJS with ugly DOM manipulations, all your framework does is hide those details for you, so you can work and think on a higher level. So if you're building an application, use those frameworks. But if you're building the framework itself, innerHTML is your friend.