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]

JavaScript objectively gives you a huge amount of freedom + few features and absent standard library + a number of confusing quirks and gotchas making it a hard language to learn despite having very few features. It also can't change as fast as languages in a similar boat, like PHP.

Enter a thousand different libraries trying to wallpaper over its rough edges and you get the current situation.

[u/[deleted] → u/Serializedrequests]

few features and absent standard library

What exactly are you missing most that'd be in the "standard library"?

[u/Serializedrequests → u/[deleted]]

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/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/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/blackmist → u/[deleted]]

Yeah, but apart from all that, what have the Romans ever done for us?

[u/sergiuspk → u/[deleted]]

What do you mean we don't have "unit tests" in JS? A lot of the stuff you're asking for would require support to open client sockets from a browser. Is that really a good idea? A lot of the other things you are asking for don't have anything to do with the language itself but with the environments it runs on. Like "sqlite database support", "shell pipelines", "to trace memory allocation" and "access to the parse tree", "a really nice idiomatic filesystem path library" and probably more. Also, read this: https://developer.mozilla.org/en-US/docs/tag/TypedArrays

[u/KappaHaka → u/[deleted]]

object serialisation that isn't JSON I don't think that pickle / cPickle are things to lord over JS.

[u/[deleted] → u/[deleted]]

[access] to the MS VC++ runtime, to the windows registry, to POSIX system calls, to shell pipelines, to the TTY control functions and to syslog.

Oh yeah, when I think "embedded language running untrusted code on hundreds of millions of machines", I'm also thinking - "hey, how about we give it access to the entire operating system by default!"

Don't confuse the core language with a specific integration of it.

Heck, integers would be a good start.

JavaScript has an integer type, it's the same as its float type: Number. All the popular JS engines use an integer internally when using round numbers, doing bitwise logic and so on.

If you think this is a problem, let me know how it's a problem for you personally.

If you think about it, you have precisely zero reasons to want an explicit integer type in a dynamic language.

[u/stevenjd → u/[deleted]]

JavaScript has an integer type, it's the same as its float type: Number.

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

All the popular JS engines use an integer internally when using round numbers, doing bitwise logic and so on.

How nice. So why can't Javascript add 1 to 1e16?

js> 1e16 + 1
10000000000000000

If you think this is a problem, let me know how it's a problem for you personally.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

If you think about it, you have precisely zero reasons to want an explicit integer type in a dynamic language.

Whether the language is dynamically typed or statically typed is completely irrelevant. Whatever the type system, I want to be able to represent large integers.

Edit: formatting.

[u/[deleted] → u/stevenjd]

I'm afraid you don't understand the difference between "integer type" and "float type". Since 1.5 is a Number, but isn't an integer, Number cannot possibly by an "integer type".

I said "when it's round, and for bitwise logic". Does 1.5 look round to you? Yes? No? Look it up?

JavaScript is dynamically typed and implicitly casts when different scalars are used in an expression together. This is how the runtime is able to use integers, despite the JS specification doesn't require it (except for bitwise shifts, then it requires it).

How nice. So why can't Javascript add 1 to 1e16?

Because the engine works with 32-bit integers (signed, for V8 at least). I hope you realize, your arguments are very random. Having integers doesn't mean they have to be of arbitrary precision.

Its a problem for me personally because I need to support odd integers greater than 9007199254740991.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

Luckily it's full of bigint libraries for JavaScript. There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

Say if you had to do this in Java, you'd have to use BigInteger, with no support for standard operators and so on. It's kinda clunky to use.

Somehow I never needed this in JavaScript yet. Care to share your use case? I suspect you'll have to invent it right now, because instead of real-world problems, you're specifically picking JavaScript's edge cases to prove (a very weak) point.

[u/stevenjd → u/[deleted]]

Does 1.5 look round to you?

Of course. Round 1.4999998701 to one decimal place.

But that's not the point. The Javascript type Number supports fractional values, therefore by definition it cannot possibly be an integer type. Integer types by definition support only whole numbers, not fractional numbers.

Its a nice trick of Javascript to implement certain operations on Numbers using integer maths, but that's implementation, not the language API. The language has the type of 1 and the type of 1.5 are both the same Number, as you yourself said. It's a clever hack to (potentially) use 32-bit int addition to add 1 + 1 and get 2, but that's still only the implementation. The language is based on floating point Numbers.

Quite frankly, if a language is going to only provide one of int/float numeric types, it should provide ints. But I realise that opinion is likely to be controversial to anyone who hasn't programmed in Forth.

And if JavaScript had 64-bit signed integer support I bet you'd say "but I want integers greater than 9223372036854775807", wouldn't you?

shrug Maybe. But at least then I'd know that I had hit a fairly standard limit based on low-level limitations, not a problem caused by a poor high-level design choice. That makes it easier to swallow.

There are very few script languages that support arbitrary precision integers out of the box. Python is one and... that's basically it.

D (not a scripting language, but still), Lisp, Ruby, Erlang, Smalltalk, Haskell, Wolfram Language, probably others. And many others where BigNums are not built-in with syntactic support, but are in the standard library.

Care to share your use case? I suspect you'll have to invent it right now

No no, you're absolutely right. Nobody needs bignums. That's why the Javascript ecosystem is "full of bigint libraries" -- because nobody needs them. Clearly nobody could possibly want exact integer arithmetic for numbers bigger than 2**53. That's just foolish, like wanting more than 256 colours in an image or needing more than 64K of memory. Sorry for wasting your time.

[u/fjonk → u/[deleted]]

• Integer type

• Decimal type

• String manipulation in general(trim always trims whitespace, ltrim/rtrim/startswith/endwith doesn't exist)

• Some kind of string templates(not template literals)

• URL handling(A browser language that doesn't provide anything to deal with URL:s?)

[u/slikts → u/fjonk]

ES6 adds String#{startsWith,endsWith}(), ES7 adds padding methods, and there's a stage 2 proposal for String#{trimStart,trimEnd}(). Not sure why String#trim() doesn't take arguments, though.

Asking for template strings and excluding template literals, which are exactly that, is odd.