Seems like these "usage by" charts are probably not properly normalised(or how you call it?). Seems like these are showing for example how many users (earn 200k+ and use typescript) from all developers instead of percentage of TS users from 200K+ subgroup (which is much more interesting IMO), similar with experience and others.
State of JavaScript 2019
211–220 of 372 posts
Re: State of JavaScript 2019
#212I'm surprised to see Angular drop in ratings and rank so poorly compared to React. I personally prefer Angular myself because it's (a) opiniated and (b) has everything included (HTTP REST calls, Material UI, etc). Just curious why so many people prefer React and mark it so positively.
I don’t know what Angular is currently like, but I worked on an Angular 1.x project and boy was it painful. So many concepts to learn just to make something simple, and the style of dependency injection was really awful (pass an array of strings that get automagically resolved, with implied suffixes, or maybe not but you won’t find out until you refresh and it doesn’t work!)
I work in React these days, which is fine. But it doesn’t really attempt to solve all the same problems that Angular does. And thank goodness for that.
Re: State of JavaScript 2019
#213Earlier quoted context omitted.
It's not just the people, some topics leads to that. E.g you can get far with just a few git commands, but one day, you will encounter a situation that is like a brick wall because you have no idea what's going on inside. Today, most JS devs don't know how "this" works, most python devs never used pdb, most git users picture a branch like a diverging chain of commits and not a moving label, etc. Again it's not the pe…
That ok, but these people need to stop labelling themself as experts. It makes difficult for true experts to stand out.
Oh one can identify experts very easily: they are the ones that understand nuances, see and explain things as cost/ratio instead of good/bad and have an up to date view of their ecosystem of choice but are ok with other techs.
The problem is that they are easy to spot only for somebody with experience in the field. This is why companies sometime pay good freelancers to help with hiring: they can assess what the company can't.
And once they do, they realize quickly that:
- there are few experts
- most resumes are bs
- experts are expensive
- they probably don't need them for most tasks and the bs resume dev may be ok, given the price and skill constraints
- they had one expert internally all along, doing half the job of the rest of the entire team and they should make sure this expert stays
Re: State of JavaScript 2019
#214[flagged]
Re: State of JavaScript 2019
#215Wow, 39.9% of respondents mark themselves as "Expert" at CSS. I've been doing front-end in various guises for 12 years and I would only rank myself maybe 5 or 6 out of 10. As I've gotten more experienced in my career I've become more aware of what I don't know as opposed to what I do know. It's funny that "Advanced" is mastering animations and transitions whereas "Expert" is being able to develop a full-front end con…
I design in Sketchapp and then write my code accordingly. Sketch let's me make a consistent style. I know all of sketchapp's keyboard shortcuts.
Re: State of JavaScript 2019
#216Earlier quoted context omitted.
Slows down what? Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware. Development time? Types reduce mental overhead and abstraction for the developer, speeding up development. Run time? Variables with types that stay static exe…
> writing maintainable code is the real challenge If you think these same developers can't do it without TS, then you really haven't seen the sort of mess lesser developers make when they try with TS. Unless the JavaScript developer has a strong background in C/C++/Java, they are going to truly fuck up a code base with TypeScript. I'm not making a static/dynamic typing argument here. I'm making an observation that th…
> 9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary.
I think the exact same problems exist with JS no? Except now there isn’t any compiler to shut up, and things just silently fail.
Re: State of JavaScript 2019
#217Earlier quoted context omitted.
Meteor 0.8 was released in 2014, and I'm sure your app would still work on the latest Meteor release without much changes, while in the meantime offering all the latest JS features (JS in 2014 was a completely different world). How many other JS build tools & frameworks from 2014 can say the same?
How many JS build tools from 2014 exist? And how many are still used? I think both will be fairly close to zero.
Are Grunt and Gulp still not used?
Re: State of JavaScript 2019
#218Earlier quoted context omitted.
Just the fact it uses Handlebars templates disqualifies it as a viable option for me. Handlebars is terrible to work with, especially once you're used to JSX type of options. HBS = restrictive for nonsense reasons. The separations of Model, View, and Control really don't make sense anymore. It's outdated. I've worked with it for years and I consider myself familiar with it up until 3 years ago, but I would never go b…
> The separations of Model, View, and Control really don't make sense anymore. It's outdated. What ? why ? care to elaborate please ? and what do you use instead ? MVVM ?
Ember uses MVVM
Re: State of JavaScript 2019
#219Earlier quoted context omitted.
In my experience, people who have been experts on JS before TypeScript became a thing hate it. - It doesn't give them any advantages, while severely limiting their options and workflow. For newer developers with background in other languages it is quite nice though.
For developers coming from other languages, typescript and the tool support in VS Code is what makes frontend engineering tolerable these days. A big difference with just a few years ago. I insist on it in most projects I'm responsible for. I see no good technical reasons not to use it at this point.
I mean, if you really want to, you can configure it to be just JS with .ts file extensions :P
Re: State of JavaScript 2019
#220Wow, just learned of Svelte from this. After reading their explanatory blog post and coming upon this blurb: That all changed with the advent of hooks [React and Vue], which handle state in a very different fashion. Many frameworks started experimenting with their own implementations of hooks, but we quickly concluded it wasn't a direction we wanted to go in ... We can just use the language. Updating some count value…
I implemented a similar feature in the Blop language, but by simply using a Proxy
https://github.com/batiste/blop-language
Not sure why they claim proxies are complicated... I found it was a piece of cake to implement a working library for state management using a Proxy.