'State of JavaScript' Survey Results: Good News for React and TypeScript (sdtimes.com)

"The JavaScript world is richer and messier than ever," reports this year's annual "State of JavaScript" survey, which collected data from over 28,000 developers on everything from favorite frameworks to flavors of JavaScript. SD Times reports: "A few years back, a JavaScript survey would've been a simple matter. Question 1: are you using jQuery? Question 2: any comments? Boom, done!," the developers wrote. "But as we all know, things have changed. The JavaScript ecosystem is richer than ever, and even the most experienced developer can start to hesitate when considering the multitude of options available at every stage"...

On the front end, React remains the dominant framework. However, the survey found interest in Vue is steadily increasing, while Angular is losing steam. Developers are at a 3.8 [on a scale up to 5] when it comes to their overall happiness with front-end tools. On the back end, Express is by far the most popular contender with Koa, Meteor and Hapi slowly making their way behind Express. For testing, Jest and Enzyme stand out with high satisfaction ratings.
In 2016 only 9,000 developers responded for the survey, which had ultimately announced that "Depending on who you ask, right now JavaScript is either turning into a modern, reliable language, or a bloated, overly complex dependency hell. Or maybe both?"

InfoWorld notes that this year more than 28% of the survey's respondent's said they'd used TypeScript, Microsoft's typed superset of JavaScript, and that they'd use it again. And while React was the most popular framework, the second most-popular framework was "none," with 9,493 JavaScript developers saying they didn't use one.

Comments

JavaScript is for people who can't code

[Anonymous Coward]

JavaScript is for people who can't code. It tries to do everything, and does everything very poorly. It's the systemd of web browsers. If the respondents had any clue, they'd vote for JavaScript to be eliminated entirely.

Re: JavaScript is for people who can't code

[Anonymous Coward]

Iâ(TM)m not a fan of JS but itâ(TM)s what weâ(TM)re stuck with until Web Assembly comes along with languages we like. As a result there are many people who program in it because things need to get done.

Re:JavaScript is for people who can't code

[Pseudonym]

JavaScript is for people who don't have a choice. The respondents may feel that they don't have enough power or influence to make the world better, so make do with what they have as best they can.

Re: JavaScript is for people who can't code

[Anonymous Coward]

So what's with all these weird characters and trademarks (TM) in your comment? Are you on drugs or something?

Re: JavaScript is for people who can't code

[cyber-vandal]

The latest version of iOS uses "smart" quotes that an antediluvian website like Slashdot can't handle. You can turn it off in the keyboard settings.

Re: JavaScript is for people who can't code

[Anonymous Coward]

anyway, ios sucks.

Re: JavaScript is for people who can't code

[Anonymous Coward]

Yeah, totally sucks balls (Cartman voice)

Re: JavaScript is for people who can't code

[Anonymous Coward]

sheepely fooled a huge chunk of fools

If the state of javascript isn't "it's dying"

[Snotnose]

The rest of the world as a whole is fucked.

I've said this before. I've been programming some 40 years. Awk, sed, TCL/TK, bash, Z80/8086/68k/MIPS/SH-4/32016 assembler, python, java. Oh yeah, C and C++, which have been my bread and butter for 35 years.

I've liked some languages (z-80 & 68k assembly, C, Python), disliked others (MIPS assembly, C++, TCL/Tk). But there is only one language I actively hate and that is Ecmascript, also know as Javascript. I found it mind boggling that my scripts would run differently on different PCs because "reasons". I spent 6 months coding Javascript and all I remember about it is shit like "oh, you're department sets this flag on install while mine doesn't? Gee, be nice to get a runtime error instead of wrong fucking answers".

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

Meanwhile, you may as well find that âoedisable JavaScript (ecmascript)â option in ur browser. There you go, you have your f*cked world. Right there.

Re:If the state of javascript isn't "it's dying"

[Anonymous Coward]

Well, you'll be happy. Javascript is dying.

Web Assembly has arrived and handily bypasses Javascript entirely. Now every language has a way to target HTML and DOM without having to compile to shitty-ass Javascript. And Javascript will also compile to Web Assembly, making it completely, 100% not special in any way shape or form. It's no longer the gatekeeper to active DOM manipulation. It's dying. Finally.

Re: If the state of javascript isn't "it's dying"

[Snotnose]

Been running scriptblock in my browser for years now, maybe 1 in 10 sites get the 'allow->temp'. The rest it's like "um, yeah, how about no".

So what's your point?

Re:If the state of javascript isn't "it's dying"

[Bite The Pillow]

Examples of these failures?

Re:If the state of javascript isn't "it's dying"

[basic.gongfu]

32 years here; done most of that; and I'll add Lisp, Smalltalk, Forth, Haskell, Erlang, Scala, Clojure, Ruby, Perl, Julia, Pascal, Prolog and more to your list. I've written more ShitScript than I wish to remember and there's nothing in my experience that even comes close to the puke factor of that piece of crap. It's the number one reason I avoid web apps like the plague, even generating it from a sane language on the server makes me sick since I still need to get inside of Brendans head. I wish it wasn't so, I wish it was as decent as the clueless like to pretend; would make my life so much easier. But here we are, building the future on the worst possible foundation while collectively pretending it's leading somewhere worth going; it's like watching a train crash in slow motion.

