Live data from Hacker News

State of JavaScript 2019

2019.stateofjs.com

321–330 of 372 posts

Re: State of JavaScript 2019

#321

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'll disagree with this completely.

I recently wrote an extensive post about my experience learning and using TS as both an app developer and a library maintainer for Redux, and why I am now completely sold on using TS across the board. As part of that, I listed several benefits of using TS that I've directly seen myself:

https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

Re: State of JavaScript 2019

#322
post #86

Earlier quoted context omitted.

Aren't you describing exactly the problems types help with? Must be a reason why typed backend developers allegedly don't pay so much mind to: - "proper" naming conventions - JSDOC comments - unit tests - peer review

So, I've worked with JavaScript since 2001. Up until two years ago I never used a strong typed flavour on top of JS. And I have never needed it. Not in big teams and not in small teams. At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems. Some teams used TypeScript. None of the TypeScript teams got past level 5. All of the res…

> None of the TypeScript teams got past level 5. All of the rest got past level 15.

The TypeScript-using teams also wrote a bunch of machine-verifiable documentation and code navigation tools, so I'm not surprised it was slower. I can tell you without even looking at them which codebases will tend to be more pleasant to join as a new developer. Though probably doing that extra, unrewarded work for some kind of challenge where speed is paramount wasn't the best idea.

Re: State of JavaScript 2019

#323

Earlier quoted context omitted.

Disagree on yarn - npm is still trying to keep up and the latest releases are doing well Seems like within React, Redux/Apollo/plain is splitting the data layer again too But the yarn/npm is a tiny difference and data layer is much more application specific

Redux is quickly being relegated to pile of don't use. I suspect 2020's survey result will show hooks to have completely destroyed redux.

Absolutely not the case. My own estimates are that around 50% of all React apps still use Redux, and the overall download numbers are continuing to increase consistently. I covered this in my Reactathon 2019 talk on "The State of Redux" [0], and my post "Redux - Not Dead Yet!" [1].

In addition, our new Redux Toolkit package [2] and React-Redux hooks API [3] are making it easier than ever to use Redux, and we've gotten a ton of very positive feedback from users who have adopted those APIs.

[0] https://blog.isquaredsoftware.com/2019/03/presentation-state...

