Live data from Hacker News

State of JavaScript 2019

2019.stateofjs.com

201–210 of 372 posts

Re: State of JavaScript 2019

#201

Earlier quoted context omitted.

Typescript doesn't make things easier, and react is intuitive? You know April fool's is still a few months away right?

TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers. My claim: TypeScript offers no benefit. Ever. That's 2 years of fulltime TS experience talking and 18 years of fulltime JavaScript experience, on top of a whole bunch of full stack (Java and .Net with C#) experience. I think the popularity of TS is going to decline. And I think it's only popular because of the influx o…

I personally dislike Typescript as it is most often a hindrance for me, but:

About 2 years ago I had a pull request from a junior Dev - I can't remember all of it but basically he had an event (passed from some slider component) if something in that event was undefined he set a variable to be null otherwise it was an array, then he did an if check against something else in the event, and inside the if he checked the length of the variable.

So of course I pointed out that getting the length of null would be a problem. I actually had to argue with him a bit because he thought it was necessary for reasons. I got him to go through his code again and stuff was refactored to be better.

Typescript would have solved that problem.

I am in a big react SPA right now, that also uses TypeScript, often TypeScript causes problems of the sort - I am in a place where X could possibly be one or the other type (null or an object) so you need to write a check for it, in reality it would never have gotten to that particular point if it was null but poor TypeScript cannot figure that out.

Often things are wrong because some library thinks something is an Element instead of an HtmlElement or similar type of problem etc. etc. you have to go fix types, which can take more time than it should.

Finally it can be that TypeScript gives you very cryptic messages about what is wrong and it can take a while to decode what is wrong with otherwise fine code.

I can also say that in the 8 months I have been on the project I think TypeScript has caught two bugs I would have been putting in.

This is based on 18 years JavaScript experience 1 year TS experience. So I don't think it offers no benefit, I think it offers some benefit and irritates me more than it benefits me - but that is not the same thing. I must say that if you've been using it for 2 years and never had that oh yeah, I didn't think of that experience - well that's pretty impressive as regards your attention to detail.

on edit: although I have 18 years JS experience I would say only 7 years major usage, full time doing major stuff with it.

Re: State of JavaScript 2019

#202
post #174

Interesting. React is the thing. But some trends are weird: People ditch Cordova heavily, but also React Native and native apps. Electron rises to the top, although you can't build mobile apps with it that are distributed through the various stores. So, what's filling the void for app development, if everything just went down?

Have the same question. Seems like most web mobile frameworks break when you need anything advanced.

I've been hiring Java and Swift devs for my shop after a really poor experience with React Native. Hoping that changes soon, but it seems unlikely given how infantile Electron is still.

Re: State of JavaScript 2019

#203

Earlier quoted context omitted.

I'd say that the topic of "node.js" skill covers such a wide range of skills, experience and scenarios, that you'd need to be an expert already to judge how little you know. Someone who'd applied it to a single domain successfully can reasonably feel like they've got a good handle on it. Your question is essentially a proxy for server-side architectures and applications, not nodejs itself. It invites misrepresentatio…

I'm still not grasping how the question "what have you actually built with node?" is "a proxy for server-side architectures and applications, not nodejs itself." and "invites misrepresentation." I feel like you guys think I asked them to rate themselves 1-5 on the subject. I did not, I got their resume, where they themselves rated them on the subject. With my question I was just checking whether that self-assessment…

Maybe it’s like this: Given that I have no experience with Go, I’d still rate myself at least 3 when someone asks me how well I’d be able to work with it because the job they’re asking it for is ‘back-end development’.

Of course this falls apart the moment they ask me any Go question during the interview, but not when I’m actually asked to build a web application in it after being hired.

(the one time this happened people thought I’d been working with the new language for years, but no, it’s just a whole lot of transferrable skills)

Re: State of JavaScript 2019

#204
post #190

Earlier quoted context omitted.

Why is it bad to ask about the actual experience someone had with something that I will be hiring them for? That makes no sense to me.

