Hacker News Reader

Comment by gedy | Hacker News Reader

> 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.

View on HN

Criticizing a language that just got wasm support last week for not having mature high level solutions yet is a bit ridiculous.

Wasn'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

You know something has to perform low level DOM operations, right?

Sure, but I was under impression that it's best left to the C++ the browsers are written in?

The browsers written in C++ are not doing DOM manipulation, they're providing the DOM abstraction itself.

Using innerHTML kind of is leaving the DOM manipulation to the C++ the browsers are written in!

Using 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.

This 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.

You'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

Those are some good points, but it looks like the author is mostly just injecting a React-like framework into the root element.

Ah thanks, I missed that

At 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.

Reply on news.ycombinator.com