Popular posts

Regarding tight coupling:

I work with Angular these days so I'll explain in the context of how Angular addresses this issue. To start here is a caution statement straight out of the Angular documentation (see ElementRef):

Relying on direct DOM access creates tight coupling between your application and rendering layers which will make it impossible to separate the two and deploy your application into a web worker.

Angular provides a service named Renderer2 that serves as an abstraction on top of the rendering engine. This enables you to write one renderer for rendering to the browser DOM, another renderer for rendering, say, an Android layout tree, another for server-side rendering, another for web workers, etc. Using dependency injection you can then swap in different renderers without needing to rewrite your application logic. This approach enables you to deploy the same application logic to a web application, a native mobile app, or a desktop app.

Under the hood Angular is not using innerHTML to insert DOM elements (the same for React, Vue, etc.); even Angular warns of the XSS vulnerability with this approach (see here). It is using a parser, but its own specialized parser for parsing its special markup language. That parser will generate an abstract syntax tree that is then used to wire up data bindings and event handlers, and finally to build up a render tree with good old native DOM manipulation. As I mentioned before, this parser can be run offline ahead of time to eliminate the need for parsing at runtime.

Regarding unit testing:

I presume that since you have a disdain for frameworks you are also not separating application logic and presentation by leveraging any sort of MV* pattern or by componentizing your HTML and JavaScript. So let's take the sorted list example from the demo section of your library's site.

Suppose I've made an Angular component of a sortable list.

@Component({
  selector: 'sortable-list',
  template: `
    <ul>
      <li *ngFor="let item of items">{{item}}</li>
    </ul>
  `
})
export class SortableList {
  items = [];

  constructor(items) {
    this.items = items;
  }

  sortAsc() {
    this.items.sort();
  }

  sortDesc() {
    this.items.sort().reverse();
  }
}

To test that the Angular component properly sorts a list, I only have to instantiate a new list component, call its sortAsc() and sortDesc() methods, and test assertions on the items property on the component. Because I've separated application logic and markup and because I can trust the templating engine (as it's been thoroughly tested), there's no need for building up a DOM tree.

describe('SortableList', () => {
  const items = ['A', 'E', 'B', 'D', 'C'];

  describe('sortAsc()', () => {
    it('should sort the list ascendingly', () => {
      // Arrange
      const cmp = new SortableList(items);

      // Act
      cmp.sortAsc();

      // Assert
      expect(cmp.items).toEqual(['A', 'B', 'C', 'D', 'E']);
    });
  });

  describe('sortDesc()', () => {
    it('should sort the list descendingly', () => {
      // Arrange
      const cmp = new SortableList(items);

      // Act
      cmp.sortDesc();

      // Assert
      expect(cmp.items).toEqual(['E', 'D', 'C', 'B', 'A']);
    });
  });
});

Now let's consider the direct DOM approach where the model is stored directly in the view (i.e. as text nodes in an HTML unordered list):

<ul id="sortList">
  <li>A</li>
  <li>E</li>
  <li>B</li>
  <li>D</li>
  <li>C</li>
</ul>

Hopefully you can see that the setup and teardown steps to insert the snippet above into the document are much more involved, as is the logic necessary to prepare for assertions.

describe('SortableList', () => {
  beforeEach(() => {
    /* Here's one place where direct DOM manipulation becomes inconvenient.
     * The setup procedure becomes quite involved, not encapsulated,
     * and difficult to maintain. */
    // I'll leave the actual setup as an exercise for the reader.
  });

  afterEach(() => {
    /* As will teardown as DOM manipulation becomes more involved. */
    document.querySelector('#sortList').remove();
  });

  describe('sortAsc()', () => {
    it('should sort the list ascendingly', () => {
      // Arrange
      const sortList = document.getElementById('sortList');

      // Act
      _.USort.element(sortList, function(a, b) {
        return _.Compare.string(a.data, b.data);
      });
      /* Note that I haven't maintained encapsulation here so my unit test
       * is prone to deviate from the main source. */

      // Assert
      const values = [];
      const listItems = sortList.querySelectorAll('li'); // Sorry but not wasting any more time to "walk the DOM" here
      listItems.forEach((item) => {
        values.push(item.textContent);
      });

      expect(values).toEqual(['A', 'B', 'C', 'D', 'E']);
    });
  });

  describe('sortDesc()', () => {
    it('should sort the list descendingly', () => {
      // And do it all again.
    });
  });
});

I only tested one simple list here. But imagine how complicated the unit test becomes if you have a full page of intermingled application logic and presentation code when you haven't componentized elements.

See to me that's taking something simple -- sorting stuff you already HAVE on the DOM, and throwing endless pointless code at it for Christmas only knows what! It's nonsensical garbage like that which made me reject Angular in the first place... just like all these other garbage frameworks and the convoluted hoops of fire they seem to expect you to jump through for relatively simple tasks.

Much less the derpitude of doubling-down on the memory footprint!

At least, if you're doing this CLIENT SIDE, aka the place where the DOM exists and matters. Server-side tHEN I could MAYBE see what you are saying, but at that point the HTML and DOM should have jack-all to do with the data processing if you maintain separation of concerns. LIVE changes like LIVE sorting ARE the huffing view, that's why you use the view to do it! You're not actually changing the data!

So much of what you've put there reeks of the conceptual/academia double-talk and not actually caring about efficient development. Shoe-horning programming 'paradigms' and models into things in a manner that's more akin to driving a screw with a hammer.

That entire final snippet calling my elementals library making me want to pound my forehead into a wall with the obtuse syntax and pointless gibberish. All that describe and assert bullshit -- just write the huffing code! It is EXACTLY that garbage that makes me think the people who use systems like angular and react don't know enough about HTML, CSS, or JavaScript to be working in any of them! You're just slopping more complexity on top of things for NOTHING!

Oh, and as to having it's own parser -- that's part of the problem. Dicking around with excess string processing to make a 'dom', then to not use it as a dom, to then make it as a dom... yeah, huffing brilliant. Nothing like adding more steps and more processing instead of bothering how to use the client side technologies of HTML, CSS, and JavaScript properly... a situation only made worse by basically writing two to ten times the code necessary AND transmitting same!

It's one giant colossal programming circle-jerk! ALL because programmers either can't be bothered to use HTML properly, or cannot wrap their head around actually using the DOM to do what the DOM does CLIENT side!

Particularly when you have the GIBBERISH of "oh but it uses the dom, but it has a parser server-side" -- then what the F*** is it sending client-side? Marzipan and kittens?

But of course, what usually ends up client side is nothing more than flipping the bird at accessibility. Cute for a full stack crapplet, ZERO huffing use on a website if you actually care about delivering content to as many users as possible.

Dude, are you trolling us? If you need to be stubborn and sanctimonious to get along, that's your perogative. You claimed you were asking for a genuine answer; but I guess you only wanted to broadcast your diatribe.

I think I'll stick with opinions about development practices from the company who has actually written a browser. Feel free to curmudgeonly handicap yourself with your archaic development practices.

And by the way, that "obtuse syntax and pointless gibberish [and] all that describe and assert bullshit" is what you call an automated unit test. It's what professional software engineers use to ensure high quality code free of errors and regressions.