Asking them about their actual experience is a fantastic question. Sounds like you got a good picture of their prior experience doing so. Asking them to self rate themselves is useless however, as their answer showed.

I ask candidates to rate themselves so I know where to go with the first few questions.

I ask for a 0 (never heard of it) to 10 (you made the thing or wrote a book on it) ranking and most people that have worked a couple years answer no higher than 5 or 6 but recent grads will say 8-9.

Pure anecdata but supports other comments about not knowing what you don’t know until you’ve been around different subjects for a bit.

Example: frontend design is self rated to a 6 but the person can not articulate the difference between raster and vector graphics (or doesn’t know what an SVG is or when to use one or not use one and vice versa).

Re: State of JavaScript 2019

#205

Earlier quoted context omitted.

> I could go on and on about the horror that is typescript In his talk Predicting the future of the web at the last ReactiveConf, Richard Feldman (not himself a typescript guy, but an Elm user) quoted an interesting statistic that most of developers who try typescript never go back to writing plain javascript. I do not remember where that statistic was from, but can attest that with me it is the case. So much for the…

I also can't remember any technology that I've seen so few people complain about online. That was actually part of the reasons for us to start using it.

The worst thing about typescript (and all of the JS ecosystem right now) is the compile times.

Re: State of JavaScript 2019

#206
post #191

Earlier quoted context omitted.

> most of developers who try typescript never go back to writing plain javascript yes, most developers adhere to RDD. That is, resume driven development. You ever see developers going back to Ruby from Node? Or from any shiny new thing to the slightly older but perfectly fine thing? I predict people will move on from TypeScript within 5 years. Purely because everyone will know TS so the differentiating value of TS wi…

This is really condescending. I don’t like writing JavaScript, I find writing TypeScript ok. I avoid both when possible but if the business needs some front end or someone else has chosen Node I’ll oblige, and I’ll be happier if it’s TypeScript. Either way it’s not contributing to my resume in a meaningful way as a backend developer.

Backend NodeJS is Typescript? At least if you know what you are doing.

Re: State of JavaScript 2019

#207

Earlier quoted context omitted.

> I could go on and on about the horror that is typescript In his talk Predicting the future of the web at the last ReactiveConf, Richard Feldman (not himself a typescript guy, but an Elm user) quoted an interesting statistic that most of developers who try typescript never go back to writing plain javascript. I do not remember where that statistic was from, but can attest that with me it is the case. So much for the…

> In his talk Predicting the future of the web at the last ReactiveConf, Richard Feldman (not himself a typescript guy, but an Elm user) quoted an interesting statistic that most of developers who try typescript never go back to writing plain javascript. I do not remember where that statistic was from, but can attest that with me it is the case. Same applies to me, but on the flip side: Typescript (by its very name)…

I feel like Typescript has been very successful (combined with the slightly earlier switch to Node) in converting those that were holding out against typing.

Re: State of JavaScript 2019

#208
post #166

Earlier quoted context omitted.

I continue to be involved in development of a Meteor app that started in the 0.8 days, and has been actively maintained up to current versions. I'm a little sad, too, that "Meteor" as a technology all its own hasn't developed legs, but honestly, at this point it's a build stack and little more. Once you use React over Blaze, all it really offers you is a build process and a lack of need to set up your own GraphQL API…

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.

Re: State of JavaScript 2019

#209

Earlier quoted context omitted.

Typescript doesn't make things easier, and react is intuitive? You know April fool's is still a few months away right?

TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers. My claim: TypeScript offers no benefit. Ever. That's 2 years of fulltime TS experience talking and 18 years of fulltime JavaScript experience, on top of a whole bunch of full stack (Java and .Net with C#) experience. I think the popularity of TS is going to decline. And I think it's only popular because of the influx o…

Benefit? When my friendly junior developers add a variable where it isn’t supposed to go the system yells at them.

This is much preferable to me yelling at them, or production getting broken.

Typescript may be a little bit slower if you never make any mistakes ever, and can keep the full state of your program in your mind at a given time. Nobody makes no mistakes.

Post reply on HN