Re:If the state of javascript isn't "it's dying"

[bugs2squash]

I have to hand it javascript and for that matter to java for reinventing itself as time goes by to include support for new ideas in programming as they come along. Javascript has introduced me to some interesting ideas like closures and functional programming and methods for handling backward compatibility (all with a pretty low barrier to entry). Given that most of the complexity is in handling the DOM or some representation thereof I can't see web assembly magically making most of the things that we (including I) gripe about in javascript go away.

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

The point is the majority of the web dev industry wouldnâ(TM)t exist without JavaScript; it is a massive industry worth billions of dollars. But thatâ(TM)s cool if youâ(TM)re not in on it.

Re:If the state of javascript isn't "it's dying"

[Anonymous Coward]

I have a surprisingly similar background to what you are quoting. And I generally agree with you on my likes and dislikes for languages.

But Javascript is the one language where I would disagree with you. The language itself is a little "different", but not necessarily bad. In fact, for an embedded scripting language, it works really well. Yes, it does have some warts. Type coercion was a bad idea. I understand why it was added to make the language more beginner friendly. But it still is misguided. Fortunately, it is pretty easy to avoid. Semicolon insertion is a little more nefarious, but manageable.

Other than that, the only unusual aspect is the prototype based object model. It's not wrong. It's just different from what most people are familiar with.

It's a compact and well-defined language. Philosophically, it feels like a modern version of C. And it has shown surprising staying power and the ability to adapt to new use cases.

Now, what most people hate about Javascript doesn't actually have anything to do with Javascript. It's the runtime environment and the DOM. Yes, for a long time, that's been a huge mess. But things have gotten much better recently. It still has a lot of complexity, but it has much fewer surprises. And browser differences are slowly fading away. And in cases where that hasn't happened yet, there are libraries that can hide the differences.

If you only remember coding in Javascript some 10 years ago, you'll be pleasantly surprised how much saner things have gotten. On the other hand, it's a big industry, so you now have to learn new frameworks, and that adds it's own set of pain points.

Re:If the state of javascript isn't "it's dying"

[Anonymous Coward]

That is ridiculous. Javascript is a rigorously defined language. As rigorously defined as C++. Standards committee and all.

I run Javascript under node.js and it works the same on Windows, Mac, Linux. From Raspberry Pi to cloud server instances.

Yes, there are issues with JS in different browsers. That is down to the differences in browser APIs and capabilities rather than JS itself.

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

Been running scriptblock in my browser for years now, maybe 1 in 10 sites get the 'allow->temp'.

Cool. Good for you.

The rest it's like "um, yeah, how about no".

Fascinating anecdote.

So what's your point?

It wasn't me who tried to make the point to you, but I'll add one: The real world doesn't care one iota about you or your stance on this at the moment.

I respect your principles, but they don't matter. Keep flailing, though. Eventually you may, maybe, get some traction, but don't hold your breath.

Re:If the state of javascript isn't "it's dying"

[Greyfox]

It all seems like quite a long way to go to avoid writing a GUI application. That's what we're doing there, right? Someone took a look at the state of writing GUI code in the mid '90's, said "Fuck THAT shit!" and came up with Javascript instead. And every attempt to polish THAT turd since then has made it look worse. So now we're at the point I want to write a front end, I have to weigh my choice between trying to write a new GUI toolkit that doesn't suck goat balls and Javascript and a few gallons of turd polish. It seems like a number of really bad decisions have led to this point, and we're not making any better ones lately.

Re:If the state of javascript isn't "it's dying"

[chthon]

Closures and functional programming are as old as the first real programming language, 1959, Lisp.

The main problems with them are not the ideas, but the handling of them through automatic memory management.

Re: If the state of javascript isn't "it's dying"

[gbjbaanb]

The point is that javascript as a language is fucked up, and that if we tried to get rid of it we could replace it with a proper language that had some determinism to it. Something that we could rely on to work without hack after hack after hack, and that might be more optimisable to work at native speeds.

What we have today is just a mess caused by history, and yes, people are using it, but only because we have no choice.

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

Your post indicates a lack of knowlege on your part. First thing to understand is that JavaScript is NOT the same as the DOM and CSS. As a language JavaScript is well designed, sane and versatile. It is in fact one of the most versatile and consistent languages I know - and I know them all from experience, C, C++, Perl, PHP, Ruby, Python, Java, C#, Visual Basic, and a few more. Of all languages PHP is certainly the very worst.

Re:If the state of javascript isn't "it's dying"

[Anonymous Coward]

So what do you do for web pages? CGI and JSPs? Not that there's anything wrong with those two, just curious.

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

