A little bit of plain JavaScript can do a lot

https://reactjs.org/docs/react-without-jsx.html

        // data driven HTMLElement creation                                                                                                                     
        var $element = function(type, p={}) {
                let h, elem = document.createElement(type);

                if (!p || (typeof(p) !== "object")) {
                        elem.innerHTML = p || '';
                        return(elem);
                }

                h = p.attributes; delete p.attributes; if (h) for (let e of Object.entries(h)) { elem.setAttribute(e[0],e[1]) }
                h = p.classList;  delete p.classList;  if (h) for (let c of h) { elem.classList.add(c) }
                h = p.dataset;    delete p.dataset;    if (h) Object.assign(elem.dataset, h);
                h = p.style;      delete p.style;      if (h) Object.assign(elem.style,   h);
                h = p.innerHTML;  delete p.innerHTML;  if (h) elem.innerHTML = h;
                h = p.children;   delete p.children;   if (h) for (let ch of h) { if (ch) elem.appendChild(ch) }
                h = p.parentNode; delete p.parentNode; if (h) h.appendChild(elem);
                h = p.event;      delete p.event;      if (h) for (let e of Object.entries(h)) { elem.addEventListener(e[0],e[1]) }

                return(Object.assign(elem, p));
        };

* getNodesByType - allows me to get things like attributes, text, and comments directly

* getAncestor - allows me to get a specified element somewhere between a target element and the document.documentElement

    function $e(t='div',p={},c=[]){
      let el=document.createElement(t);
      Object.assign(el,p);
      el.append(...c);
      return el;
    }
    
    var $t=document.createTextNode.bind(document);

Interestingly, the function names are exactly the same - I guess people think similarly :-)

https://preactjs.com/guide/v10/getting-started#no-build-tool...

https://redom.js.org/#elements

May I suggest a repo. Github is great, I hear. :)

https://developer.mozilla.org/en-US/docs/Web/API/ParentNode/...

When will we ever get that jQuery’s thing wasn’t only cross-browser compatibility. It’s that the DOM’s native API is terrible and jQuery is a much terser, powerful, chainable alternative.

The valid, useful test is whether or not a good vanilla JS app can be better than a good framework driven app.

None of the max 30-user SPAs I wrote during my time at a certain large pharmaceutical company made sense as SPAs, because the scale at which that becomes beneficial just wasn't there.

As for your other experience: I get where you both are coming from. Thing is, we as front-end developers are kind of forced to use that guy's approach, because over the years stakeholders got used to a level of flexibility that's just not achievable using yours.

I for one would love to use minimal amounts of JS instead of frameworks that make me wait 2 minutes on my sad little work laptop until they compile the project, but that would make any event in which some stakeholder changes their mind a disaster requiring me to re-write the whole application every now and then.

Anyway there's light at the end of this tunnel in the form of compiler-frameworks:

https://svelte.dev/

Writing in this feels just like old school vanilla JS, but with additional language features like reactivity.

Because it doesn't scale for large projects and is impossible to work on with larger teams. Rails may seem bloated to some people, but if you are creating a set of complex business rules that constantly change and cost too much to rewrite with the framework flavor of the day, it makes a lot of sense.

Please tell me you're joking?

There are many approaches you can take. The following is an MVC approach I'm trying out in a personal project. It's organized as follows:

There's a subscribe/emit system, where you can link functions to run when an object sends an emit signal. This can be done in a couple dozen lines of code. Example: https://gist.github.com/stefano/32cbe9bef5a68ecb3286113369d8...

Models are JavaScript objects. They have methods to read their state and to update it. The methods that update the state need to call emit() so all subscribers are notified.

Views are functions. They return an object with 2 properties: a DOM node (the root of the view), and an update function. The update function takes a model instance, and updates the DOM structure accordingly. If a view supports user interaction, it'll take a delegate object as a parameter. The view will add event handlers which call the delegate object. Example of a text input with a label and optional validation error: https://gist.github.com/stefano/2135cc15470cceba4ac2d344fe2e...

