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.

Jason Knight the word is defined as side-effect in this context because you change something outside the function. that's the whole meaning and it's a precisely coined term not about intention.

Javascript is Object oriented hence it uses references for memory optimizations it's logical that they use it. but from a functional perspective it's still a side-effect and side-effect is nothing bad per se it's just something that happens sometimes you want side-effects and sometimes you don't.

Actually gg I just picked the functional approach because you asked for it. I'm not dogmatic, I like programming and I like understanding stuff that's it. I just wanted to explain the reasoning behind that approach and what they wanted to achieve and why the picked the approach.

there is a talk about this from facebook where they explained that after a while the code base got so big they had so many side-effects from so many different modules and libraries that every change did screw up something somewhere else. That's why they were going for the functional idea of "no side-effects".

Tbh. :D I wanted to build the reference based optimizations you implicated where i directly attach an element to the meta-object so I really just change what's needed when it's needed.

I even have several models in mind for that, I usually write libraries and frameworks so I usually have several ideas about implementations,

But I have to work _gg _so I cannot write 5 different solution and go into detail of all behavioural effects of the implementations and intentions. And I just wanted to bring the point across which obviously failed miserably ;D

Yeah, I'm not big on the current hot and trendy (and also poorly named) "functional programming" because it doesn't work how I think, how I learned to program, how I've spent four decades programming... and for me it creates more problems than it solves.

But then I tend to use a few dozen lines of JavaScript on production sites where most people use hundreds, avoiding most of those headaches by again treating JS as an enhancement to already working scripting-free pages, instead of going the "screw users with disabilities" approach of making sites that ONLY work with JS enabled.

One of the reasons a lot of people I know hate and will not use Facebook. JUST like they flat out would not use hashnode or quora or a slew of other sites as the "JavaScript for f*** off" approach to development has them saying "fine, f*** you too!"

Every time I look at these complex JS codebases all I can think is either "I could do this in a tenth the code" or "why the hell are you telling users to sod off?" Again what I've always said about the mental midgetry that is jQuery as what people do with it invariably falls into one of three categories.

1. Something that would be less code without the framework, NOT counting the size of the framework against it.
2. Stuff that's HTML or CSS' job.
3. Stuff that has zero damned business on a website in the first place.

What I've seen people build with systems like React, angular, and vue -- much less what I've cleaned up / eliminated for clients -- generally follows the same design pattern of what I would consider outright ineptitude.

Even as the people making them spout big words that don't mean anything like we're playing a game of bullshit bingo.

Jason Knight

I understand :D but FP is old it got put down for a long time because memory was expensive and other classic religious fights between rivaling approaches of "how to control global state"

OOP took the "we control who change what" aka "messaging (private, protected, friend, public ....) and FP the "we just don't use the global state, everything is a copy" aka no "no global state inside a function" approach.

The lack of "memory / cpu" based thinking based on the "lets push this to the client" attitude as well as the newer compilers with better GCs and Heuristics for branch optimizations as well as the container based hybrid apps for mobile phones pushed a lot of it to. I think you observed this too.

A lot of solutions are just throwing a nuke onto something where a firecracker would've done the job.

I totally agree with you about those things ;D I use no-script as a default and just allow certain pages and scripts to run and it annoys me.

Still I will follow every trend to understand it because it does not matter if I like something, I need to understand it ... that's a requirement to myself. If it's good .... that I don't know ... it's just how I approach information, I need to dissect and understand it.

And yes some devs just use FP without knowing what the core principle of FP architecture- and memory-wise ... they probably don't understand OOP either ... a lot of BS all around.

Anyhow ... I'm rambling ;)

Where you say:

Alleged "designers" and front-end developers basically huddling together to flip the bird at accessibility and in the process screaming "f**k users!" at the top of their lungs.

I don't think it's even intentional. I answer questions almost every day about “how to I make tabs without JavaScript, just CSS?” or “how can I make an accordion but without any JS, just CSS?” and I'm usually the one having to explain why some of these solutions aren't as good as others.

I do also think a lot of people do many times more work than they need to simply because they don't deeply understand the things they're working with. Building websites doesn't have to be nearly as complicated as most people make it.

the simple fact is I don't see how it makes creating projects faster. This is something I've said for ages about jQuery, for ages about HTML/CSS frameworks, and it just continues to get worse and worse year after year!

I think that "making things faster" part comes with the developer not having to reinvent the wheel, web development is getting very hard and a lot of times it is repetitive.

DOM manipulations, state management, App re-rendering, accessing/storing data. All of these are parts of every application these days and a lot of them have been abstracted away.

When the same repetitive keep coming up people find ways to solve these tasks more efficiently. Think about design patterns or some higler level abstraction.

When you abstract something you make it "easier", by hiding internal workings in favor of some API, but with abstractions you have to pay a price, and sometimes it's worth it.

I think that is what is happening with all of these new frameworks is that they abstract the re-rendering/DOM manipulations and state management so that you can focus un building stuff.

After these abstractions have been adopted for a while the entry barrier into web development is somehow lowered because of less knowledge of these internal working. I believe this is where you will see developers struggle with DOM manipulations, and cling to frameworks, but in my opinion they do more good than bad.

Tommy Hodgins wrote:

Building websites doesn't have to be nearly as complicated as most people make it.

THANK YOU! That's basically what I'm really saying... but at the same time the woeful ignorance of the most basic of accessibility norms or even what semantic markup IS or how to leverage selectors is outright terrifying.

Made all the worse by outright mentally enfeebled derpitude like:

<nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
    <a class="navbar-brand" href="#">Site Title</a>
    <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarsExampleDefault" aria-controls="navbarsExampleDefault" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
    </button>

    <div class="collapse navbar-collapse" id="navbarsExampleDefault">
        <ul class="navbar-nav mr-auto">
            <li class="nav-item active">
                <a class="nav-link" href="#">Home <span class="sr-only">(current)</span></a>

Where as I'm always saying if you don't know what's wrong with that, do the world a favor, back the hell away from the keyboard, and go take up something a bit less detail oriented like macramé!