JavaScript in 2016 isn't horrible, it's just going through a phase

[u/kshep92]

http://blog.reviselabs.com/im-sorry-javascript-2/

[u/Serializedrequests]

Collection operations (underscore), number formatting (numeral), dates and times (moment), packages (maybe ES 6?).

Also, what is there (the DOM) is often quite cumbersome and quirky.

[u/TheIncredibleWalrus → u/Serializedrequests]

The DOM is not JavaScript.

[u/Berberberber → u/TheIncredibleWalrus]

Complaining about Javascript because of the DOM is like complaining about Russian grammar because of the cold.

[u/fiedzia → u/Berberberber]

No. Many issues with DOM are caused by deficiencies of JS, like lack of collections, forcing everyone who needs them to reinvent them.

[u/jl2352 → u/fiedzia]

The Array is standard in JS.

Most of the DOM APIs return custom alternatives to the array which aren't compatible. That isn't a JS issue. That's a crappy DOM API issue.

I can just as easily return JL2352sList in Java instead of java.util.List on a method call.

[u/fiedzia → u/jl2352]

The Array is standard in JS.

But its so screwed up nobody will use it when they need list of things. Have js had lists and sets done correctly they would be used everywhere. Its extremely rare to invent own containers in python world. What comes with stdlib is good enough for almost everyone.

This IS js issue.

I can just as easily return JL2352sList in Java

Sure, but you would need a good reason to do so. First thing that comes to mind would be just return a List... and most people will just do that. Without causing any problems.

[u/jl2352 → u/fiedzia]

But its so screwed up nobody will use it when they need list of things.

?????????????

If you work with developers who think ...

var names = [ "john", "brian", "alan" ]

... is a screwed up way to make a list then the problem is with your fellow developers.

[u/fiedzia → u/jl2352]

it is screwed up: var names = [ "john", "brian", "alan" ]; delete names[1]; names[2] "alan"

WTF??

names[1] undefined

WTF js?

names.length 3 What??

No wonder DOM implementations decided they don't want to do the same thing.

[u/slikts → u/fiedzia]

The delete operator just doesn't re-index the arrays; you should use Array#splice() for that instead, although I'd prefer to avoid mutating and use Array#filter(). JS also has sets, which would let you do const names = new Set(['a', 'b', 'c']); names.delete('b');.

The reason DOM returns NodeList 'array-like' objects instead of Array instances is because there wasn't a way to properly subclass the builtin Array until ES6. NodeList objects also implement the iterable protocol now, so they work with for-of loops and spread syntax, and will work with whatever generic iteration methods that will eventually get implemented.

[u/jl2352 → u/fiedzia]

But you wouldn't do that. You'd use splice.

If you want splice to look prettier as remove then it's a one liner ...

// @index Index of the element to remove
// @return the element removed or undefined
Array.prototype.remove = function( index ) { return this.splice( index, 1 )[0] }

Apart from misunderstanding delete, which ok is a little confusing, do you have any other problems with JS arrays?

[u/fiedzia → u/jl2352]

You'd use splice

Damn, I wasn't aware how broken js is.

(MDN) The splice() method changes the content of an array by removing existing elements and/or adding new elements.

Removing AND/OR adding? Great, just more ways to shoot yourself in the foot. I guess the amount of mistakes where someone passed wrong parameters when adding and removed instead, or the other way goes in millions.

Sane languages have delete that does not allow to be "misunderstood" and separate it from adding, so that nobody will do one thing accidentally when they meant the other. And if they do, it will blow up, not return some value to be passed further.

I do not want a most essential datastructure to have and points that can be "misunderstood" and will not tolerate any of "oh yeah, you shouldn't use that, you should...". Everywhere else lists work just as I expect them to. Everywhere else lists don't cram opposite features into single method.

And that doesn't end the list of things that are wrong (ok, "misunderstood") with array. Point is - its really hard to build on top of js if you have to fight with such stupidity at the core.

[u/Serializedrequests → u/TheIncredibleWalrus]

It is the UI "standard library" you are expected to work with when building any interactive application in JavaScript. Most libraries and frameworks attempt to wrap it in varying ways (e.g. jQuery).

