The State of JavaScript 2019 (stateofjs.com) 150
Over 20,000 developers have shared what are their favorite JavaScript features, front-end frameworks and back-end frameworks in a new annual survey. The figures come from the fourth State of JavaScript survey, which included responses from 21,717 developers around the world. On the flavors front -- languages that compile to JavaScript -- most developers were satisfied with Microsoft-backed open-source JavaScript superset, TypeScript, followed by Reason, Elm, ClosureScript, and PureScript. But TypeScript also came out on top when ranking developers' interest as well as awareness. Some 58% of developers reported having used TypeScript and that they would use it again, compared to less than 5% for all other flavors of JavaScript.
Angular and React: hmmm (Score:2)
Who here has used React AND Angular? I need some feedback from people who have actually used both, not armchair analyst opinions. I work for an organization that adopted Angular cross multiple projects. Other than one project, we are not a web development company: we just put web front ends on our embedded devices. At this point about a dozen teams are familiar with Angular, probably 50+ developers or so. We are starting a new project so if we are to switch away from Angular, now is the opportunity. T
Re: (Score:2)
Who here has used React AND Angular?
me.
I need some feedback from people who have actually used both, not armchair analyst opinions. I work for an organization that adopted Angular cross multiple projects. Other than one project, we are not a web development company: we just put web front ends on our embedded devices. At this point about a dozen teams are familiar with Angular, probably 50+ developers or so. We are starting a new project so if we are to switch away from Angular, now is the opportunity.
while angular and react can be used for the same they don't really overlap that much. do you need/want native? do you have complex state to manage?
The article shows React is vastly more liked than Angular at this point.
again, i wouldn't decide a tool based on popularity. do your research about those frameworks, how they fit your specific scenario and current resources.
But I hesitate to have one team doing something different, and to fragment a department that has finally unified under something.
there is no reason why both can't be used in different projects. any competent developer should have little problem getting up to speed with either angular or react. deep knowledge and getting the proper infras
Re: (Score:2)
FYI: In this context "momentum" means things like:
Re: (Score:3)
I've used both and it depends - to be honest, I like React's less opaque execution model a lot better than Angular's more hidden one, but that's personal taste, and either framework is serviceable. That being said, React is where the R&D mindshare is being invested and is liable to have longer legs than Angular. On the other hand, you have a team that is familiar with Angular and all of its quirks who would have to be retrained for React. Basically, the fact that you ask the question is an acknowledgmen
Re: Angular and React: hmmm (Score:2)
React is better for most situations. It's got a steeper ramp up, but it's way smoother long term. Way better architecture with more digestible day-to-day problems. Only "downside" is the immutability, which is what leads to the steep ramp for most people.
The one area Angular shines is big web shops. Places with dozens or hundreds of web developers and designers. In these places - and with significant engineering expense from your top guys - Angular can be used to deliver components that your designers can u
Re: (Score:2)
[React]'s got a steeper ramp up
Compared to Angular? How do you figure that? Even with all the recent clutter, you can still document the essential APIs you need to use React for web development on a single screen, and a moderately experienced developer can learn it in a few minutes.
Only "downside" is the immutability, which is what leads to the steep ramp for most people.
This doesn't make sense. Nothing about React requires immutability, though immutability can be helpful for efficiently determining when to rerender components.
Are you perhaps confusing React-the-library with React-the-ecosystem? The latter is, like most progra
Re: Angular and React: hmmm (Score:2)
Because Angular can better be cobbled together by a web designer without any coding, and because the state management in React is drastically different than what JS devs are usually used to.
I'd say it's easier to do Angular poorly than it is to do React poorly, but it's easier to do React right than to do Angular right.
Re: (Score:2)
the state management in React is drastically different than what JS devs are usually used to.
What state management in React? Apart from setState/useState, which are mostly only useful for temporary view state anyway, React isn't opinionated about how you manage your state.
Again, are you perhaps confusing React-the-library with React-the-ecosystem? Nothing says you have to use Redux or MobX or Immutable or Immer or any other specific library to help manage your state. For simple applications, it's perfectly possible to manage state without a lot of infrastructure at all. For more demanding requireme
Re: Angular and React: hmmm (Score:2)
If you're doing mutable state in React, you're literally not following the documentation. You can do it, but you're doing it wrong.
Re: (Score:2)
If you're doing mutable state in React, you're literally not following the documentation.
Um... setState on class-based components and useState in hooks world would like a word with you.
Re: Angular and React: hmmm (Score:2)
The immutability of React is what will crush your bug count.
Re: (Score:2)
Re: (Score:2)
The fact that the main thing you use to change a React component is called 'setState' is all the answer he needs
Re: Angular and React: hmmm (Score:2)
"Never mutate this.state directly. Treat this.state as if it were immutable." - the React docs.
Look, if you don't know how to use React properly, then just STFU.
Very useful analysis (Score:3)
Thank you for publishing this - Interesting and quite intuitive (for me, anyways) approach to showing the various JS technologies in terms of what user's think of them. Maybe this is an example of my own cognitive bias at work extrapolating what I don't know based on what I do know (and agree with, as it's shown here) but I'm thinking that this could be a guide to looking at new technologies going forwards.
While I'm not an expert in any way in Javascript, I do have a code base to maintain and based on my experience, I would agree on the how the technologies we're using (namely Angular, NW, Storybook, Vue & React) show up in the graphs and was surprised by where Typescript ended up - that's something we've avoided because of its Microsoft origins/support.
Nothing here changes my opinion that Javascript is a terrible approach to apps programming but it is a reference point when thinking about the future.
Re: (Score:3)
Re: (Score:2)
Trying it without these two paradigms is just begging for a disaster. Maybe not immediately, but most certainly eventually.
Re: (Score:2)
Actually, I found that the "data visualization" got in the way. I did not find it intuitive and having small amounts of raw data filtered by type was much slower to absorb and "chartjunky" than if the designer had just stuck to creating a decent multi-dimensional display that was common across the different survey categories. After all, in all of these categories, you're just displaying an ordered list of percentages over time. Having to absorb three or four different interfaces to understand data from a co
We all process data differently (Score:2)
I don't know what else to say.
A hot mess (Score:2)
Re: (Score:2)
And all of it came from the promise that everyone would write in the same language and it would run anywhere.
Re: (Score:2)
Java was write once, run everywhere. Adopting JavaScript as the one true web language was supposed to make sure that, well, there'd be one true web language.
You're also misrepresenting the relationship between Java and JavaScript. Netscape wanted Eich to incorporate Scheme into Navigator, but then decided they'd rather have Java because it was new and hot. Then they realized using only Java on a web page kind of sucks, so they decided they wanted a scripting language that had a similar syntax to Java: JavaS
Re: (Score:3)
Then they realized using only Java on a web page kind of sucks, so they decided they wanted a scripting language that had a similar syntax to Java: JavaScript. JavaScript was specifically written to be similar to, and complement Java in the browser.
They totally failed at that then. It's nothing at all like Java, not even a tiny bit!
Knowing Java gives you no advantage for writing JavaScript.
Knowing JavaScript gives you no advantage for writing Java.
Re: (Score:2)
It's nothing at all like Java, not even a tiny bit!
That's because it's actually a mixture of Scheme and Smalltalk/Self (with some weird incomprehensible quirks such as variable scoping or behavior of some primitive operations).
Re: (Score:2)
Hiring a Scheme developer and getting him to write a prototype in 10 days probably bode well.
Pissing him off by hiring him to implement Scheme and then demanding something new but "Java-like" probably didn't help either.
At least they didn't use perl.
Re: (Score:2)
*didn't* bode well.
Re: (Score:2)
Ah, ACs, so good at parroting random shit they hear without thinking about it.
“I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.”
-- Brendan Eich, creator of JavaScript
At least you signed your post accurately.
Re: (Score:2)
God help you then.
PHP7 itself isn't a totally miserable language, although theres still some spots of cancer in the spec, its not quite like the hell dimension we all remember from the PHP3 days.
The problem is the ecosystem.
On one hand you have a tonne of old poorly written hell that was clearly generated by graphic designers with no formal comp sci background. Wordpress seems to be a prime example of this, its a complete shocker under the hood. Yes theres been a decade of trying to clean it up going from,
Re: (Score:2)
The main benefit of PHP remains the long, gradual slope of complexity. You can start with simple form processing or in-line text conversion and move all the way up to Java-levels of OOP minutiae. It's still a great language to get started in.
It's less valid in today's world where the fad is stateful one-page Web apps, but I'm old enough and cranky enough to dismiss that as broken nonsense. Get off my lawn!
But your point about Wordpress is spot-on. If you haven't looked into it for a few years, you really sh
Commie programming language (Score:2)
JS because we have not not because we want to. (Score:2)
For people who know how to code in multiple languages JavaScript is rarely anyone's favorite.
However if you want some UI level processing happening on the Clients Device vs off your server, and not bother refreshing you page all the time, JavaScript is the only language you can rely on everyone having in their browser.
Languages like Node.JS is helpful because it allows you to do the server side and the client side in the same language. But it isn't because we Love Javascript so much we wanted a client side
Re: (Score:2)
I use it a lot for things that require a "platform" to run in that has basic graphics/UI functions.
Web browsers can do a lot these days.
Re: (Score:2)
Re: (Score:2)
Everyone I know that's been writing code for a long time [with success] thinks javascript is terrible. (And that includes people both in- and outside my usual work/friend group.)
So, I'm not sure which "expert developers" you're referring to, but I don't think they're as "expert" as you think.
Re: (Score:2)
I hope this is a joke.
What you wrote reads as "JavaScript is awesome, I can do whatever I want with it." You provide absolutely no backup for your statements, and you don't even express why you like JavaScript very well. Few languages (if any) corner developers into fixed standards. JavaScript is one of the few modern languages that is riddled with features that you should never use (eval), and quirks that still remain or were only recently fixed. It has strange type coercion, a weak numeric type system, bi
Re: (Score:2)
That's the biggest problem. JavaScript has so little built in, and what's built in is so rickety, that a zillion frameworks sprang up to plug the holes. So you don't have JavaScript, you have React or Angular, or Joe's Cool Framework layered on top of JQuery.
You might love that "flexibility" if you only ever have to deal with your own code, or code written by people who use the same set of libraries you do, but anyone with wider experience recognizes that it's a major weakness of the language.
Re: (Score:2)
Re: (Score:2)
I expect WebAssembly will get direct DOM access pretty soon. That's got to be way up on the top of Google's list.
Re: (Score:2)
I had some hope with Web Assembly, however its lack of support of DOM is the big showstopper. Because with Web Assembly you could actually have normal languages compile into that format for your client side control.
This. Web Assembly DOM support is what we need to free us from this Javascript ball and chain.
Once this happens I would expect Javascript's popularity to only go in one direction: down.
Re: (Score:2)
Using the same functions to check for validation on both the client and server side is handy and prevents sloppy coding during the products life cycle is the biggest advantage.
Re: (Score:2)
Irrelevant (Score:2)
The fact is that it does not matter what these people think. JavaScript is pure evil incarnate and the root cause of 100% of malicious software on the Web.
They can go ahead and argue about what their favourite form of malice is, however, I for one do not care.
Your malice shall not be permitted to execute on my computer.
End of Line.
Re: (Score:2)
Re: (Score:2)
Using GNOME or Cinnamon?
Why would anyone in their right mind use Gnome or Cinnamon? Now that you point it, being loaded with Javascript just fits right in with that compost heap.
Re: (Score:2)
No.
Re: (Score:2)
JavaScript is pure evil incarnate and the root cause of 100% of malicious software on the Web.
Would you prefer that all interaction with web applications be done through form submissions, each with a full page reload?
Downloadable native applications are just as prone to malware as client-side JavaScript in websites.
Two edged feature (Score:2)
I learned Typescript by following the Angular 2+ tutorials, then online courses. As a long time Java user it was much easier to use Typescript than Javascript because -- wait for it -- the compile time type checking!
Hence the name: TYPE script.
So it is a bit ironic that the big deal about Javascript for its fans is that you don't have to be a slave to type checking and if you are smart as opposed to dumb and who needs dumb programmers anyway.
And yet it the addition of type checking of Typescript th
Re: (Score:2)
it is a bit ironic that the big deal about Javascript for its fans is that you don't have to be a slave to type checking and if you are smart as opposed to dumb and who needs dumb programmers anyway.
It's rich... Javascript programmers obsessing over which of them is dumbest.
Compile = not scripting (Score:2)
It's no longer a scripting language if you NEED build tools and compiling.
Scripting is supposed upset "real" "serious" programmers. It's not supposed to make massive complex apps which multiply human flaws and therefore greatly benefit from anything they can invent to compensate our problems; however, I fail to see where type checking is actually a problem for real programmers.
Yes, the browsers only have a scripting language and we apparently need to build massive apps running on the browser OS... People n
Re: (Score:2)
Even so, I wouldn't be surprised if we didn't have Photoshop running in a browser within 10 years
Um.
Doka. [pqina.nl]
CamanJS [camanjs.com]
Tui [github.com]
.. and that's just a few from the first page of a google search. I realize that Photoshop is much more extensive but I'll bet 90% of the most important features are covered already. 10 years?
I don't get it? (Score:2)
Why all this hullabaloo over a font?
Re: (Score:3, Troll)
Re: (Score:2)
No mod points sadly...
Re:TypeScript is for junior devs (Score:5, Informative)
Funny, Java, C, and C++ are also languages that use types. They are also languages in which people write software that's much more critical and complex than the software written in JS. Types are a way to get the computer to do some of your testing work for you. If you don't want the computer to do your work for you, why are you using JS instead of assembly?
Re: (Score:2)
Re:TypeScript is for junior devs (Score:5, Insightful)
Either way JavaScript sucks. I'd sooner work in C or Java than work in JavaScript
Re: (Score:3)
No one is building a web browser that lets you manipulate the DOM using C. And as I recall, Java weblets were a total disaster.
There is a critical need for JS, not because of the language itself, but because no one has taken a better language, built the bindings for it, then wrangled it into 3 or 4 major browsers.
Moreover, the idea that you start by choosing a language makes no sense. You start by looking at what needs to get done first, then you chose a language suited to the problem. In almost every case
Re: (Score:2)
And as I recall, Java weblets were a total disaster.
Do you mean Java applets? And if so, what makes you think they were a total disaster? Some of us were building complicated web UIs using applets literally decades ago that would be challenging for a lot of the modern JS frameworks to keep up, and the reason I know that is that when the browser developers decided to kill of Java plugins, some of us had to rewrite tried-and-tested applet-based UIs in JS using those modern frameworks, and it was painful how much time was wasted testing for and debugging exactl
Re: (Score:2)
the browser developers decided to kill of Java plugins
They did so because security of Java applets were a total disaster.
Re: (Score:2)
Yes they were, but that has little to do with the language itself. (Nor does it mean the security of the native browser-hosted versions of the same functionality will necessarily be much better once the same attack surface is available.)
Re: (Score:2)
OMG, a Web browser in Javascript... a perfect horror. Let's see how many weird bugs and security holes we can have and how slow we can browse!
Re: (Score:2)
Not a web browser in JavaScript, the fact that every web browser builds in a JS engine that lets webdevs manipulate the DOM using embedded JS. You know, like every single web browser out there?
For the foreseeable future, there isn't going to be an alternative.
Re: TypeScript is for junior devs (Score:2)
Have a guess what 2 languages most major web browsers are written in. Clue - it ain't javascript.
Re: (Score:2)
Either way JavaScript sucks. I'd sooner work in C or Java than work in JavaScript
I second your comment!!!
Re: (Score:2)
I'm guessing you're a Haskellist, am I right? In that case, while Haskell's type system does provide some advantages which C doesn't, I still think that being prevented from calling a function on an object/struct with a mismatching type is already a huge benefit compared to JS and Python's "you call anything on everything and we'll crash in runtime".
Re: (Score:2)
Re: (Score:2)
Lisp has static typing???
Re: (Score:2)
Re: TypeScript is for junior devs (Score:2)
When you're writing in regimental OOP-crazy languages, types help. In dynamic languages like JS, you're just getting in the way.
I don't care if you pass an argument that implements ILogger. I care that you pass an argument with a .log method.
Type checks are fine in languages that need them. JS does not need them.
Re: (Score:2)
Well, one of the roles of type checks by the compiler are their use as training-wheels. That readily explains why so many developers like them: They cannot really get things to work without that help. In code that is more demanding than business code or glue, type checks matter a lot less.
Re: (Score:2)
In code that is more demanding than business code or glue, type checks matter a lot less.
I've got a substantial amount of demanding code that is in production right now, in environments where updates in the field are extremely expensive, with literally zero bugs reported from the field so far after several years of deployment. That code uses formal methods, including as much support from a good type system as we can get, to help avoid silly mistakes slipping through and let us focus on more important matters during review. This seems to be the complete opposite of the view you're expressing, wh
Re: (Score:2)
And this is a special case. Formal methods are used in a tiny portion of all software development. Hence your case does not qualify as a counter-example and, I suspect, you are well aware of that.
Re: (Score:2)
Yes, the level of formal methods we use on that project is unusual for general software development, but it is nevertheless a counterexample to your position. This isn't a black and white issue, and plenty of good programmers writing serious software do routinely use less hardcore versions of the same ideas to ensure the quality of their code automatically in less comprehensive but still useful ways.
Re: (Score:2)
Nope. Exotic situations are not valid counterexamples for general arguments. This one fails because of course when you have deployment restrictions so bad that you need formal methods, you will of course want static type safety (which is itself a formal method) in the pack if the task allows it.
Re: (Score:2)
Well, your argument was literally that type checks matter less in more demanding code, and I have demonstrated that in relatively demanding code type checking matters more than ever, so I don't really see how that's not a contradiction. In any case, you're glossing over the other point from my previous comment, which was that this isn't a black and white issue. Static type checking is useful any time you're working on code where there would otherwise be a significant risk of causing bugs because of type err
Re: (Score:2)
Strong typing is a helluva more than training wheels. It's one of the best guarantors against a number of bugs, some security critical. When I'm stuck coding in a language like JavaScript or PHP, I'll do what I can to maintain the ethos, even if the language won't.
Re: (Score:2)
Oh? And why are there successful languages that do not cause more security problems or bugs that do not have it? Do you have any actual facts or is stating your opinion all you can do here?
Re: (Score:2)
Re: (Score:2)
Just ask yourself what is opposite of "dynamic language"
A non-dynamic language? How does that help?
Re: (Score:2)
When you're smearing dog poop on the wall, do it with Javascript. Always choose the best tool for the job. For real work, use a real language.
Re: TypeScript is for junior devs (Score:2)
Sounds like youâ(TM)d love typescript, then. If you only took the time to learn what it actually does, which (from your comment) itâ(TM)s obvious that you didnâ(TM)t.
Re:TypeScript is for junior devs (Score:4, Insightful)
TypeScript sucks. It serves no purpose to those who can organize their code. You don't need type checks. All they do is put road blocks in front of automated testing.
In order to organize your code without artificial aids requires that you be able to hold the entirety of your code in your head. As the human mind is fallible, that limits the amount of code for which this can be done. And that limit is very small, thus limiting your ability to write perfect code to solve only trivial problems.
Re: TypeScript is for junior devs (Score:2)
No it doesn't. Use jsdoc. There's no need for type checks if you follow the docs.
Re: (Score:2)
No it doesn't. Use jsdoc. There's no need for type checks IF you follow the docs.
Something .. something .. humans are fallible .. something something.
Re: (Score:2)
For what it's worth, there is a lot of easy money to be made in some parts of our industry by cleaning up after infallible programmers fail in ways that the better tools they don't need would immediately have avoided.
Re: TypeScript is for junior devs (Score:2)
JSdocs are like types that canâ(TM)t be automatically verified.
Re: (Score:2)
Re: (Score:2)
In order to organize your code without artificial aids requires that you be able to hold the entirety of your code in your head.
Well, I guess, at least if your code is tangled. For the rest of us, there are hierarchies.
Re: (Score:2)
For the rest of us, there are hierarchies.
If you don't have a strong static type system, how do you know your data is respecting the hierarchies you think it is?
Re: (Score:2)
Re: (Score:2)
OK, let me rephrase that. How do you know before you accidentally launch the missiles, turn off the pacemaker, crash the stock market, or otherwise screw up when you're already in production?
And please don't say unit tests.
Re: (Score:2)
TypeScript sucks. It serves no purpose to those who can organize their code. You don't need type checks. All they do is put road blocks in front of automated testing.
turns out in the industry a majority of developers have no clue on how to properly organize their code (nor how to use the vastly underrated power and flexibility of js, mind you). i would never use typescript on my own. for a team of developers educated in nowadays agile era? you bet.
also, if type checks get in the way of your testing you're doing it wrong.
Re: TypeScript is for junior devs (Score:2)
Maybe they would learn if they didn't use TypeScript.
What those developers absolutely won't learn while using TypeScript, is JavaScript.
Re: (Score:2)
What those developers absolutely won't learn while using TypeScript, is JavaScript.
What do you mean by that? TypeScript is, to a crude approximation, just JS with some basic static type annotations and corresponding type checking on top. Pretty much anything you can do in one can also be done in the other, except for making basic typing errors that would probably result in bugs if you didn't find them. Pretty much anything that is a good practice in one is probably also a good practice in the other, too.
Re: TypeScript is for junior devs (Score:2)
What I mean is that won't learn how to structure a large JS app. TypeScript gently pushes a quasi-OOP approach to coding which is not the best way to use JS, which is largely a functional programming language. As soon as you start doing FP, those type checks are less than useful; they are antagonistic to clean code.
Object hierarchies breed more object hierarchies. It's a hammer that makes everything to start looking like a nail.
The situation might be somewhat improved by first class support for multiple inh
Re: TypeScript is for junior devs (Score:2)
Itâ(TM)s clear from your comments that you have absolutely no idea what typescript is, or how itâ(TM)s used.
Re: TypeScript is for junior devs (Score:2)
It's clear from your comment that you write shit JS code.
Re: TypeScript is for junior devs (Score:2)
If theyâ(TM)ll never learn prototypical inheritance, weird this handling, hoisting, and a zillion other annoying things that are byproducts of Brendan Eich being forced to create a programming language in only 10 days... ...I can live with that.
Re: TypeScript is for junior devs (Score:2)
That's the fucking language. If you don't want to learn it, fine. But TypeScript experience provides very limited experience in how to write and structure large JS apps.
Re: (Score:3)
You don't need type checks. All they do is put road blocks in front of automated testing.
If enforcing a basic level of type safety is enough to break your test strategy, you really need a new test strategy, preferably one that doesn't miss simple programming errors.
As for junior devs, is that your view of all static type systems? Because if so, I hate to be the bearer of bad news, but some of the most high-reliability software in the world written by some of the most skilful software developers in the world uses much more powerful static type systems than TypeScript, with excellent results.