No what we need is to flip it around. Running scripts that modifies a document while being embedded in said document is just begging for problems.
If we need a web-language it should be the top level.
As for the graphical environment html isn't really suitable for the way page layout have been made the last 20 years.
It is so bad that we had to invent another language (css) as a patch on top of it.

What we need is a graphic layout format that is better than html and doesn't require css. Ideally it should not support embedded scripting and dynamic pages should be made by invoking the language at top level and let it generate the output.

Re:If the state of javascript isn't "it's dying"

[Anonymous Coward]

There are a few valid excuses for running Javascript in a browser context. But there is NO excuse to run Javascript natively on the system or in a server context (node.js). We have a lot of better programming languages for those applications.

Re:If the state of javascript isn't "it's dying"

[Junta]

It was less about programming GUI applications and more about distributing and installing gui applications. Over time, the security model also became a key factor as well.

The world might have been a very different place if microsoft *ever* cared about having decent package management. As it stands, getting an executable running under an arbitrary user's desktop is an exercise in excessive bundling of third party dependencies (because you can't ask the OS to resolve it for you), install wizards that make a big deal over the most trivial of app install, and as security evolved, the joy of code signing, anti-virus that assumes all new software is suspicuous, and so on.

Of course on the security front, all the desktop platforms are still in the general permissions model of the 80s: all user content is roughly equivalent. The mobile platforms have made some good permission decisions, like apps not being able to access files from other apps by default and such. On the desktop however, security policies have been implemented in hamfisted ways that make it far easier to make a web app and roll with the security model in the browsers, which seem to make all the anti-virus vendors happy.

Re: If the state of javascript isn't "it's dying"

[Junta]

While DOM manipulation is a bit verbose, and CSS can be weird, Javascript as a general language is not exactly consistent, at least not the way I think of consistent.

One is how it tries to cater to the 'object oriented programming' pattern. Javascript is heavily tilted toward closures, but a lot of programmers struggle with that. Now I think there are at least three general ways of trying to make things easier for OO, and they are all still really hard for people to grasp coming from C++/Java/Python where OO is more well defined into the language syntax. This is similar to Perl's OO, which looks more like they accidentally found a syntax that acts OO as did that instead of doing design around the language.

Another is it plays fast and loose with variable values. In a complex javascript applciation, a bad variable value has a stronger tendency to bounce around incorrect until it finally blows up and it becomes an effort to trace things back to where things went wrong earlier. This is another thing that I'd say is very Perl like, compared to other languages that are more forceful about making sure the programmer *really* meant it. There are always some sorts of problems possible, but the forgiving nature of these languages increase the occurrence. Even with 'use strict' (incidentally, same in javascript and perl...) this is the case.

The final situation is where it tries to be forgiving with quoted strings or omitting the quotes. For example, if you have "var a = "key"":
both:
b = {a: 1}
b = {"a": 1}

produce the same object, with string "a" as the key, rather than the unquoted value being used as a variable name. Javascript is chock full of little forgiving things that tend to help simple code work without being anal to the programmer, but explode as you get to larger complex code.

Re:If the state of javascript isn't "it's dying"

[Junta]

This is of course what makes javascript more controversial than other languages. If I don't like, say, python, I can write in another language. It's easier to adopt a "live and let live" philosophy.

Inside the browser however, there has been little choice. There are roughly three:
-Static site. Note that with CSS alone, a lot can be done to enhance the apparent responsiveness of a site, and it will also be a lot faster and less resource hungry than doing the same things in javascript.
-Loading whole pages from a backend instead of the data. this makes for more bandwidth, slower rendering, and general non-dynamic feeling
-WebAssembly - Not yet mature, excludes a lot of older browsers, and for the occasion you want an arbitrary third party to be able to trace your site's code, it's not the most friendly thing, but then again, angular, 'minifiers', and so on already ruin java script for that use case.

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

C++ is NOT a first-class object language.

It is merely data structures containing pointers and magical name mangling. In fact, everything that can be done in C++ can be done in C. C++ is nothing more than a pre-mangler for a standard C compiler.

C++ is akin to Microsoft-style objects. They are not objects. They are merely STRUCTs containing pointers to functions and there is no such thing as real "inheritance" since there are no actual objects ...

Re: If the state of javascript isn't "it's dying"

[Anonymous Coward]

> In fact, everything that can be done in C++ can be done in C.

False.

> C++ is nothing more than a pre-mangler for a standard C compiler.

False. When did you study C++, 1988?

> C++ is akin to Microsoft-style objects. They are not objects. They are merely STRUCTs containing pointers
> to functions and there is no such thing as real "inheritance" since there are no actual objects ...

Uh-oh, sounds like someone drank the OOP Kool-Aid.

Tell me, how do you think objects are implemented in your magical pure OOP language?

Re:If the state of javascript isn't "it's dying"

[Anonymous Coward]

You're a hack.

Close to unemployable. MIPS assembly and TCL/tk, and you are complaining about ECMAscript 6?

lol

Re:If the state of javascript isn't "it's dying"

[Tablizer]

I found it mind boggling that my [JS] scripts would run differently on different PCs because "reasons".