[1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

[2] https://redux-toolkit.js.org

[3] https://react-redux.js.org/api/hooks

Re: State of JavaScript 2019

#324
post #242

Earlier quoted context omitted.

A git repository is best thought of as a sort of tree, where the nodes can potentially have multiple parents. This technically makes them a graph ("directed acyclic" to show I do know the technical terms), but our human intuition will mostly work thinking of them as a tree. To understand multiple parents use your intuition about human beings, since we all have multiple parents. A "branch" doesn't really have any spec…

>> makes sure to walk the trainees through the confusing states you can get into, >> then we explain what happened, why, and how to correctly get out of them Is this something you could share?

Not meaningfully. It isn't written as a blog post document; it's a series of commands and presentation notes, designed to be delivered live by me. You can basically obtain what I have in the document by combining A: what I wrote above B: a good git tutorial, see internet and C: some screwing around with using git checkout, reset, and merge with commit hashes directly on a little repo you use locally.

Re: State of JavaScript 2019

#325

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. There's been a lot of reasons for a shift in opinions over the last few years: - Redux is well past the initial burst of enthusiasm in the "hype cycle" - As you mentioned, there are a number of common concerns expressed by a lot of folks, most of which revolve around "boilerplate" - There are now a wider variety of other options that overlap with ways you'd use Redux: React's Context and H…

How do you feel about runtime type checking and model validation in Redux? Will that ever be a thing? This is the killer feature that made me abandon it for MobX State Tree.

Not sure what MST does there, but that's not something that would ever be built into the Redux core. The store API is complete as-is. The only changes we're making there are porting it to be written directly in TypeScript.

Re: State of JavaScript 2019

#326

Earlier quoted context omitted.

Half of my income is from training people in JS and Python. I have 50% of those missions that are requested to be "advanced" courses. The vast majority of the participants are not up to the task. They are paid professionnals, but they consistently overestimate they level, skills and needs. They often are not very good, and of course, they don't know what they don't know. So I always check for that first, and rewrite…

If you don't mind my asking how did you get into training people in JS and Python, and, how do you like it?

When I was at the university I was enraged by the grades the other students were getting: it was not because it was complicated, it was because the topic was poorly explained.

So I asked the uni to borrow a classroom and hold my own courses, a summary once before every exam. The grades went up and I felt useful for the first time in my life.

I kept explaining things to friends and colleagues after that, while being a full time dev. That's the only thing I was consistently better at than most people. There were better devs, but I could explain python decorators to a junior like if it was the most obvious thing in the world, and I felt proud of it.

I also still was regularly irritated by the terrible state of teaching. Why do people explain react by first installing webpack + babel while you can just drop a script tag and start playing? Why do nobody tells you what a bloody env var is, like you are supposed to be born knowing that? Why no beginner course ever include an intro to a debugger, do you enjoy having your students suffer? Why do they keep using the confusing reverse arrow in git history schemas, as if technically correct where the best kind of correct?

One day, I decided to do charity work in West Africa. I ended up stayed there for 2 years, eventually created my own company. Things where good.

Then the war started. My company went down, my bank account was frozen and I was forced back home, in debt. Fun times.

I looked for missions to quickly make cash, but in France dev doesn't pay that much. So I dug, and noticed that training professionals was incredibly well paid, thousands of dollars for a few days of work, which for the country is insane. It felt like stealing. It still does sometimes.

But I needed the money, and I though I was good at it, so I spammed dozens of entities. After a few courses, in which everybody was surprised there were no slide and the program kept changing, the phone started ringing.

Apparently most professional trainers suck too, and companies were astonished that not only the trainees could enjoy the session, but that they gained productivity afterward. Why did they paid so much money before, then? It's a mystery to me.

But I kept at it every since.

I usually do training once a month: JS, Python, Git, lot of web, a little bit of data analysis, best practice or design patterns.

But I still dev the rest of the time, otherwise I would always go from planes to hotels and that's no life. Besides, a trainer who doesn't code becomes obsolete very quickly.

Yet I try to get remote gigs for American clients: french customers never pay as much and they are very risk adverse so the projects are less interesting. I do have a few, because we know each others very well and working together is a blast: we can have drinks, say offensive jokes and still get the stuff done. Money is not everything.

All in all, I like training people. It's frustrating, infuriating even sometimes. And exhausting. But when I'm fed up with computers, I get to see people. And when I'm fed up with people, I go back to my computer.

Re: State of JavaScript 2019

#327

The data visualization is often awful and misleading. For instance, consider https://2019.stateofjs.com/javascript-flavors/ 1. The first graph shows "Rankings". I strongly doubt rankings are more importants than values. When Clojurescript goes from 67% to 72%, this increase is shown as a ranking decrease because Reason was introduced at a higher ranking. 2. The meaning of the data is unclear, since the exact question…

I think the best visualization overall is the first one on https://2019.stateofjs.com/overview/.

Seeing the trajectory of each piece of tech gives a lot of insight on overall trends. For example, I was thinking of learning a bit of the more recent Angular (last time I used it was Angular 1.x, before React was a thing), but now I think I'll look more into Vue.js, as its trajectory looks much better.

Re: State of JavaScript 2019

#328
post #47

All the content aside, I just want to say that the presentation in State of JavaScript is magnificent. Some of these charts are superbly designed.

Do you know what charting library has been used? These charts are indeed magnificent!

D3. Incidentally, the creator of the overview chart [1] is also the author of an excellent book on D3 [2].

[1] https://2019.stateofjs.com/overview/

[2] https://www.newline.co/fullstack-d3

Re: State of JavaScript 2019

#329

Earlier quoted context omitted.

Of course. Someone explained it to me, after all. In git, a branch is NOT like a wooden branch on the trunk of a tree, although it ends up being at the top of one, which makes the analogy ok. A git branch is the same thing as a git tag, except it moves automatically when you commit from it. You can see it as a lightweight label attached to a commit. If your HEAD is itself attached to a branch (HEAD is also a lightwei…

> In git, a branch is NOT like a wooden branch on the trunk of a tree, although it ends up being at the top of one, which makes the analogy ok. So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node. Why then is it important to think of "branch" as referring to one rather than the other? As evidenced by the isomorphism, they're the same thing.

It helps to NOT think of a branch as a commit node, nor a chain of commits ending in that node.

A branch is a separate concept, it's not even stored in the history DB but in a different dir. See it as a label attached to a commit, since a commit can have several branches attached to it, or none. A branch will be moved across the history, while a commit will keep his place in the history.

A branch is designed to be easily created, deleted, and moved around, freely, from anywhere to anywhere.

A commit is designed to feel immutable, and unmovable, and although this is not strictly true, this is how you will mostly use it.

A chain of commits is like a rail track, it goes in one direction, each commit composing it never changing (again, conceptually), and never moving. You stack commits, you grow the track, piece by piece.

The branch is more like a flag you put somewhere on the rail track (most often at the end), to let the workers know where to put the next piece.

Picturing it that way let you best use its properties:

- branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want.

- moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast.

- you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working.

- deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink.

- this branch is so good it should be master? Sure you can. Just swap the labels. But let everyone knows :)

Etc.

Post reply on HN