'State of JavaScript' Survey Results: Good News for React and TypeScript (sdtimes.com) 89
"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.
Re: JavaScript is for people who can't code (Score:2)
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: (Score:2)
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: JS best for people who _can_ code. (Score:2)
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 ar
If the state of javascript isn't "it's dying" (Score:3, Insightful)
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: (Score:2)
So what's your point?
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Examples of these failures?
I think that JS just compromised my Firefox (Score:1)
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
Re: (Score:2)
Firefox should do a better job asking if you intended to install that. But it isn't an example like I asked for.
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:1)
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
How about stability? (Score:5, Interesting)
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: (Score:2)
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: (Score:2)
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 f
Re: (Score:2)
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: (Score:2)
GUI frameworks are an old, well-studied area of programming
At yet, mostly, they still are all awful.
Re: (Score:1)
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: (Score:2)
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
You Don't Know JavaScript... (Score:1)
You can't call yourself a JavaScript programmer until you've read "You Don't Know JS" [amazon.com] 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.
Well if they had asked me ... (Score:5, Interesting)
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: (Score:2)
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 t
Re: (Score:2)
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?
If not in browser, why JS in first place? (Score:2)
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: (Score:2)
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).
Electron wastes RAM in my experience (Score:2)
Other common uses of Node -- to host standalone desktop applications that are implemented in Javascript
Which leads to the Slack O(n) RAM problem [slashdot.org]: "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?
Re: (Score:2)
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.
How will non-technical users self-host PWAs? (Score:2)
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 i
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:1)
Are you saying 80% of the net is using browsers over two years old?
Re: (Score:2)
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 lik
Re: encouraging (Score:2)
The 'drag drop API' has NOTHING to do with JavaScript.
Re: (Score:2)
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 (Score:2)
See typescript's a sync/await
Re: encouraging (Score:2)
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.
NoScript (Score:2)
for the win. :)
No such thing as a JavaScript Framework (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: No such thing as a JavaScript Framework (Score:2)
Typescript does exactly that, and more.
Down the toilet bowl (Score:2)
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.