new | show | ask | jobs Github

pyrolistical 2 days ago

I don’t get it. The native js Dom api has a lot of sharp edges but do people hate it that much abstract away from it?

Personally I rather have zero runtime code along side zero build by learning truly native js dom

▲

zdragnar 2 days ago | parent | next [-]

Three reasons spring to mind:

1- the DOM APIs are very verbose, excepting perhaps replacing chunks by setting innerHTML, but

2- manual DOM manipulations aren't composable without also using web components

3- naive manual DOM manipulation can potentially be slow by way of triggering needless layouts/repaints or inefficient use of the APIs

Web components didn't exist when the major frameworks came about, and the ones before them handled composition rather poorly if at all (such as backbone). Angular, ember, react and company all sought to provide a cohesive story for code reuse and composition. Many had their own performance stories, though it was always a secondary concern to everything else.

I've done a bit of everything, including pure vanilla JS, just jQuery, vanilla + web components, all the way up to next, ember, angularjs and angular, and more. If you're building a web site, vanilla JS is fine. If you're building a web "app", you'll pretty quickly appreciate what a framework can bring to the table. If you don't, you'll also quickly find yourself building your own mini framework and runtime to manage things.

	▲	TonyPeakman 2 days ago \| parent [-]
		Well put — that lines up with how I see the ecosystem too. For small sites, vanilla JS is fine; once you move toward “app,” you either reach for a framework or start reinventing bits of one yourself. dagger.js is basically me leaning into that middle ground: accept the verbosity/sharp edges of the DOM, but try to smooth just enough of them with directives (+click, +load, interpolation) so you don’t accidentally start building your own mini framework. It stays runtime-only, works directly with Web Components for composition, and tries not to hide what’s really happening under the hood. So it’s not aiming to replace React/Angular, more to give people a lightweight option before they hit the point where those make sense.

▲

TonyPeakman 2 days ago | parent | prev [-]

That’s totally valid — if you’re comfortable living close to the DOM, zero-runtime + zero-build is the purest path.

dagger.js is meant for folks who want to stay mostly in plain HTML/JS but still smooth out a few of those DOM “sharp edges” — e.g. inline state with +load, simple event handlers with +click, template interpolation. The idea is to reduce boilerplate without hiding what’s really happening underneath.

So it’s less about abstracting away the DOM entirely, and more about lowering the friction for small tools/demos where you don’t want to write a ton of document.createElement calls.