The controller is a function or class. It returns an object with its root view and a function to run when the controller is destroyed for cleanup. It can either take a model as a parameter or instantiate it. It also instantiates the root view, passing itself (or another object) as the delegate. In the delegate methods, it calls the model update methods. The controller subscribes the view to model changes, and unsubscribes them when it's destroyed. Alternatively, the view can subscribe/unsubscribe itself.

With this approach, views can be composed by calling the view functions from inside another view, passing down a delegate and adding the root DOM node to the parent view DOM structure.

The controller and the model are completely independent of the DOM. The model can be tested independently. The controller can be tested with a mock view. The view can be tested by passing in a mock model.

Views only depend on their initial state and the state of the model passed to the update function.

Never thought I'd hear the day...

    element.classList.has('someClass') //true if present
    element.classList.add('someClass') //add to element
    element.classList.remove('someClass') //remove from element
    element.classList.toggle('someClass') //remove if present, add if not present

Not saying HN should rewrite their JS obviously, just for anyone reading this and wondering if there are native equivalents.

I was similarly inspired:

    if (undefined === window.$) {
        window.$ = document.querySelectorAll.bind(document);
        [EventTarget.prototype, window, XMLHttpRequest.prototype].forEach(function setOnOff(p) {
            Object.defineProperty(p, "on", {
                get() {
                    return function onElement(t, f) {
                        this.addEventListener(t, f);
                        return this;
                    };
                }
            })
            Object.defineProperty(p, "off", {
                get() {
                    return function offElement(t, f) {
                        this.removeEventListener(t, f);
                        return this;
                    };
                }
            });
        });
        [NodeList.prototype, HTMLCollection.prototype].forEach(function setOnArray(p) {
            Object.setPrototypeOf(p, Array.prototype);
            Object.defineProperty(p, "on", {
                get() {
                    return function onArray(t, f) {
                        this.forEach(function onEach(e) {
                            e.addEventListener(t, f);
                        });
                        return this;
                    };
                }
            });
            Object.defineProperty(p, "off", {
                get() {
                    return function offArray(t, f) {
                        this.forEach(function offEach(e) {
                            e.removeEventListener(t, f);
                        });
                        return this;
                    };
                }
            });
        });
    }

They look useful to me, but I personally think they aren't so well-named; excessively concise for my taste.

https://gist.github.com/nilsandrey/c1f66819de40b26eed4bf71ac...

From the article.

She's written some excellent articles on lower-level programming.

But I agree that VanillaJS is not appreciated by a large number of web developers.

> You can target HTML elements in JS. But how do you know which elements are available?

This assumes someone else is creating the CSS and HTML for you? Have rules or coding and naming conventions like BEM for example. That's what a framework basically is, a set of rules and conventions about how to structure an App. What you need is proper architecture, regardless of whether or not it is based on a popular framework. That's how the popular frameworks started out to begin with.

My current approach for zero dependency/build, one off UI components is:

    <div class="some-component" data-props="{}">
        ...more HTML...
        <button class="some-component__button">Click Me</button>
        <script type=text/javascript">
            (function() {
                var component = document.currentScript.parentNode;
                var props = component.dataset.props;
                var button = component.querySelector('.some-component__button');
                 
                button.addEventListener('click', function(){
                    ...doStuff...
                });
             })();
         </script>
    </div>

I used to have a class based/web components way to do this, but I don't even bother with that anymore. You don't gain anything from introducing complexity in this circumstance.

The question is, who gets to dictate the economics here? The answer is always Thanos, balance.

In a true meritocracy this is a legitimate fight, neither side has a one up. We have to find the pros and cons of the old and new and iterate.

http://vanillajs.net/

https://www.w3.org/WAI/PF/aria/states_and_properties#aria-se...

Or rewrite react yourself as another commenter already did.

It would be nice to have this (via regular or template strings) compile to DOM objects, wrapped with a couple of pointers indicating where strings or elements are placed. I guess for now the best course would be to budge that into transpilation, raising an error if it does anything kooky like work at the boundaries of elements.