It's probably not the fault of the language, but of DOM and browser differences. One has to target too many variations and mutations of clients, which is insane.

In my opinion browsers need to complete rework. The client should be a dumb loyal vector plotter and let the server manage layout and formatting decisions. That way you are dealing with ONE layout engine and version instead of 200.

Putting more of the UI complexity on the server would also mean less need for client-side scripting.

Some confuse this for returning to WYSIWYG UI's. But it's only WYSIWYG from the client's side: the server can have any layout engine you want.

How about stability?

[MobyDisk]

Look at the options for the "per-library survey results":

[ ] I've never heard of it
[ ] I've HEARD of it, and am NOT interested
[ ] I've HEARD of it, and WOULD like to learn it
[ ] I've USED it before, and would NOT use it again
[ ] I've USED it before, and WOULD use it again

Notice there's no option for "I've actually deployed it to a production platform and it has been running stably for a year." I can attest that every interview candidate tells me they've used Angular 2/4/5 before, because they went through the tutorial. So be careful when using these results.

I am on a project that started with Angular 1, then took a significant delay to move it to Angular 2, even when it was in beta, because we thought it was more stable and it was the future. Now, it's #5 in the "Ive USED it before and WOULD use it again" category. Our latest front-end developer is threatening a coup unless we move to Angular 5 (which is actually quite easy, but still - WTH?) There's just no winning here! We can't develop stable software if the platforms lifetime is shorter than the time it takes to get a product to market!

Re:How about stability?

[bill_mcgonigle]

Fire any developer who says, "this shit I recommended is a year old - we need to switch frameworks to do anything."

They are *very* common and I doubt you'll find any with a CSE degree.

Re:How about stability?

[phantomfive]

We can't develop stable software if the platforms lifetime is shorter than the time it takes to get a product to market!

This is extremely frustrating.

