The power JavaScript: 'Gandalf of JS' Wirfs-Brock on ECMAscript 2017 JavaScript has become the interface to the web thanks to browsers, it's leaked onto servers with Node.js, and is now carving out a small niche in Machine Learning – but JavaScript just wouldn’t be without ECMAScript. ECMAScript is the standard language definition on which JavaScript is based and this summer saw an important …
Python, for everyday scripting of everything.
Lua for embedding in C + C++.
Java script is a bad way to drive the DOM and AJAX. Jquery makes it a bit less horrid.Typescript tries to de-fuckup the javascript.
My jaw drops with running JS on the server - Node and all that. Just because the JS JIT runs fast does not mean you should use JS outside of the browser.
Ive never seen a Node setup which could nto be done better, faster and safer than using Elixir/ErlangOTP.
> "Java script is a bad way to drive the DOM and AJAX. Jquery makes it a bit less horrid.Typescript tries to de-fuckup the javascript."
This summer I spent a full month re-learning JS (I'm old). You may not be aware that many of the bad things in JS have been corrected or superseded by updates, particularly ES6. A lot of new/old programming capabilities have appeared too, and transpiling allows anyone to use modern JS without having to manually refactor for old browsers. There's even plans to introduce things like 'await' to the language, if you can believe it. So, over time your objections (tho valid) are becoming less and less relevant.
I'm not saying JS should be in servers because I'm not competent to judge. But Node is, as far as I can tell, not really meant as a server language but as an ecosystem for open source dev tools. For that usage it seems to be more than adequate. Node also has the huge advantage of running in a language known to millions, albeit many with only superficial understanding. It lowers the bar enough that almost anyone can contribute, which has caused an embarrassment of riches regarding tool selection, oy.
Finally, it ain't going away soon, due to browser inertia. That's why so much effort is spent on improving it. I'm betting in a few more years you won't see that much difference between JS and Python.
I’d guess you have never actually given it a good go. Most people who hold this opinion have always held this opinion (or heard it somewhere) and maybe hacked around with it in the past but tried to treat it like their primary language. Once you figure out which parts are “the good parts” and which parts to stay away from it is a really amazing, or at least interesting, expressive language.
Javascript's use case is nearly unique in the IT world. It's almost the only language that has to consider backwards compatibility for many millions of users with older browsers. Those other languages generally don't run in browsers and are mostly free to upgrade quickly.
So when someone suggests javascript isn't as good as the non-browser languages, it's like saying robots are better than people because robots don't have to use the loo.
The buffers are shared ... with itself. If normal memory safe JavaScript buffer are indeed safe, then these shared buffers are no more dangerous.
The only new danger is trouncing your own data, or creating a race condition, which was previously hard to do in single threaded JavaScript.
So basically, you're saying that you need to be some kind of amazing wizard in order to learn Javascript?
"ES2016 formalised that into "promises""
Yeah whatever, more nomenclature buzzword bollocks lingo.
"we added language mechanisms that let a programmer call a function and asynchronously delay or wait for that function to complete"
So its basically threading in disguise. *yawn*
"The other big feature is shared memory."
Wow, cutting edge stuff! In 1980.
"It has evolved into the general-purpose programming language that advocates originally envisioned,"
No, it really hasn't. Its 99.999% client side web with a few deluded webdevs who've been promoted to running servers and only know javascript trying to use it as a server programming language. Meanwhile anyone with a clue uses C/C++, java or python.
You forgot its main use is breaking web sites - "web devs" - you do not need JS to display test, process a link click - your site should do that with JS enabled
And the extra delay in loading in all those huge frameworks just to do a bit of DOM twiddling, and (high) chance of some broken JS taht hogs memory and cripples performance.
There is very little need for lots of web site JS
And with JS enabled always the lottery of seeing what malware randonm ad js is trying to chuck at you.
So its basically threading in disguise.
No, not really.
Premises are Good Old Stuff: Promises.
I really need to check out OCaml a bit more. And for the browser, elm. Now there's a beauty. So much to do, not a minute to spare to dive into the JavaScript fester-dumpster.
Oh well, Java 9 is out, time to go steady.
"No, not really."
Yes really. If a program has more than 1 simultanious execution path its either threads or processes, take your pick. The end result ultimately is the same for the programmer. Sure, "promises" might mean you don't have to fiddle about with mutexes and whatnot but other than that there's no difference. Same wine, different label.
Regarding promises, I think it was supposed to be implemented like the await keyword from C# where the compiler generates a state machine in the background and allows you to program like you are writing synchronous code rather than have to use a bunch of callbacks. Anders Heiljsberg mentioned that awhile ago. I don't know if that is what got into ECMAScript in the end, but, they were talking about it. It is a big improvement over using callbacks IMHO, at least in C#. And asynchronous programming is not the same thing as multithreaded programming. It may use multiple threads or it may basically be cooperative multitasking. One of the points to async is not creating a bunch of threads which consume resources. In JavaScript's case it is at least in part because it never had support for multi-threading. I disagree with your language choices, but, personally, I can't stand JavaScript either. It depends on what kind of app you are developing. Writing a web app in C++ is just stupid if you ask me. Java is a steaming pile. Not interested in dynamic languages like Python.
"Writing a web app in C++ is just stupid if you ask me"
Depends whats going on underneath. The client facing browser side is just the icing on the cake, it gets all the attention but there's usually a whole lot more going on below. If you need some fast DB access and industrial strength data processing then there's nothing wrong with using C++ especially since you don't have the VM overhead and memory hogging of Java or C#.
I'm posting this anonymously as I still work as a web dev and have for over 12 years.
I remember in about 2010 I said to a guy I worked with, could you write an entire web app in JavaScript (we were using PHP at the time for most things). He was the sort of, I'll accept any challenge, type of guy and so he did build something...albeit mainly ajax based (still using PHP for server side processes). He now seems to do almost everything in JavaScript, uses Node.js, configures stuff with JSON and just seems really obsessed with it.
Whilst all of this has been going on, I've ignored JavaScript (other than stuff like jquery). And I still don't know who is right - whether his stuff is now at some genius level, or just the scrawlings of a mad man who's just bodging stuff together.
I think JS is perceived as "cool" especially to a lot of younger developers. And it's started to make its way on to servers with things like Node, so also appeals to wannabe-sysadmin types who have made an alert on a web page before.
For me it just seems inappropriate for about 90% of the things it's used for. Or, there are better ways.
I believe the future is C/C++ in browser natively.
Regardless, 6 months ago I dove in using the latest node.js enabling all beta features and all the latest browsers, I wanted the full effect regardless of compatibility. I used zero libraries in the browser and only 2 core libs for node. Here's a short on what you're missing...
- Node.js
By core dependancies, I mean as in no depedacies on other libraries. Node libraries have HUGE dependcies on other libs if you don't watch out (look up the lib "Express", it's bloooooated). To be honest, node.js isn't bad as a server language once you stop using crazy libs like Express, but the pratice of intentionally crashing without any trusted way of validating input prior to crash becomes stunting.
-Browsers
The hype is justified for I believe that the ease of creating interactive widgets makes it tinkery fun. The real drawback is memory usage. I don't care if it's serial, parallel, interstellar or orgasmic... the memory usage of even a simple waveform analyzer after render is large. It all apparently comes down to the broswers' garbage collection, which more times than not, operates in JiT so memory comsumption just seems to linger regardless of what js methods you use on the graphical objects (drag'n drop is ok, just don't drag and drop graphical collections and expect even decent memory usage).
Interesting that the person promoting C++ for browser apps would be named MyBackDoor. Because that is exactly what you would be getting with C++. Massive security holes. Memory usage-wise you may be right though as far as footprint goes and memory bloat in something like JavaScript. Google had something that was supposed to be native code, but, that had array bounds checking somehow had security built into it. I haven't heard about it for several years. Not sure if they are doing anything with it. Probably they are just on the JavaScript bandwagon now.
"I think JS is perceived as "cool" especially to a lot of younger developers." As it has a very low bar to use on the browser and now on the backend, it is easy to get involved with. Like back last century for me, for enhancing user interactions with lists. (woo)
"... and just seems really obsessed with it." That enabling immediate response to users can be rewarding and addictive for devs should be obvious. I'm surprised you haven't noticed.
"Whilst all of this has been going on, I've ignored JavaScript ..." Um... uh... nevermind.
"For me it just seems inappropriate for about 90% of the things it's used for. Or, there are better ways." Mmm, okay John Henry, don't have a heart attack.
"As it has a very low bar to use on the browser...."
Right there is the problem! jquery users who have no real footwork with memory managemen. Let us generalize that "low bar".
Have you ever noticed how anything graphically intense rendered by the browser isn't running in js? The bar isn't low, it might be as high as it gets in pure js. In fact, js performs so terribly slow as DOM reflow/repaint is a horrible design (no, I sadly don't have a better solution), they had to invent "workers" to make any real interaction even tolerable. So, maybe the bar isn't low or high, maybe it just doesn't exist.
"That enabling immediate response to users..."
Again, a jquery comment. The problem is your just bloating the browers references for what... drop down menus? The heart of interactive js can't be done with jquery (even jquery devs understand that, regardless of the newer native methods). Once you try to do actual interactive designs in js you will understand why strict libraries like ASM.js have arose (and will undoubtedly be replaced by Mozzilla's push).
And it's started to make its way on to servers with things like Node
Until something else comes along to keep the hyperactive scriptlers with learning challenges busy and the managers on "muh scale-out, scale-up asynchronous web-scale" hype-drenaline.
Meanwhile, normal people will do stuff that actually works.
Using threads, for one.
And incidentally the primary vector for client side breaches (regardless of the 'sophisticated' details of what happens after the initial compromise via JavaScript).
It's fundamentally contrary to basic security principles (and common sense) to download masses of untrustable and unverifiable code onto the client and execute it silently and automatically. It's even more fundamentally stupid to use this technique to accomplish things that can be perfectly well, efficiently and safely be performed using good old HTML (e.g. the increasingly common idiocy of using JavaScript instead of link anchors to enable clickable elements for navigation).
Unfortunately this fashion for making even static pages into 'web apps' is essentially born of crashing ignorance. For example, I found today an online shop which declared that in the interest of security "our shopping cart runs entirely on the client, so there's no server to hack". Where do they think the shopping cart code resides at rest? What happens if that repository is contaminated by malicious actors?
Until software development has been raised to at least the minimum standard of a professional engineering discipline we remain at the mercy of fools and ignoramuses. Dunning and Kruger rule!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
