What about static typing!
That is the big one that makes JavaScript horrible to use for non-trivial applications. (With type inference of course.)
ECMAScript 2017, the latest edition of the specification upon which JavaScript is based, plugs a gap left by awkward extinction of some Node.js code last year. In March, 2016, as a result of a naming conflict with instant messaging app Kik, developer Azer Koçulu withdrew more than 250 of his modules from NPM, the service Node. …
So I followed the URL you gave - can't watch video at work, but loved the text:
> I’m genuinely curious as to why programs in dynamic languages are as reliable as they are ...
note that doesn't say _how_ reliable they are, just that it is suprising that dynamic typing is even capable of reaching whatever that level of reliablility.
And continues
> ... although I confess I don’t yet have many of the answers.
How about endless hours of debugging and swearing when you finally spot the typo that static typing would've caught at the first attempt?
Early drafts of ES6 (circa 2012) included proper static types and classes. Brendan Eich was behind it. This fine proposal was trashed by whining web designers on Twitter who still can't code JS to this day.
As for the new padding functions, that ship has sailed. For backward compatibility, wise developers will wait until about 2023 to use them. Or litter their code with more shims.
Javascript could have been great but now it's dead. Move along.
Use TypeScript? I know, I know, it's not the same thing as static typing built into the language. All of the static typing solutions I've looked at for JS aren't very good, but I don't think Javascript's design lends itself to static typing. We'd probably be better off with a new scripting language... and then we get to the problem of people not wanting to change.
This is definitely the biggest debate in Web development right now... glad I'm not the one who has to decided where we're going.
I completely fail to see when you could ever *correctly* use padStart/padEnd.
Basically, these functions apparently simply count length by counting UTF-16 code points. So they don't work correctly if your string contains:
* Non-BMP characters (e.g. emoji)
* Double-width characters (Chinese, Japanese etc.)
* Combining characters (accents etc.)
* Let alone right-to-left languages like Arabic.
On the other hand, if you still believe that "all the world is ASCII" you'll be fine.
The correct way to deal with this would be to style your HTML so that stuff gets left or right-aligned.
That this makes it into a language standard in 2017 is ridiculous.
"I think JavaScript strings are UTF-16 internally. I don't think it could be done any other way."
Agreed. It's unfortunate, but not everything can be of uniform length. It's up to the user to handle edge cases accordingly. For example, if the string is expected to use mainly CJK characters, pad with the Idoegraphic Space (U+3000) which is meant for CJK typography. As for RTL languages, the main thing needed is consistency. As long as you keep the text uniform, just use the appropriate padding function. As for combining characters, Unicode already includes many precomposed characters, so this doesn't crop up as often as you think.
"I think JavaScript strings are UTF-16 internally. I don't think it could be done any other way."
That may be. I have to wonder, what's wrong with just using UTF-8 for everything? C language 'mbcs' functions handle it just fine... [so the JavaScript engine can just call the C libs, right?]
And then there's this article quote:
" the absence of a native method to pad strings makes JavaScript needlessly painful."
padding strings is easy, if you know your data. I do this in 'awk' all the time. You take a 'substring' of a whitespace string [or 'whatever space'] equal to the right column minus the length of the string you want to pad. You might have to test the string first, and take the right 'n' characters of it. OR, you can smash them together (padding plus string), then take the right 'n' characters of THAT result.
Simple. probably faster than calling a library, ESPECIALLY when you consider the BANDWIDTH POLLUTION that all of those "trivial shared java libraries" eat up on the CONSUMPTION side, "for the convenience of the programmer" [read: laziness of the programmer]
The one thing I think SUCKS about Java and Javascript (and similar lingos) is the BASS ACKWARDS MANNER in which you do the right/left/substring/trim thing, typically by turning it into a String object and then calling ".method" [after searching online docs to see what method you have to use, because I don't do this kind of thing every day in Java or JavaScript, but do it a lot in OTHER lingos like C, C++, PHP, awk, or even Python, which deserves its OWN vent-post ]. Pardon my ignorance on the details if Java[Script] tries to fix this, but I've run into this with Android coding and it's irritating.
/"The correct way to deal with this would be to style your HTML so that stuff gets left or right-aligned.
That this makes it into a language standard in 2017 is ridiculous."/
People said the same about print formatting JSON, yet people use it. Prettying things is useful in some languages that don't have default Ui mechanisms such as CSS. So, I agree this pad feature is not needed.
A lot of the problems in Javascript come from the fact that most Javascript scripters (I'm thinking 90%+) have never written anything serious in system languages. I'd say the Javascript section at Stackoverflow is a testament to this. Browse that for 3 minutes and it becomes clear that both form and function are 2nd or 3rd concern. I fear the functional aspects might make things even worse.
The functional side of Javascript is exactly the thing that makes it powerful and perhaps my favourite part of the language, but functional programming is hard to grasp conceptually, hard to learn and - in my opinion at least - harder to write in a way that is easy for other developers to follow.
Most developers see a language that looks a bit java-like and assume they can write java ( or C or C# ) with it, which is understandable, and then desperately try and squidge the language into their expectations. That makes for cumbersome code that eventually gets the job done and is fairly easy to read.
Of course as you say most people using Javascript aren't programmers at all by training and just keep poking at the code and pasting from StackOverflow until it works.
What makes JS painful is reading through code written by people who think Java / PHP / C is the only right way to work.
Learn it _properly_ and its lovely to work with.
And to answer an earlier comment, the time spent chasing that one bug due to _not_ doing type-checking is more than offset by all the time saved from not having to fix bugs due to unnecessary type-check failures.
The issue here isn't with left pad, it is with dependency frameworks like npm that make it all too easy to consume disparate collections of third party libraries in a way that makes this sort of thing inevitable.
Should the language have it built in? Probably, but that is going to be years away before you can safely assume any browser hitting your site supports it. The bigger question is what function disappears next for {reasons=null,noticeDays=0}.
"when MS finally get around to implementing it years after everyone else (as per bloody normal)."
which leaves a few of choices:
a) do the work on the server end instead [bypassing the browser compatibility nonsense] and avoid all of those massive javascript library downloads, and maybe avoid ALL script entirely!
b) deprecate micro-shaft browsers and put "this site best viewed with" again, when Edge/IE is detected
c) one page for IE/Edge, one page for everyone else. "segregate" Micro-shaft (tweeking the SJW's ha ha ha)
I prefer 'a', but 'b' makes for a nice protest
-gate needs to go away; the correct way to accomplish this is to attach it to anything even remotely controversial.
Regarding left-pad, it's pretty trivial to implement, as seen here.
https://stackoverflow.com/questions/13859538/simplest-inline-method-to-left-pad-a-string
function pad(value, length) {
return (value.toString().length < length) ? pad("0"+value, length):value;
}
also seen is this concept, which can be used inline:
("0000" + n).slice(-4)
Developer dependency on copy-pasta node and jquery stuff is a problem that needs to be solved.