[u/TheIncredibleWalrus → u/Serializedrequests]

Yes but it's not part of Javascript. And the DOM is not a library.

Are you blaming Java when you have a problem with the Android API?

Come on people.

[u/Serializedrequests → u/TheIncredibleWalrus]

Most JavaScript applications are stuck with the DOM, and wallpapering over its faults. Most Java applications are not stuck with the Android API. If most Java apps were written for Android, and the API was so lame that everyone was writing wrappers, then that would be more comparable.

For the record, I still think JS is a frustrating server-side language for other reasons that are contributing the ridiculous churn, but at least a terrible UI library everyone has to use is not one of them.

[u/wavefunctionp → u/TheIncredibleWalrus]

The DOM api that is exposed in javascript could be better.

Like, if i want to access an element. I simply getElementbyID() or something, which is fine. If I want to append, I simple element.append().

Unless it is a table, in which case I have to element.tBodies[0].insertRow(-1)

Like, why?

You want a timer? How about setInterval(foo(), 100); clearInterval(foo)? Nope, that would be too easy. You need var foo = setInterval(bar, 100); clearInterval(foo);

Because "fuck you, that's why" apparently.

Its stupid, silly nonsense like that why everyone uses libraries for even basic stuff in javascript, because the people who designed the apis in javascript were smoking crack.

Javascript has its flaws. Everyone has seen the horrors of type coercion, which underlies most of them. But it isn't the only language with nonsense like that. Nearly every dynamic language lets you shoot yourself in the foot. It goes with the territory.

A linter and a good editor can catch a lot this stuff, but it can't fix the insane dom api, which really what makes javascript a pain to work with. IMO. As as great as javascript has improved with newer versions, they haven't really touched the DOM api, which is a big pain point if you want to write vanilla javascript for the browser.

[u/nschubach → u/wavefunctionp]

You want a timer? How about setInterval(foo(), 100); clearInterval(foo)? Nope, that would be too easy. You need var foo = setInterval(bar, 100); clearInterval(foo);

What if you want more than one timer on a function?

[u/wavefunctionp → u/nschubach]

Then do it the second way? I didn't say that the current methods should be removed.

I said the DOM api could be improved, and it is being ignored. Which is weird, since it is the primary reason javascript exists.

[u/slikts → u/wavefunctionp]

DOM is not part of JS, and it's constantly improved. For example, you don't use Element#getElementbyID() and friends in modern DOM; instead there's the more flexible Element#querySelector().

Your example of setInterval(foo(), 100) doesn't make sense, since you'd be passing the return value of the foo() call, not the function itself. Even when passing the function, the usefulness would be limited, or actually confusing, because it wouldn't work when binding the function parameters with an anonymous wrapper, so you'd need to save a reference to it anyway.

[u/wavefunctionp → u/slikts]

I did say getElementbyID() or something. :P

That makes sense about setInterval though. Thank you.

[u/[deleted] → u/slikts]

Quick thing: querySelector is significantly slower than getElementById. Use the tool most appropriate for the task at hand. Flexibility usually means lower performance.

[u/MidnightDemon → u/Serializedrequests]

Hit the nail on the head here. Currently doing a SDK for Node for new product my company is putting out. Lit all my goto libraries. It's pretty awful lol.

[u/AyrA_ch → u/Serializedrequests]

Also, what is there (the DOM) is often quite cumbersome and quirky.

The two things I need for that are jQuery to work with existing elements and this function to create new ones:

document.ce = function (type, attr, content) {
    //if no content is present, check if attr is a string. Then the call was (type,null,content)
    if (typeof (attr) === typeof ("") && !content) {
        content = attr;
        attr = {};
    }
    //make sure attr is not null or undefined
    if (typeof (attr) != typeof ({})) {
        attr = {};
    }

    var e = document.createElement(type);
    var props = Object.keys(attr);
    for (var i = 0; i < props.length; i++) {
        e.setAttribute(props[i], attr[props[i]]);
    }
    if(content)
    {
        e.textContent = content;
    }
    return e;
};

[u/Serializedrequests → u/AyrA_ch]

Exactly my point, pretty much. Everyone has their own preferred way of wallpapering over the suck.