extending-the-dom.md/comments

[nbubna]

Add for comments for "What's Wrong With Extending the DOM Now?" here.

I just.. love the way you think and the way HTML.js do ;)
Great works, keep it up!

[jedwards1211]

@nbubna out of curiosity, have you used any of what I'd call second-gen web frameworks like Meteor or Angular or third-generation frameworks like React? If so I'm curious if your viewpoint has changed.

[nbubna]

@jedwards1211 I've used React and read plenty about Meteor and Angular. Thus far Vue is the most compelling 3rd gen framework.

That said, my mind has changed a bit. I still think there is plenty of value in app-specific customizations, but i'm more leery of framework-level changes to the DOM. The reason for that is actually Safari. The devs hurt my work on DOMx (superior sequel to HTML.js), by adding a very framework-like, not DOM-like, totally unspecified method that conflicted with one that i added. It wasn't hard to work around, but it caught me off guard because it wasn't in any specification that i'd been tracking. I'd thought, "hey, browser vendors like standards. As long as i see what's coming, it won't be an issue to choose names that avoid anything standard-like." I was wrong.

I still use and work on DOMx, and i have a fun little hack/plan to secure it against such problems reoccuring. But i've been swamped with legacy maintenance at work and haven't had time for such fun. I still think it is a mistake to use wrappers, and i still think DOM extension has a place in apps. I just don't trust browser vendors to follow/broadcast standards and specifications well enough for libraries or frameworks to get into the DOM extension business without the very greatest of care.

[jedwards1211]

Hmm. Do you have an example of difficulties that using wrappers causes?

Now that I think about it:

• C is a wrapper for assembly language.
• JavaScript, C++ etc. are wrappers for C-like languages (they abstract away our ability to manage memory inconsistently)
• the DOM is a wrapper for probably wickedly complex C++ classes that I assume have tons of optimization of their own at the CPU and GPU level

[nbubna]

Don't confuse a "wrapper" as i use the term in this context with a language abstraction. When i speak of "wrappers" here, i speak only and specifically about JavaScript objects that exist purely to encapsulate DOM objects. jQuery, Zepto, and company all do this. When you use them, you generally do not use the DOM directly, but use an alternate API.

While there can be benefits to an alternate API, they are generally stop gaps, stepping stones toward progress, and they do have downsides in:

• Penetration: the DOM is in literally every browser. jQuery is not.
• Typelessness: the wrapper object exposes every feature and extension regardless of what elements are being wrapped. The DOM is far from typeless, and types are crucial for discovery, debugging, and more.
• Performance: wrappers do take extra memory and extra function calls

I know i've had other complaints in the past too, but these are the big ones.