GUI frameworks are an old, well-studied area of programming. If you do a little research, know the history (obviously people aren't doing that, Alan Kay calls it "Pop culture programming"), you can get a good framework from the beginning. There is no reason to have breaking changes more often than blue moons.

Re:How about stability?

[Anonymous Coward]

you should see angular 5 as angular 2.5 or so, it's just angular v2 with lots of improvements. We have been developing with angular 2-5, easily just updating the packages when a new angular version comes out, in 1 big project, and by every new version, I see the javascript bundles shrinking in size.

I would love to do a reactjs project in the future, just for seeing the different ideas and if it's easier in the long run. Unfortunately the internet is full of I did the tutorial and angular sucks stories. As I see it, a few things that makes angular more difficult are modules, which reactjs doesn't have. Further reactjs is only the View part of angular, which has a lot more stuff, that you need to add yourself, also increasing the learning curve.

I liked programming in angular, (the template syntax is actually fine), it also forced me to use typescript (extra learning curve, be it a small one). But by the same designer of C# / Delphi, making it a joy to work with.

Re:How about stability?

[Junta]

There are a few reasons why I avoid using Javascript frameworks:

-They can trip themselves up over time. A framework falling out of favor means it actually starts to not work well with newer browsers.
-They royally screw up the browser developer tools ability to debug code
-They aren't really that necessary if you don't mind requiring users to have a browser that's at least newer than a couple years old, which is a really good idea given security fixes anyway. I remain dissatisfied with Javascript, but the frameworks don't really do anything to mend the frustrations I have, and the core language gives me about as good syntax as the frameworks now.
-They bloat the page download

Re:How about stability?

[Joopsy]

I have to say, I find the pace of change in JS frameworks utterly ridiculous.

How are you supposed to build long lived systems? Ideally to have a code base with a long life span, you need the tools to remain relatively stable (and to keep the talent pool as deep as possible - no point build a system if you can't tempt devs to work on it in a couple of years).

I actually logged in for the first time in ages just to post how much I utterly agree with you.
 

Re:How about stability?

[brantondaveperson]

GUI frameworks are an old, well-studied area of programming

At yet, mostly, they still are all awful.

Re:How about stability?

[Anonymous Coward]

>> GUI frameworks are an old, well-studied area of programming

> At yet, mostly, they still are all awful.

Serious question: what would a good one look like?

Re:How about stability?

[terjeber]

How are you supposed to build long lived systems

By using a proper build system. Easy.

We have a larger project that has evolved a lot over time. It has aspects that are written in Javascript+JQuery only, other pieces are using Knockout. We moved quite a bit of our stuff to AngularJS a good while back, but paused to move it all to Angular in the beta phase of Angular 2 as it was called at the time. Moving from AngularJS to Angular 2 took a bit of work, but moving from 2 to 5 has not really required any code update on our part. Changing the HTTP client in v5 took about 1 hour, and was trivial.

The current animosity towards JS frameworks appears to me to be based mostly on ignorance.

You Don't Know JavaScript...

[Anonymous Coward]

You can't call yourself a JavaScript programmer until you've read "You Don't Know JS" by Kyle SImpson. Most JavaScript programmers know enough to get a JavaScript framework working but not enough to figure out how to solve a problem.

Re:You Don't Know JavaScript...

[Anonymous Coward]

That's backwards -- competent programmers understand javascript fine, it is the "idiot-savant" of programming languages. Most framework goons would be lost in any programming language.

For the record I like javascript as a language and also browse the web with it disabled.

Well if they had asked me ...

[AlanObject]

TypeScript seems to fix nearly everything I had a problem with regarding Javascript. And if you are using Angular and follow 90%+ of the instructional material out there you are using TypeScript. I had spent years avoiding Javascript and learned what I needed but without much enthusiasm.

The funny thing is that I don't really need strong type checking for designing my app. My IDE (WebStorm) needs strong type checking in order to be more helpful to me. Without TypeScript it is forced to make a lot of hellacious guesses (mostly wrong) about code completion. With the current version it is almost as solid as if I were programming Java.

The cherry on top is that I can still be as careless and sloppy as I want the way Javascript alone allows. Occasionally that is actually helpful. So all win for me.

Re:Well if they had asked me ...

[tepples]

TypeScript seems to fix nearly everything I had a problem with regarding Javascript.

Does it fix the problem that it has become unacceptably common for programs written in the language and running in web pages to automatically download unnecessarily large amounts of data over a possibly metered connection, automatically spy on private information the user inadvertently enters before submitting,* and automatically track the user's viewing habits from one domain to another?

* This happens when someone copies private information and later, after forgetting what he had copied, pastes it into a text input or textarea in an HTML document. I'll concede that the clipboard UI is poorly designed in that it makes this forgetting too easy.

Re:Well if they had asked me ...

[AlanObject]

Does it fix the problem that it has become unacceptably common for programs written in the language ...

Isn't this a complaint about the runtime environment and not the language itself? What about this would change if, for example, the browser language was Python or Java?

Re:Well if they had asked me ...

[modmans2ndcoming]

That is pretty derp. The world is moving to PWAs so your dislike of the modern web is unfortunately dated. Non-incumbent desktop apps (Office, Photoshot, etc) are dead.

Re:Well if they had asked me ...

[jez9999]

TypeScript seems to fix nearly everything I had a problem with regarding Javascript

Runtime type checking. Unfortunately it all falls apart and requires you to do everything manually when you care about runtime data (reading in a JSON file, getting in data from the network, etc.) I really wish they had included runtime type checking as a goal of TS but alas they didn't.

encouraging

[Anonymous Coward]

And while React was the most popular framework, the second most-popular framework was "none," with 9,493 JavaScript developers saying they didn't use one.

This is encouraging, even if it is only a third. React functionality was being standardized in browsers naively at the same time that React was being developed. Hopefully eventually people will realize that.

And will people stop needlessly using ES6 Promises? The Promise pattern was always possible without a built-in object type and the built-in sucks major ass, and only browsers from the last 2 years support it (therefore 80% of the net doesn't) and yet all of these stupid banking websites are starting to require it just to log in (thanks to retarded React usually)

Re:encouraging

[Anonymous Coward]

*natively

Re:encouraging

[AvitarX]

Are you saying 80% of the net is using browsers over two years old?

Re:encouraging

[maztuhblastah]

Promises do have applications in all sorts of async tasks though.

[ begin_rant ]

I agree they're over-used, but it's hardly the end of the world. Even the polyfill versions of them are performant enough that you're unlikely to hit their limits. And if you are, it's a good sign that you're abusing them!

Personally, I think a much bigger problem is the clusterfuck way in which stuff gets standardized into JS (now ES). From Promises (yes, I sort of agree with you!) to the insane drag-and-drop API, it seems like the JS world tends to simply pick whichever implementation "got there first" and standardize on that, with nary a consideration for whether the resulting API is sane to use. I mean, when IE 5.x is your reference impl, you just *know* that something is up... That's how you end up with "oh, none of this works until you return false to this handler" and shit like that. And why you have both 'dragover' and 'dragenter'. I guess because the Outlook web team didn't want to maintain event counters?

One of the best programmers I know -- responsible for some *seriously* widespread libraries that pretty much swept the games industry -- always says: "try to write the calling/usage code before you write your library. Because if you as a future caller can't use the API you had in mind, it's crap."

And I tend to agree with him. There's a lot of stuff where that falls over, and I can only imagine it was because the spec/lib authors didn't really think through a real-world use-case for the stuff that they were turning out. If they did, they'd probably have made some changes. (Even Sun, who did a great job with some stuff like the Collections API, has plenty of these architectural brain-farts, particularly surrounding authentication and authorization. They built something super complex and flexible that nobody in their right mind can actually use, so everybody uses a third party lib or two which offer a simple, sane API.)

React actually isn't too bad, particularly compared to Angular or similar! As a functional programming fanboy, I dig the "data drives UI changes" model and the one-way data flow. But "native" DnD, file upload? It's pretty clear that nobody thought through how it is to be on the receiving end of those APIs before ship time. Is it doable? Sure. I've written plenty of code that deals with the "raw" DnD API. But it's damn sure not easy or pleasant! It's hack city because too much was left up to the browsers, and across three browsers you got four opinions on what events should look like. Not to mention the flat-out bugs that nobody cares about fixing because, fuck it, handling backwards compat. is hard! Yeah, you can do it (or use a lib if your use case fits it -- ours didn't), but for something that should be simple and should be a total non-issue, god*damn* did they make it complex.

The interesting thing about JS is that new additions are rarely straight-up terrible. They're usually just sort of "death of a thousand papercuts" bad. No one standout, but a bunch of really annoying bits that make the whole experience an exercise in pain compared to, say, writing for Cocoa or even .NET. I mean... I'll still do it, 'cause I need a paycheck. But for stuff on my own, I tend to shy away from painful APIs... and I imagine that sort of casual dev loss times however many opinionated programmers there are out there is a significantly non-zero number. Maybe not enough to get the ES spec authors to care, but it's still not something that they should take lightly. That's the thing about us old grumpy bastards... we're starting to move into "influencer" positions where we can shoo our junior members away from tech that we know is labour-intensive...

On the other hand, ESWhatever got just about everything right with lambdas, so it's very much a mixed bag. Not quite right on the JIT optimizations (at least on FF), but I'm sure they'll sort that out soon enough!

So yeah, go lambdas. React? Eh, getting there. Drag model? Fuck that noise.

Re:encouraging

[Junta]

I don't mind requiring newer browsers (a browser that old is likely to have security problems).

But on Promises, what annoys me is that they were heralded as the solution to callback hell, but it's still really hellish and tedious. I don't see a lot of benefit of promises over the previous best case, and they all suck.

Re: encouraging

[spongman]

See typescript's a sync/await

Re: encouraging

[spongman]

What's wrong with promises? Polyfills exist for older browsers. They're just a standardization of API callback mechanism, which has the added benefit of making them composable.

Would you prefer every library have its own way of handling asynchronous callbacks, errors, state and cancellation? And in that case, are you ok with having to write error-prone, ad-hoc code for using multiple such libraries together.

No. Promises make doing this trivial. Especially with typescript's async/await.

Re: encouraging

[spongman]

The 'drag drop API' has NOTHING to do with JavaScript.

In a near future, all 64-bit.

[Anonymous Coward]

Running JavaScript on a grid of x86-64 & RISC-V machines maybe an Internet explosion as the movie Matrix.

Amen!

[Anonymous Coward]

The same issue is true with python, ruby, to a certain degree with C++ today (linux C++ ABI is totally fucked if you compile with the wrong compiler. And since it doesn't offer any sort of ELF metadata so the compiler will throw an error 'this library compiled with ABI xx while other libraries and/or compiler expect ABI yy' leads to all sorts of compilation issues (and occasionally runtime issues due to structure/mangling changes!) if your whole system isn't compiled against the same standard AND THE SAME COMPILER VERSION.

I believe this is slightly less common on the Microsoft side due to differing vcrun versions for each revision of the compiler toolchain, but even there you occasionally run into it with 3rd party compiled libraries when needing to merge older and newer versions of code.

Given that even C is hopping on this bandwagon now with the C17 changes, having not had any major stdlib or ABI changes since the 90s previously, I really worry as to the future of software design, and more importantly, the ability to recompile old code without wondering about what it had formerly been expected to do.

Unjust downmoderation = censorship... apk

[Anonymous Coward]

See subject: It can't affect me - I override it, reposting when it's unable to prove me validly wrong (& it never does) but it affects "your kind" (unidentifiable anonymous trolls) by ME running you DRY of your 'downmodpoints', easily.

I only post on my program when & where hosts help vs. the issue @ hand (or when trolls like you bring it up - especially since "your kind" hasn't done BETTER than I, lol).

* As to the rest of your bs? Please - I have no standing on 'bump stocks' @ all, & I don't talk Vatican conspiracies either - so You now vainly "trying to put words in my mouth I never said" you're doing? Is stupid & weak (like you).

APK

P.S.=> Grow up... apk

Re: Unjust downmoderation = censorship... apk

[Anonymous Coward]

and where is this apk thing... o want to give it a try.

"none" is the right answer..

[Anonymous Coward]

otherwise you're just spending your time chasing down the "flavor of the month" and constantly porting your shit from one to the next.

find what works, what works for you, and stick with it. you'll be far more productive than you would if you keep wasting time building on buzzwords and fads.

Javascript costs YOU the user (in many ways)

[Anonymous Coward]

See subject: Running clientside script defeats logic of a client-server model (you run the script clientside raising powerbills). CGIBin/WinCGI does the same serverside (ISAPI/NSAPI libs/dlls too) NOT RAISING YOUR CLIENTSIDE POWERBILL (or sucking up YOUR cpu cycles, RAM & other forms of I/O in doing so).

Clientserver was ALL ABOUT THAT (making it better for you as the client, the important consumer of information).

* Javascript's also rampantly abused to deliver malicious code (or tracking of you) to you (I don't need to note that I am sure but I am for "posterities' sake").

APK

P.S.=> I block 3rd party scripts via hosts files (which work long before browser addons "script src" tag parsing do & more efficiently by outright blocking their source, no need to parse) via APK Hosts File Engine 10++ 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ ..,. apk

I think that JS just compromised my Firefox

[Anonymous Coward]

I don't know what the fuck is happening, but I now have a strange "Looking Glass" extension that unexpectedly showed up in my Firefox recently. I don't know what the fuck it is and I don't know how it got there, because I sure as hell did not install it.

I'm no expert on this stuff but I think that some malicious JavaScript might have compromised my Firefox to install this plugin that may be malicious.

I don't know what to do at this point. I've done the obvious thing and completely uninstalled Firefox, as it appears to have been compromised. I'll likely never be using it again. Since I don't know how far this contamination has spread, I have to assume that my entire Linux installation is affected. So I'm going to be wiping my drive and reinstalling from scratch today.

I really don't know what to think any more. I had always heard that Firefox was a secure browser, but now this extension just appeared out of nowhere, and now I'm stuck reinstalling my entire Linux installation just to be safe! This is one of the worst computing experiences I've had in a very long time.

I wish that JavaScript would just go away if it can contribute to my browser being violated like this.

Re:I think that JS just compromised my Firefox

[Bite The Pillow]

Firefox should do a better job asking if you intended to install that. But it isn't an example like I asked for.

Re:I think that JS just compromised my Firefox

[Anonymous Coward]

Firefox extensions are written in JavaScript. If code written in JavaScript can be used to unexpectedly infect a Firefox installation, then it's a huge failure of Firefox and it's a huge failure of JavaScript. It's exactly the kind of example you asked for.

Re:I think that JS just compromised my Firefox

[Anonymous Coward]

The code Mozilla added to Firefox for Looking Glass could have been written in any language. That has absolutely nothing to do with Javascript being bad.

NoScript

[evanh]

for the win. :)

examples please

[Anonymous Coward]

Examples of scripts that "run differently on different PCs"? Even just some links?

I've only coded c, c++, perl, php and fortran besides javascript so maybe I'm just a ignant tourist. I like c, perl and fortran. Despise php and just never got the hang of c++. After a bunch of years of php for $ node is very relaxing. Maybe you greyer beards can spin up quick web crud in an afternoon in c but I can't. On the front end react is a waste of time, angular is web dev for Kafka fans and jQuery works for quick and then write it out if needed.

No such thing as a JavaScript Framework

[sproketboy]

There's no such thing as a JavaScript Framework since any function can be clobbered by a string or int or anything and there's no way to enforce parameter types. Kill JavaScript and we should use web assembly and write in real languages.

Re:No such thing as a JavaScript Framework

[Bite The Pillow]

Meanwhile I have a requirement and JavaScript helps me meet that and it is easily debuggable. Proprietary stuff goes server side of course.

Only an idiot would clobber, that's a sign you don't know what you're doing and likely learned from how to searches. So you look for a framework to help you instead of understand it.

That's okay, just know it ain't everyone's thing.

Re:No such thing as a JavaScript Framework

[sproketboy]

I didn't say I did that. It's the fact that the language has no type safety whatsoever. Reading comprehension isn't your strong suit I guess.

Re:No such thing as a JavaScript Framework

[Junta]

I do not relish the thought of sites going to web assembly. Already BS like Angular and other frameworks and minification makes it challenging to trace third party code, don't want it to get any worse, but maybe it is a lost casue...

On the general argument of type safety (an other related sensibilites), it totally made sense in the beginning when javascript was only used for lightweight page manipulation, and being unforgiving and requiring tedium of the programmer just wasn't worth it. The problem is of course that people are writing massive javascript applications, and that stuff really complicates quality as code complexity grows.

Re: No such thing as a JavaScript Framework

[spongman]

Typescript does exactly that, and more.

Re:No such thing as a JavaScript Framework

[Anonymous Coward]

Just run NoWebAssembly in your browser.

If not in browser, why JS in first place?

[tepples]

Isn't this a complaint about the runtime environment and not the language itself?

Yes. But who in their right mind would choose JavaScript if it weren't for the runtime environment? True, Node is faster as a server-side JavaScript implementation than CPython is as a server-side Python implementation, but it only got that way by sharing the V8 runtime with Google Chrome. How common is it in practice to use Node other than as a server for dynamic websites that also use JavaScript in the browser?

Re:If not in browser, why JS in first place?

[ljw1004]

How common is it in practice to use Node other than as a server for dynamic websites that also use JavaScript in the browser?

Other common uses of Node -- to host standalone desktop applications that are implemented in Javascript -- VSCode editor, Atom editor, Slack, Visual Studio Installer. I'm sure there are loads of other standalone desktop apps that run on Node, but these are the ones I'm aware of.

(Come to think of it -- of the applications open on my mac on a day-to-day basis, the only ones not running on Node are Terminal and Outlook).

Re:If not in browser, why JS in first place?

[Anonymous Coward]

Standalone desktop applications have no business being written in Javascript. One of the reasons is that you get the possibility of XSS exploits.

Examples see here: https://statuscode.ch/2017/11/from-markdown-to-rce-in-atom/

I made a new one

[Anonymous Coward]

It's called WhomScript

You just convert Javascript English to any encrypted language of your choice, then you reconvert it back to Javascript then you make a C program that does less than 20 type enumerations and 1000 functions to loops then runs in a simple C built environment that executes that as a basic C construct modeled as simple as any procedural language can be.

Then, we release it for free and wonder why we built anything other than a runtime C interpreter with a few generous libraries...

Also, we made sure to type it out on both dvorak and qwerty keyboards.

JS is dead. WebAssembly killed it.

[Anonymous Coward]

It just doesn't know it yet.

But nobody in their right mind will use JS, when they can use whatever is their favorite language, and compile it to WebAssembly.
You can even use the same code for a program, an app and a web application. (See: The Godot game engine.)

And I'm saying that as somebody who doesn't hate JS (because I understand it and its intentions and what it should have become).

Electron wastes RAM in my experience

[tepples]

Other common uses of Node -- to host standalone desktop applications that are implemented in Javascript

Which leads to the Slack O(n) RAM problem: "Why am I wasting 365 MB of RAM and tens of MB of SSD space on Discord or Slack when it could use half that much RAM by sharing it with my other Firefox tabs?"

of the applications open on my mac on a day-to-day basis, the only ones not running on Node are Terminal and Outlook

And how much RAM does each use, especially on a Mac where end-user RAM upgrades are difficult or impossible to install?

How will non-technical users self-host PWAs?

[tepples]

The world is moving to PWAs

APIs used by Progressive Web Apps require HTTPS. Say a home user downloads a copy of a PWA to run on a web server on his home LAN, be it an otherwise unused desktop PC or a Raspberry Pi SBC. Will he have to buy his own domain in order to qualify for a certificate from Let's Encrypt?

PWAs also require the ability to listen for and accept connections from users' browsers. But in the era of IPv4 scarcity, a lot of home broadband Internet access plans don't allow incoming connections on (say) port 443, such as if the ISP uses carrier-grade network address translation (CGNAT) to put hundreds of subscribers on one public IPv4 address. If a home user downloads a copy of a PWA to run on a server on his home LAN, how will he be able to access it from his phone thorugh a second cellular ISP or his tablet through restaurant Wi-Fi. Or should users also lease hosting for their PWAs from Amazon or another VPS provider?

And if you're recommending use of PWAs hosted exclusively on the server of a publisher who collects usage statistics to sell to advertisers, please see the article "Who Does That Server Really Serve?".

Re:How will non-technical users self-host PWAs?

[Junta]

Probably would have been better to shorten your discussion on the concrete challenges of running self hosted webapps, since no one is advocating for that, and instead bringing more of the linked articles points into your text (that the publisher has eternal control to impose rental arrangement versus the previous arrangement where the publisher had to actually *do something* to extract more money out of the customer).

Crazy man, crazy!

[Anonymous Coward]

As a 47 year software engineer, I view JavaScript as a complex and completely un-intuitive language. I HATE it.

Down the toilet bowl

[taylorius]

I'm 45, I've programmed in c++, java, fortran, even actionscript in my time, and enjoyed using them all. However I cannot abide javascript, and that goes double for the 10000 vague, incomprehensible frameworks that surround it. It could be that I'm just getting old, but I find the whole javascript framework / html app development scene a fractal hall of mirrors. A pox on it all.

What about ClojureScript and PureScript

[Anonymous Coward]

I know thereâ(TM)s many to-JS compilers. But how many of you guys are sold on functional programming.

Re: JS is dead. WebAssembly killed it

[Anonymous Coward]

Unless WebAssembly ends up torturing JS to death Reservoir Dogs style, itâ(TM)s death isnâ(TM)t good enough.

Re: JS best for people who _can_ code.

[fygment]

Almost correct except for the 'does everything poorly'. Clearly it doesn't do everything poorly. In fact it does most things as well, a lot of things differently, some things better (package management), and only two things poorly (classes (but not objects) and types). As for the latter two, you have to believe those are important and my experience is that they aren't in most practical cases. Bottom line seems to be that a good programmer will make as many (or few) errors no matter what language they are using. So better to say: Javascript is for people who _can_ code. If you have a problem with Javascript, the problem is actually you.

  Most people got taught OO programming so they believe it to be the only way to do things but those of us longer in the tooth (say, started with Fortran and C and now working with JS/Node) realized a while ago that it usually isn't the way to go. Imperative and functional is way better for number crunching, object-based is far better than class-based, etc. And as for typing, well that's supposed to reduce errors and improve security. Maybe a 'yes' to the security bit, but a big 'NO' to errors in coding. The latter seem to be better addressed by teaching people how to code attentively and methodically.