Slashdot Mirror
'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.
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.
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".
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.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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!
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.
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.
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.
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.
for the win. :)
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.
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?
Are you saying 80% of the net is using browsers over two years old?
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
The real litigious bastards...
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?
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?".
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.
XML is like violence. If it doesn't solve the problem, use more.
See typescript's a sync/await
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.
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.
The 'drag drop API' has NOTHING to do with JavaScript.
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.
"Consensus" in science is _always_ a political construct.