(.innerHTML setting is sugar for a HTML parser being initialised on the element, so such a transpiler wouldn’t be removing functionality per se)

[1] https://w3c.github.io/DOM-Parsing/#dom-innerhtml-innerhtml

I had heard that document.write is discouraged but not innerHTML. In fact, browsers have doubled down, by adding insertAdjacentHTML (originally only in Internet Explorer).

> Instead, you were supposed to use the DOM APIs

I tried that in an app. It turned out that IE 6 was faster with innerHTML, like literally 1,000 times faster. This was surprising because I assumed the DOM APIs were closer to the metal. Not so, at least with Internet Explorer. (With Chrome, the DOM APIs and innerHTML were about the same speed).

> standard compliance and future support

It will be supported forever, because browsers refuse to break the web. You can see them saying so when they discuss syntax for new features.

Mozilla's documentation tells you when a feature is deprecated (again, usually for a feature that was experimental and never widespread). It carries no such notice on its page for innerHTML. It does, however, carry a warning: "Warning: If your project is one that will undergo any form of security review, using innerHTML most likely will result in your code being rejected." --- https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

To me, innerHTML is sometimes useful and no more dangerous than server-side rendering. Rather than deprecating it, I wonder why browser vendors have not added a native escapeHTML function (or even better, a very short syntax) to make innerHTML safer.

It's an Arkanoid clone (bat and ball game) written in React, with react-three-fibre for WebGL, zustand for state management, and use-cannon for physics. The full version is about 250 lines and there's also a simplified version that weighs in at 60 lines (not including the library code obviously). It runs at a solid 60FPS on a very basic laptop.

Doing the same thing in vanilla JS, using the same libraries (or alternatives) would be a lot more work, and would end up with the exact same result. That's the point with a well written framework-driven app - when you use something like React or Vue you should be aiming to get the same end result as a vanilla JS app, but with much less effort. The cost to the user should really only be a slightly bigger download.

The browser gives you all that for free, just by writing some HTML. And allows your website to be accessible and indexable. It seems like a lot of work to re-implement that, for little benefit. It doesn't seem worth the hassle, but maybe there's something I've overlooked.

> normal usage of the web application should be quicker, as you’re only fetching the relevant data to fill each of the required widgets...Or did I just describe some already popular JavaScript framework?

Every popular JS framework already does all of this.

Is 64 kb heavy?

There is a graphic libary, that (partly) tries to accomplish this. (but did not really take off)

lib.ivank.net/

Basically the idea was to replace the DOM with a canvas and then create elements in it, like you did in flash.

If it would have matured, you probably could have then used Flex, which is a flash libary, similar to the DOM, but much cleaner. (but flex is heavy, though)

But apparently, no one thought it is worth it. Because, it would mean quite some work, to reimplement the DOM in a faster way ...

Flutter does this for web support.

Yes it can. Qt when compiled to web-assembly does this. It just uses a canvas as a framebuffer basically. [0]

Going off on a tangent here. This is something I've been thinking about a lot lately. I wanted to build a cross platform app that also works in the browser. Especially as single developer maintaining multiple codebases just sucks. So the only real option seems to be to write it as a webapp. So I started, but personally, I just really can't stand the JS ecosystem.

I basically see two ways here this could go. Either the we go the use-canvas-as-framebuffer route. Or we'll need small embeddable html/css engines so you can write your code once in your preferred language, where for native apps you access the engines DOM directly, and when compiled to WASM it 'syscall's it out to JS see e.g. go [1]

Basically something like sciter[2].

[0] https://www.qt.io/web-assembly-example-slate

[1] https://www.godoc.org/syscall/js

[2] https://sciter.com/

1: https://github.com/avajs/ava

2: https://github.com/bcoe/c8

In the same way there's definitely web apps that are better off with a large framework, but if all you're doing is toggling some classes you're better off without them. Most websites don't need to be SPAs.

The tree things you mentioned might be important to you for a specific project, but these are not requirements for every project. So instead, do what makes sense to you. And remember that you don’t always need a framework to achieve what you actually need.