Comment by Buttons840 | Hacker News Reader

Comment by Buttons840 | Hacker News Reader

I see a lot of pent up frustration towards JavaScript and the large companies that control our browsers and the internet (perhaps because I see a lot of myself :).

I wonder if a new browser that doesn't treat JavaScript as a special language will ever succeed? How long until the DOM is usable in languages other than JavaScript? Yesterday I read about someone writing their own browser, which they didn't expect to succeed, but I think a lot of people might jump at the first chance they get to leave big tech companies and JavaScript behind. I lump JavaScript and big tech companies together, but their problems are very different; it would be a breath of fresh air to leave either though.

The W3C says: "As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The Document Object Model can be used with any programming language."[0] How long until this is true in a practical way? Has there ever been a more widely used and important API that is constrained to only one language?

[0]: https://www.w3.org/TR/WD-DOM/introduction.html

I think there are efforts within the WebAssembly GC to expose the DOM API directly to WASM programs.

I don't have much skin in the game, not being a web developer, but something I find intriguing about WASM is the possibility for JS to merely become one of many possible languages to use instead of being the end-all-be-all language of the web. That is, WASM being a successor to JS insofar as being the primary runtime, instead of being dependent on JS.

I would assume this is the direction WASM is trying to go? It sounds so much cleaner, and it does seem the DOM being limited to JS is one of the showstoppers.

>> I would assume this is the direction WASM is trying to go?

Yes, that's it and more. WASM is runtime idependent so it can run on cloud platforms or(in theory) even on bare metal interacting with the host through WASI

JavaScript, JScript, ActionScript

But those are all JS flavors.

There’s definitely the possibility that an SSR system can use the DOM model or something very close to manipulate HTML as a substitute for the many different text-based templating systems.

In that case, designers could work with templates that are pure HTML, loren ipsum and all (as opposed to the always somewhat disorganized mess you get with FreeMarker or Jinja2 that is never quite properly handled by Dreamweaver, IDEs, and such), and the tools would stick content into slots identified by id, CSS selectors and such. (not to mention transformations such as “replace the word ‘red’ in text with <span class=“red”>red</span>]

I have built prototypes that are a few orders of magnitude slower than plain text templating and that’s one reason this has never caught on. It is not terribly hard to do it in either Java or Puthon. If you take it seriously you run headlong into hygienic macro problems although namespace troubles in class names have always been a bugaboo in HTML and CSS that have led to all sorts of bad ideas culminating in “f it let’s just use tailwind”. Really though you ought to be able to transclude any HTML+CSS into another document and bring along the relevant formatting (with the caveat that you do have to consider things like the global availability of space) and not have name collisions.

Reply on news.ycombinator.com