Wow, 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 consistently. I know many people that can build a front end, myself included but are nowhere near mastering anything, especially animations and css transitions.
I write this in jest of course. As we all know, self-assessment is about as reliable as...
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 my course on the fly to include the untold pre-requisites I identify. I don't tell them I do this to avoid making them feel bad. Nobody wants to hear "dude, you wanna learn react and you never used an arrow function, wtf ?" even if being comfy with JS is a listed requirement on the site.
Bottom line: most devs are not experts, and don't have the ability to assess that. But more importantly, it's enough for them to be productive and most industries don't need more.
If I've learnt anything from teaching kids it's the ones really good at it when we start are completely dwarfed by the kids who sucked at it.
You can get kinda far without really understanding what's going on, but if you stop and have to learn something really fundamental the "good" kids just seems to manage. Once things pick up they can excel because the have truly moved on. the previously "good" ones are still copy/pasting from past work or tutorials and get brackets wrong whereas the "slow" ones are now perfectly happy writing from scratch and thinking for themselves.
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 people's fault: they are required to be productive very quickly. There is competitive pressure. So they aim for what's good enough to make things that looks right. Can you blame them ?
Few jobs pay devs to update their skill on company time, and not everyone will spend an hour a day learning new things instead of playing with the kids, doing exercice or going out with friends.
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 special status in git. All it is is a pointer to a particular commit. Literally, that is all it is, even in the data structures. It has no additional ontological existence beyond that. When you make a commit to a "branch", all that happens is that git moves the branch marker along to the next commit. All of the "specialness" of a branch is what is in that behavior.
You can do anything you want with that branch marker, such as yanking it to a completely different part of the tree via "git reset --hard $NEW_COMMIT", and while you may confuse humans, you haven't confused git in the slightest. On the flip side, since branches don't actually "exist", it is perfectly sensible to "merge" with a direct commit hash, because that's all a branch is; a pointer to a hash. You can pick up that pointer and drop it down where ever you want.
(A tag is the same thing as a branch, except that when you're "on" a tag and make a commit to it, git does not advance the tag. But almost all it is is a pointer to a commit. Technically it can carry a bit more data, like a signature, but as far as the core structure is concerned it's just a commit.)
I am not the original poster, but I have a training I give at work for git, and it is heavily based on making sure this understanding is presented. (The other reason I wrote my own training rather than reusing any of the many other existing ones is mine 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. They follow along as we all manipulate a repository, and the training actually spends quite a bit of time in a "detached head" state, checking out, merging, and resetting to commits directly.)
>> 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
- you don't where somewhere and you moved and you can't go back: "git reflog"
- local repo and remote with a different history (e.g: you rebased on a published branch): the whole team to sync with remote except you, then hold. Export your remaining changes as a patch. Reclone. Apply patch.
- remote has a different history than the rest of the team (e.g: you forced push a different history): Delete remote, recreate, repush from one of the team mate, then apply previous solution.
- your messed up your merge and wish to never have done that: "git reset --merge"
- the last commit is not published and you messed it up: "git commit --amend"
- the last commit is published and you messed it up: "git revert HEAD"
But rather than solve problems, better not get them in the first place. Always "git status" before anything, always get a clean working copy before checkout/pull, create a fat gitignore, etc.
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.
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 lightweight label, but this one is like a red sticker on a map saying "you are here"), when you do "git commit", the branch label is moved to the newly created commit.
Hence, you can have several branches on a single commit, and you can move branches around: they are just labels. You can also have branches with different names locally and in a remote, or have a branch with the same name, but on different commits locally and in a remote.
A branch is like a reference, it's useful to tell git what place in the history you are talking about, without referring to a commit in particular. It is a moving reference because the place in history you talk about is always changing: it's the top of a chain of commits, the ever changing last thing you worked on for this particular part of the history.
We want branches because they are a convenient way to say "I'm going to do something on the latest commit of this part of the history":
- "git checkout branch_name" => I'm now working on this part of the history, gimme all the latest stuff you got and consider everything I do is now related to it.
- "git checkout branch_name /file/path" => Get the latest version of the file from this part of the history and bring it on my hard drive
Of course, you can put a branch at a commit that is not yet the top of a chain of commits. But soon this commit will become the top of a new chain of commits because when you'll commit from this branch, a new commit will be attached to the previous one, diverging from the original chain, and the branch label will be moved to it. You now have a fork of two chains of commits, both of them having a different branch label at their top:
"git checkout commit_hash && git checkout -b new_branch_name" => I'm going to consider this commit as a new starting point and work from that.
In fact you can move a branch pretty much anywhere, create one or delete one at anytime, including "master", which is not a special case, just one created automatically on the very first commit.
This is also why if you "git checkout commit_hash" instead of "git checkout branch_name", git warns you you are in a "detached HEAD" (the "you are here" label is attached to a commit directly, not a branch label). Indeed, a chain of commits (the stuff that looks like a wooden branch on a trunk in graphics) can exist without a branch label. But it won't be convenient to reference: looking for the hash of the newest, latest commit, every time you want to mention it is tedious. Besides, git will run "git gc" automatically once in a while, deleting diverging parts of the history with no branch or tag, so you may lose this work.
This makes it clear that tags are labels like branches, only they don't move. They serve the purpose of having a static reference to a fixed point in time: both allowing you to easily talk about it, and let git know you want to keep this around.
All that stuff is way clearer with a visual explanation. For my Git training, I bought a fantastic toy for 10yo with magnets that let me build a 3D history tree and use post-its to represent branches and tags. It's instantly obvious. It's really fun, you can move stuff around and show what each command does to the tree. After that, git seems much more accessible, and you just grunt at the terrible UI ergonomics.
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 :)
> branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want.
Ahhhh. So the distinction matters if you bring in a bad assumption from SVN. It had never occurred to me that a labeled branch would be noticeably more expensive than the weight of the commits making up the branch.
> 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.
Well... yeah. That's how you create branches. You go to the commit you want to branch from, and you run `git branch`. The fact that you can do this is immediately implied by the way you have to do it. I don't understand how someone could believe something different.
> deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink.
This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data.
> this branch is so good it should be master? Sure you can. Just swap the labels.
This is another one where I don't see how you would believe something different. Even if branches were huge, heavyweight objects, they have names, and changing the name of something is generally not so hard to do. There's a command solely for the purpose of renaming branches. (`git branch -m`)
> 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.
And in my mental model, a checkout is indeed a (potentially mass) update to file contents (and, if applicable, file existence). Saying "apart from moving the files to the working copy" sounds -- to my ears -- kind of like the chestnut that "controlled for height, taller men earn no more than short men do". Setting up the working copy is the thing I'm looking to accomplish in a checkout.
I can imagine two types of people who want git training:
- Never used version control.
- Used subversion heavily; trying to update to the new new thing.
In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group?
> In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group?
Many years ago, SVN users coming to git were indeed a huge source of head scratching.
Not anymore.
Now we just have a lot of people that just don't think in a way that will lead them to say "So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.". In fact, they don't know what isomorphism means, nor that the word exists.
Personally, I like to picture git as applied graph theory. One command = a bunch of operations on the graph.
But there is an old git joke that says:
"Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space".
It is nonsensical (it's a meta reference to a Monad joke), but I think it gets the point perfectly: we need to bring git to the people that needs it, not to ask the people to come to git. I don't care what level of abstraction they are comfortable with, I want them to feel like they can trust their ability to be productive with the tool and feel their project is safe.
And I find that this way of explaining branches is the most universal way for people from all sorts of background to have a decent model of how git works under the hood. So that when fall in a trap, they can use this model and find a pragmatic way out by themself.
Being right used to be my objective when I was younger. Now I just want to be helpful.
> This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data.
git reflog is very useful for this. Also, when you delete a branch, git helpfully prints
Deleted branch foo (was da2bb5d)
so you already have that information, right there.
Was going to say that. reflog should be in every tutorials.
When I started using git, I checked out back in time, then git logged and was baffled to not see my most recent commits in the listing. I panicked, though I lost my work.
Git terrible UI didn't help there: who though it was a good idea to just hide everything with no hint of how to get back at it?
Of course, I could have just git checkout master to get back where at was, I just didn't know it. But that's the point of reflog: if you are not sure what you did or where you are, it's always there for you, it has your back.
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
I have a friend that had some home remodeling work done, poorly. The friend said to me, "But, they were professionals!" I responded, "Well, that's the problem. A professional is someone who will do the least amount of work in the least amount of time for the most amount of money. If you want someone who actually cares about the work, hire a craftsman instead of a professional."
> you wanna learn react and you never used an arrow function, wtf
At least in the early days, using React was the first time most people would be exposed to webpack/babel, so it was also their first exposure to the newer JS features.
But you didn't need arrow functions at the time because createClass autobind this and you used methods. Now with extends and hooks, it would be a pain.
Besides, it's alright to learn es6 and 7 with react if you have time, but if your company pays a $10k react training in a 3 days session, you better have the pre-requisites right.
And at the very least, don't pretend to be "an expert" in 2019 if you don't know es6. Every tutorials for beginers include them now. Every docs of every libs use them.
You don't have to be an expert. It's legitimate. I don't advertise myself as a JS expert despite being pretty good at it.
But it looks better on the resume, and once you are hired on that assumption, you can't go back. Next time the company asks, you say expert again.
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.
The "expert" description is far too vague and easily interpreted as less advanced than the "advanced" category. Results for this question are meaningless.
Exactly my reaction. I do think that you can create stunning animations and for that you need some expertise but animations are the "the basis" for a complete and successful front-end.
You're absolutely right. I'd bet the CSS experts understand the context of the question and the difficulty involved in "styling an entire front-end app from scratch with consistency." I think a lot of novices looked at that and thought it meant using one of the css grid / framework libraries and making a website. The question hides how difficult that actually is with CSS and how easy it seems if you've never had to do it.
(Survey author) yes, it seems like I made a mistake with the different level descriptions. For me knowing how to do things like transitions and animations is comparatively "simpler" than being able to architecture an entire CSS front-end including managing a design systems, naming, specificity, etc. but I guess many respondents didn't see things that way.
I don’t think you’re wrong on that front. Because I seldom use animations, for example, I tend to have to look up the syntax, but that’s no big deal.
Knowing how to actually build things from scratch in a way that survives the beating of time is something else. It’s much harder to quantify though. Also, these days you have the css in js solutions, which means you can build the app by dropping in the css where you need it, so you get to tick that box, but if you tried to do it the “traditional” way you might not even know where to start.
EDIT two of my more common phrases at work are “you could just use css for that” and “you don’t need to use flex box to do that”. I’ve found that there’s a lot more using css to style things in isolation without understanding the power and performance it brings to the table. I spend more time trying to stop react renders from happening because css should have just been used than I do on the micro detail of ordering things a certain way to avoid repaints.
The problem is that you're trying to mush multiple dimensions into one axis, in the same way that political pundits try to shoehorn all debates into an arbitrary left-right axis even though political alignments are actually highly multidimensional. You should either query the multiple dimensions separately or ask only for a single dimension with a more clearly focused definition.
I don't think you made a mistake. This is just one of those topics that for some is subjective and for other is objective.
As others have mentioned, getting people to assess themselves accurately is very difficult. We always seem to skew towards the overly-confident side - not least because this what is usually rewarded in the job market.
Although it might be worth considering a simpler heuristic in the future as the distinction between Advanced and Expert is somewhat vague and perhaps ultimately not very informative.
I got a resume a while ago where the applicant rated their skills 1-5 stars. They has rated themselves either 3 or 4 out of 5 in Node.js. When asking what they actually did with node, they explained they built some proof of concept once. I got to see the code and it was maybe 4 weeks of work for a beginner...
At that time I was leading a small Node.js dev team and I would maybe rate myself 3/5 in Node. We didn't end up hiring them.
I don't see that as terribly problematic. Unless a specific absolute scale is identified (as per another comment, e.g., the top of the scale meaning "I wrote the book on it"), I would assume the ratings were all relative to each other and the candidate's general skill/experience.
So 4 - 5 stars in an area just means "this is what I'm most comfortable working with and/or have the most experience with", not "if you rank yourself a 3 then I'm better than you at this" or "I'm a world-renowned expert at this". Otherwise, I'm not sure what you would expect from a fresh graduate who'd decided to use this format; 1 star for everything, or fractions of a star?
My lesson from that experience would be to throw away that useless 1-5 star rating scheme and skip to the interesting question immediately: "Tell us what you actually did with NodeJS."
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 misrepresentation.
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 was correct. I don't see how that is a bad question... Should I just believe their resume? Should I give them some programming assignments? Should I ask them to write a complex algo on a white board? I feel like just asking is a good way, personally, but maybe I'm wrong.
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)
The self-rating is useful because it gives you a measure of their perceived proficiency in skills relative to each other. You still have to ask a question like you did, but now that you know that "3/5 stars in Node" means advanced beginner level, you have a good idea what to expect when they rate their SQL skills 5/5 or their CSS 2/5.
Sorry: I misunderstood slightly, thinking it was something you put to them. In our tech interviewing I ignore self-assessed ratings, finding them useless for the reason you do, but I don't hold it against them if they're inaccurate just for the reasons I outlined.
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).
I interviews interns from a school where they all ask their students to rates themselves like that.
At first I was put off, but now I interpret it as their own personal scale, with 5 being what they the best at, and not as "I know everything about this".
But even then, the best candidates are usually the ones who rated themselves the lowest.
That makes sense. The more I know about a topic, the more I know about how much I do not know. If I know a topic very well, I also know how very little I really do know, so I'd rate myself much lower.
Second this - I'd have put the requirements of "expert" to be "advanced", skipped the rather small part of "know how to animation" as it doesn't constitute such a "level" for itself as much as beeing "one of the tools you'd probably know if you think you can write a frontend from scratch in css".
The "expert" category would rather be "having a deep understanding of what the browser does with styles and how the concepts of display etc actually work" for me.
But it's really hard to draw a line, css allows for awful hacky solutions that end up looking like they work, and many people "able to write a full frontend project" will produce rather bad CSS irl.
Probably because a lot of people have been working with it for a long time (like you). I think I started 20 years ago - but I just learned like 40% of css grid this past weekend. (I've been a happy flexbox user for a few years)
But I know what you're saying. I also noticed a few percentage points of people saying they have 20+ years or React experience at this point.
> It's a cognitive bias in which people assess their cognitive ability as greater than it is. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence.
I'm not sure it's worth addressing this rant because it conflates so many things, but...
> "Oh, look, typescript! Finally JS looks like Java!"
TypeScript's structural typing is vastly different from Java. With Java, every type must be declared somewhere. TypeScript types can be declared, defined as classes, or just based on whatever you typed.
At its core, the TS compiler is just paying attention to what you do and making sure you don't forget what you did elsewhere. It's like having bumper lanes on a bowling alley.
It's arrogant to think you'd get no use out of it when Microsoft, Facebook, and Google have all decided they need static typing on the back and front ends. If you think the cost is too high, that's a different argument, but I'd wager it's because of a poor IDE setup.
> Which means that silly HTML and CSS is going to be easy!
What does this have to do with TypeScript?
> Buzz off back to the backend, you strong-typed clown who doesn't understand what UX and a11y mean.
This is bizarre gatekeeping. TypeScript was adopted by Angular and, early on, seemed focused on browsers rather than Node.
> I know most people love it. I fucking hate it. I'm using it, because I have to, but I never needed it. It literally offers me nothing of value.
That's fine. You may believe it offers no value to you (although better auto-complete and errors are objectively valuable), but it does offer value to anyone who works on your code. TypeScript is like machine-readable self-documenting code.
If you document your code, it might as well be in a format the compiler can enforce and your coworkers can use without having to look back and forth between files.
> 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 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.
Same applies to me, but on the flip side: Typescript (by its very name) is probably only going attract the kind of users who appreciate the kind of things that Typescript provides.
People who insist that dynamic typing is best, that compile-time checks of code is wasted effort etc etc are probably never going to try Typescript (and then go back to JS later on, and thus ruining the "never going back"-statistic).
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.
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.
> 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 will plummet.
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.
"Most" is a fairly strong quantifier, and some people would probably disagree.
Anything new could be termed as an example of RDD, but if that were always the case, we never would have had JavaScript in the first place. One (IMO) useful skill is determining when something new actually provides ROI or is actually a manifestation of RDD or similar.
Unless a language has really great first-class pattern matching (JavaScript does not), I don't ever want to work on a serious project in a dynamically-typed language. The guarantees provided with static-typing and the benefits when it comes to bugs, testing, and refactoring are huge.
Sure, devs that partake in RDD might move on, but there is a good use case for TS that has nothing to do with resumes, and everything to do with a preference in how to build software.
Even if that is true, there is typically a reason things become popular. Right now only Flow / Elm / Purescript could possibly compete in that specific space. Do you specifically see people migrating en-mass to those technologies or do you think something better is coming... soon?
(Or are you literally saying people will go back to JS? - I don't know too many people excited about the prospect of losing all the contextual help and caught compiler errors - and I don't see that happening because of RDD anyway!)
I'm not above going along with tech I think's misguided or bad rather than fighting it, because I know it's trending up and will look good on my résumé, but ask for me to solo-write a Javascript project and tell me delivery must be in Javascript, explicitly not in Typescript, and I'm writing that fucker in Typescript and delivering you the Javascript that tsc outputs, and I don't care if no-one ever knows I did that. It's for my own sanity.
TypeScript is kind of in its heyday though, it's fairly unlikely many teams would be comfortable making a bold decision to "switch back to JS", even if they want to.
Would need to be given more time for such a statistic to be meaningful, if it ever would be.
Not a single developer I know (I was in leadership position in a company with 300+ devs, now I lead a small startup dev team) cares about "heyday". They care about their experience during development being significantly worse with plain JS due to stupid ("we'll use TS because it checks names of properties") but also not so stupid ("we'll use TS because it checks that switches are exhaustive", "we'll use TS because it allows you to check nominal types") mistakes and bugs that TS helps to prevent. For all the devs I know, hearing that they have to code plain JS is the point when they head for exit.
Yeah, I think it might be similar to a lot of things actually. Maybe painting is a good example. Like, the techniques of using a brush in different ways can't be that difficult to learn, but putting them to use to create something great is something else entirely.
You can imagine someone learning those brush techniques and becoming quite confident that they could, theoretically, paint a whole painting, without ever trying and learning the difference.
You see this arrogance everywhere and it's really annoying. The classic joke about it is the "..first assume a perfectly spherical frictionless horse.." one.
This is what happens when front end is marketed as "easy to get into".
I have 2 acquaintances who work in the medical field ask me about how to pivot to frontend web development. When they asked me about it, I told them that a modern frontend developer needs to at least know one of the major frameworks(ReactJS, VueJS, Angular).
They replied to me in surprise. "You mean CSS and HTML, right?"
That one made me mull over if I should get out of frontend web development altogether.
> I could go on and on about the horror that is typescript
As someone who has seen great improvements in delivered productivity and quality across an entire organization, more or less due to Typescript alone, I would be eager to hear what your complaints are.
So sad to see Meteor solidly in the avoid quadrant, but it seems deserved. Meteor is what I learned how to do web development with back in 2015, and it was fun. It didn't take much to make stuff happen, and the baked-in live sync was like magic. I'm still eager to whip Meteor out for proof of concept prototyping because of how convenient it is to have a schemaless database and a framework that abstracts away HTTP, but for one thing I feel Meteor's big bet on Mongo hasn't paid off.
Also surprised to see ClojureScript's satisfaction rate at 60%. In the past year or two it's become much easier to use NPM packages, which was IMO the last remaining huge missing piece. It's now a great language for web development, providing what JS couldn't: a rich standard library with, ahem, consistent API's, a strong FP flair with excellent immutable data structures built in, and maybe most critically of all, a somewhat constrained macro system that allows users to write and distribute third-party libraries for syntax that in other languages would have required an extension of the language standard.
All of that is (I think) desirable by anyone unless you're hardcore anti-FP (with the one exception, I guess, that macros can be and are abused, though I haven't seen it very often in the CLJS ecosystem). So why hasn't ClojureScript seen more adoption? It's the age-old curse of Lisp, I guess: those dang old parentheses which decades of CS curricula taught in ALGOL descendents have rendered foreign and horrifying.
BTW Sacha, thanks so much for Discover Meteor, it was what I cut my web dev teeth on! Somehow I hadn't heard about Vulcan until now. It looks really interesting and I'll be looking into it more.
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; in exchange, you get exploding build times because of the uglification library, and something that you know is nothing more than a nodejs app under the hood, but with just enough special sauce mixed in that you don't want to look under the hood, hoping the vendor that's reduced the dev staff to 1 will keep in good shape.
It's a missed opportunity, but the mistake was the Meteor Development Group's in betting on the JS community being satisfied with an "opinionated curation of the stack". The JS community has the attention span of rabid squirrel, and this was obvious back in the 0.8 days. They were never going to love a single bundle of choices for long.
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?
It's on Meteor 1.6 now, and you'd be mistaken about "much changes". Blaze to React was a nearly a rewrite; Atmosphere packages to npm was a significant change for the internal dependencies we developed; removing the custom file loader itself that preceded Atmosphere packages meant touching every single file.
The original code might have still worked, but the code would be helplessly outdated and stuck on a dying platform's technologies. As it is, though, the extensive and continuing effort to update the code means that now, we have a React/node app with an idiosyncratic webchannel connection to Mongo and a
build process that's outdated but manageable, and still under active development of new features.
I credit the Meteor Development Group with recognizing that the stack they wanted to lock people in on, wasn't going to work (Blaze, Atmosphere, Mongo) and providing a paced transition off those pieces early on. But if we hadn't kept pace, we'd have a half million LOC app that would be termed "legacy".
But if you had picked any other tool from 2014, you'd probably also be stuck with a legacy code base now, without any clear transition path except a big bang rewrite. You would have probably picked angularjs or backbone back in 2014 and a switch to react would have been even more trouble. Meteor allows you to mix blaze & react, mix atmosphere & npm packages, mix their old module systems with commonjs and ES6 modules.
We made the same transition, but just replacing one package/ui part at a time when it suited us, so we always kept releasing new features each sprint while gradually modernizing our code base.
True: we'd have faced the same transition with any other stack. In hindsight, Meteor wasn't a bad choice, it just didn't live up to its promise of sidestepping churn and offering an opinionated stack that would endure. I don't know that any did.
That's my point. Other people had to rewrite their software for new build tools, while our Meteor app started 5 years ago never needed any big changes, while we could gradually adopt ES6+ features, modules, dynamic imports, ...
I don't think it's deserved. If you don't need the kind of reactive queries Meteor offers (and IMO is still unbeaten in terms of developer productivity in case you do need them), then you can safely ignore that part. In the end Meteor is mainly a layer on top of nodejs. So you can do all your regular nodejs stuff and you can run Meteor without any of the mongo stuff these days. Then it still offers you a zero-config build tool which has been absolutely unbeaten (at least in the JS world) in terms of backwards compatibility over the years.
I think Meteor mostly suffers from not being the cool new thing anymore and being released in a period of a heavily changing JS ecosystem. I'd still pick it over any webpack config-clusterfuck project any day of the week.
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 questions and proposed answers are not shown.
3. Some measures have varying populations, so ranking them is absurd. Supposing that 2% of people use A and 80% use B, what does ranking satisfaction with A above satisfaction with B mean? Since the uncertainty is huge on the A measure, the "real" ranking is not known.
4. Having to click in order to switch the measure shown is strange. The three measures should be display on three consecutive graphs.
5. The Categories graph is unreadable for a slightly color-blind like me.
6. The Categories segments aggregate data over 2 levels which makes them unreadable. First levels: Used, Heard, Unheard. Second levels should be computed relatively to their containers. Who cares if 1.8 % of users would not use Elm again? What is important is that ~28% (1.8/(4.7+1.8)) of those who used Elm would prefer not to do so again.
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.
Wow, 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 — and
all the things that depend on it — should be as simple as
this:
count += 1;
That's super exciting to me, as it puts the emphasis back on solving the task at hand and instead of framework nuances around state management. Will definitely be keeping my eyes on it.
Svelte seems promising. I think it's a natural evolution from what I think is an over focus on FP and purity in React, to a more natural and intuitive DX without significant drawbacks.
Svelte does have an irritating wart IMO, citing their tutorial:
Because Svelte's reactivity is triggered by assignments, using array
methods like push and splice won't automatically cause updates.
So for reference types that are mutated in place you need to do something like:
This looks like a leaky abstraction to me since it forces the developer to work according to the implementation details. Don't know how easy it would be to fix this.
Since Svelte is a compiler I was thinking they could wrap the exported variables in an observable of some sort and make any method call on the reference variable trigger a value update behind the scenes. I have now idea how costly/complex that would be though.
Also, maybe it's a conscious choice and they want to make any data update explicit with reassignment.
I'm a huge fan of persistent data structures such as those implemented by immutable.js. The "normal" way that I would update an immutable.js List is just:
numbers = numbers.push(numbers.length + 1);
Maybe it's just a coincidence, but Svelte seems awfully congruent with the pure FP way of doing things.
FWIW, MobX lets you mutate state in the same way. It does require you to make use of its observer/observable functions to make things reactive, but in general it works amazingly well. I strongly urge everyone to try it!
Agreed. I feel so weird seeing everyone messing around with hooks while all the time I've been using what feels to me like a much simpler better solution.
It seems like you're splitting hairs. React had a new syntax. Svelte has a new syntax too, albeit a familiar one.
You can call Svelte's syntax 'templates' if you want, but if you do, you should call JSX a 'template' syntax too. You seem to be saying templates are bad, which is fine, but a vdom and a compiler are both sufficiently different from, say, mustache templates and you seem to be favoring React for no technical reason.
> Familiarity != simplicity.
Sure. But you literally just said:
> That's what happens when you create your own template syntax...again.
Which seems to indicate you preferred familiarity.
I'm not really sure what your argument is except pointing out that you prefer React. OK.
Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity.
InfernoJS is massively faster than Svelte or Preact (the benchmark author had to do some rather convoluted re-writes of vanillaJS over the years to keep ahead) and it uses a virtual DOM, but has a few optimizations that React doesn't have or can't use due to its external API.
stdweb is the real thing to keep your eye on as it seems to show that WASM can be every fast. They still haven't gotten the vanilla benchmark up to the same speed.
React's Fibers do some cool batching behind the scenes which means that large updates (especially constant ones like animations) don't have large negative impacts on user interaction. I doubt this would be possible without a vdom or something very similar to track all changes before deciding batches and update priority.
Also, remember that vdoms have gotten a lot more efficient too. Newer ones can do things like re-use existing sub-trees or recycle vdom objects (they can also recycle the associated real DOM nodes too). Preventing all that extra garbage goes a huge way toward keeping those vdoms efficient.
As to svelte in particular, you aren't "just using an equals". It actually compiles behind the scenes into a completely different set of reactive code. This gets at my biggest issue with such frameworks. Their abstractions aren't free. I have to learn their proprietary syntax and markup. I then have to learn how their compiler works behind the scenes when its time to debug the code I wrote. When I compile a React-style component into ES7 and run it in the brower, I have to deal with webpack for imports and I have to understand that JSX is really just JS functions. Otherwise, what I wrote is what I'll see.
The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's.
Comparing average numbers in that chart, Preact is 22% faster than React, Svelte is 12.6% faster than Preact and Inferno is 14.5% faster than Svelte. (note: Preact 10.1 is out and this uses 10.0)
Vanilla JS 1.04 (5.8% faster than Inferno)
Inferno JS 1.10 (14.5% faster than Svelte)
Svelte JS 1.26 (12.6% faster than Preact)
Preact JS 1.42 (22% faster than React)
Total Size isn't that different either. That's an 11% payload difference between Inferno and Svelte and a less than 5% difference with Preact and Svelte. This isn't surprising since Preact is about 9kb unzipped (less than 4k zipped) and Inferno is about 21kb unzipped (less than 9k zipped).
Maximum memory difference between Svelte and Inferno is negligible too at only 9%. I'd argue that memory usage for any of these will be dwarfed by actual data and the DOM itself. Preact memory usage is interesting as it uses more than Inferno despite not having to diff against a vdom.
Startup time (parse to first load) is also completely unimportant with Svelte at about 1.2ms faster than Inferno, but 1ms slower than Preact (which even beats out the fastest vanillaJS version).
Inferno and Preact both have access to the wide support of the React ecosystem and tooling. Inferno is faster overall while not being particularly worse in any single area and better in others compared to Svelte.
Your total size numbers are almost entirely dominated by Bootstrap and a font, which are the same for all the tests (and not something that would be used on a site where payload size matters). Svelte's JS output, gzipped, is about 40% smaller than Preact and 65% smaller than Inferno.
Assuming those ratios hold up for larger apps, that would be one reason to consider Svelte.
With only 20-ish milliseconds to load, parse, and execute, the size difference disappears into the noise and is irrelevant. In addition, that difference definitely does NOT scale. As you add more components, the ration of component to framework becomes larger and larger as the internal wiring is used over and over again. All those things in the framework have to be re-created quite often in svelte. Even if Svelte could fit all its component changes into the same area as a React-style component (which I doubt), that extra 9 or 21kb would still disappear into irrelevance.
> I have to learn their proprietary syntax and markup.
One of Svelte's raison d'etre is to "use the language" and err on less proprietary syntax / api / markup. Of the big three (not including Svelte), Svelte uses far less proprietary syntax, boilerplate, and API coverage. It errs on using as much native JS, CSS, and HTML as possible.
React has one and only one syntactic conceit which is JSX. Truth be told, that is based on a subset of the now deprecated e4x standard.
Let's look at Svelte's special syntax going over the docs. Everything mentioned here is NOT part of either the HTML or JS spec.
* Uppercase HTML is special (I really don't understand this one as this seems like the perfect opportunity to go all-in on web components)
* Interpolation using curly braces
* magical $$props object
* custom if..else..end syntax
* multiple variants of the custom loop syntax
* custom await, promise, and handler syntax
* custom HTML escape syntax
* custom debugger syntax
* custom element directive syntax
* tons of stuff using the element directive syntax
(especially events and data binding)
* 4 non-standard pseudo-DOM events
* magical <slot> (lowercase) HTML element
* magical <svelte> (lowercase) HTML element
* magical $: syntax for binding updates
That's a ton of magic and doesn't include all the magical code generated to wire everything together. That wouldn't be important except that you can't really avoid it. In React, I can just step over library calls, but since there's no Svelte library, I have to step through the spaghetti it creates from my code (spaghetti because efficient machine-generated code is always spaghetti).
The biennial JS framework migration makes me glad to be in ClojureScript world, where it's a little more static (in a good way). Well, perhaps thats a function of its smaller developer base. ClojureScript + Re-frame + GraphQL subscriptions (Hasura) is the most fun combination I've used in a while. I hope nothing 'better' takes the CLJS market anytime soon.
I'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.
Angular ng-is ng-very ng-opinionated and requires a ton of boilerplate knowledge. It requires typescript knowledge, and I've noticed that (finally!) a lot of developers are realising that typescript actually doesn't make life easier at all.
React, on the other hand, is a very intuitive library instead of an all-encompassing framework. You can easily setup a React application in a few seconds and get started, adding whatever you want as you go.
The JSX syntax is infinitely more intuitive compared to the Angular way of doing things. Which also gets me to the point of Angular having a specific way of doing things, "the Angular way".
With React there's less thinking required to get things done. The learning curve is steep (as in: you pick up the knowledge quicker) because the amount of information to take in is relatively low.
Angular takes months to master. It's very opinionated. And it requires typescript.
I for one hate typescript with the passion of a thousand suns. I know it very well because I have to if I want to keep my job, but it's so freaking unnecessary...
Just the other day I had a look at a friend's customer Angular project. My eyes! I knew Angular from past experiences, but once again it stuck out to me that Angular devs tastelessly found it necessary to equip HTML with additional meta-syntax such as parens and asterisk as part of attribute names. Now I can get that some people dislike markup languages (SGML/XML), but going in there and invent a whole new syntax on top when SGML already has plenty (arguably even too much already, to the point that W3C found it necessary to invent the XML subset of SGML) just tells me Angular is made by people full of Java-ish MVC world-views but complete lack of awareness of prior art and established practices in the field. A similar thing is happening with HypeScript: bending a weakly-typed language to fit an outdated and obsolete OOP mindset when JavaScript has eg closures for modularizing event handling.
I probably wouldn't go around discrediting a large group of extremely knowledgeable devs with extensive experience. My opinion is generally, if I see something a ton of people have spent countless hours building and I think it's stupid, I should atleast think about why.
Angular uses parens to bind to existing element classes, so if you use an html element, and it has a src field, you want to pass a string just do the normal src="string" you want to pass something from javascript [src]="variable". Boom, you just learned the biggest part of angular template syntax, congrats. This allows for using any existing element, or newly developed elements, web components, without worry about clashing, (jsx class...).
I do agree they went a little to heavy with OOP thinking, it's a weird balance between the functional reactive pushed by rxjs, and a more classic OOP line of thinking. I believe Angular will move more towards a functional way of developing as the team is coming off of the rendering refactor, ivy, and the community is working on the functional reactive component.
I have to say, although I agree that type-safety is nice, in practice having worked on many javascript apps large and small throughout the past decade, type errors have never been something that slowed me or my team down. Lately I've been questioning whether the hype around TS, and the extra layer of complexity, is really worth it. I guess it depends on the team etc, but I certainly question whether it's a good choice for new or smaller projects.
I think people underestimate how often they encounter type errors.
Anytime you try to call a property on an object that's undefined, or try to call a function that doesn't exist - those are type errors. And they're the most common JS errors we encounter.
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 of backend developers coming into the frontend. Additionally, because "everybody does it so it must be professional so I should like it".
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 execute faster in JS engines.
Types keep code maintainable, and protect against any accidentally implicit conversions (rife in JS). Types still exist whether you define them or not, so being explicit gives the maintainer of your code much less mental overhead when working with your code. Knowing the contract that a function follows allows them to skip over any assumptions and know exactly what the code is meant to do. Break the contract, get a compile time error.
Anyone can write code, writing maintainable code is the real challenge. In my own 20 years experience this is always what separates the wheat from the chaff.
> Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.
React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues.
> Run time? Variables with types that stay static execute faster in JS engines.
The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call.
As to changing variables, judicious use of `const` is the real answer here.
There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up.
I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).
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 thousands of developers that haven't seen what the hell a type even is are now somehow expected to operate on the level of creating coherent abstractions throughout the code. Good luck with that, once your team starts allowing "any" and "ts-ignore" everywhere.
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.
Getting typing correct is more nuanced than the pro-TypeScript group will ever admit, and TypeScript provides so many ways to dodge actual typing responsibility that it renders the whole exercise a colossal waste of time.
tl;dr: Good developers don't need TypeScript and bad developers pull good developers down with TypeScript.
I think I'm going to have make this my last comment as this is going in circles. I mean what is even your argument? Types exist whether you like it or not, implicitly or explicitly. You cannot get around this, it is simply a fact. When you have input parameters, or a return type, they follow a structure. That structure is a type. This is not nuance, this is just how things work.
'Good' developers is a subjective term, what is a good developer to you? Someone who can work without types? Wtf?
Anyway, I'll keep being productive with typed languages. You do you I guess.
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.
That sort of thing definitely happens, but the problem usually has very little to do with the choice of programming language. Front-end web development is the next generation's Visual Basic or PHP, the kind of software development that is easy to get into, but which as a result attracts a lot of people who have never really learned to program well. If you don't understand basic concepts like reference and value semantics, you're probably going to write bad code in any language, but you're also not particularly interesting from the point of view of what makes an effective language for a competent programmer.
> 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.
I'm totally in favor of using TS, but I agree that lazy devs can set up an absolute mess when they try to use TS without really learning it. I think probably the fundamental weakness of TS is that you really need a good understand of how it's limited to compile time type checking, and how easily you can set up situations where the actual run time types don't match what you have in TS.
For example, it feels like I'm in a constant battle with some of our front end devs about typing their models correctly... they don't seem to understand that they keep setting up the type system to lie to them. For example, if a property in our API is nullable, then the property will always be present in the json with an explicit null value, so the model should be typed `propName: string | null`... but they prefer being lazy when mocking out data on the front end, so they instead type the model as `propName?: string`. Likewise with properties that are date/times (ISO-8601 strings in the json) they love to use Date as the type for those properties, then everywhere they use that property they end up wrapping it with `new Date()` because "it doesn't work" otherwise. Yikes.
Typescript's inherent problem may well be that it's rules are too lax, it allows you to circumvent them conveniently. This keeps poisoning the code base piece by piece, leaving you with a false sense of trust.
Maybe it's because of the compatibility with Javascript but it does kill Typescript's type soundness.
> TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers.
Types slow you down a bit at the start, but speed you up forever after that. Untyped projects are fast to whip out, but slow piles of undefined behavior forever on. Oh and add unit tests, without types, and all you have is a checksum.
> And I think it's only popular because of the influx of backend developers coming into the frontend.
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.
If you don't require at least 2 approvals from medior/senior developers for your junior's PRs you're doing it wrong.
TypeScript is not a "little bit" slower, I've seen it take over 3 times more time (and frustrations, even for an experienced TS guru) to get simple things done.
TypeScript is a colossal waste of time that many sheep gladly embrace because they feel they're expected to. Nobody dares to ask "but why?" when someone else comes up with the idea of adding TS to a project. They should.
I wish I had the money to setup 2 teams of 5 developers each for 12 months. One team: JS only. The other team: TS only. Give them the exact same project instructions, same sprint length of 2 weeks, and the same expectations per sprint.
Here is my guarantee:
- The JavaScript team will get much more done consistently over the entire duration of the project;
- The JavaScript team will have a higher quality of code that is more intuitive to read;
- The TypeScript team will be the only ones that regularly fail to make deadlines;
- The TypeScript team will have to be reminded time and again that they should focus on UI and UX details.
And at the end of the road the JS team will have a far superior project, simply because they didn't waste time typing all of their code.
I've seen it so many times already. Once you use TS the devs focus on the code and forego the idea of UX, a11y, i18n, progressive web, offline capabilities, etc.
They'll often pair-program and waste hours of time to figure out how the hell they're supposed to properly type that one complicated piece of code.
Meanwhile, the JS team using React will simply use JSDoc, code reviews, propTypes, and defaultProps and be done with it.
I am reading your comments with interest. I do not find myself losing time using Typescript, quite the opposite, typing is in code documentation. And I find it much easier to read than untyped code. You say that TS dev focus more on code, maybe it is because they like to focus more on code that they use TS. I do agree you can waste time searching how to type a complicated piece of code. Meanwhile it is worth typing that piece of code if it is subject to change, or that the usage of it is not easy to understand.
I hear the frustration in your comment, and I wonder if it’s because you might not be using TS correctly.
When used right: TS infers most of your types, TS does not add to the lines of code you need to write to get something done (especially if you’re already using propTypes), and TS multiplies your productivity by reducing time spent debugging and by making refactoring super easy.
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.
Well, TS does point things out to me in the IDE that make me correct it right there. But, I would have caught that in my browser in under 2 seconds anyway. With proper .map files to debug things it's infinitely more clear what's wrong than with TS's sometimes very cryptic messages.
As for your junior dev, maybe that makes the case for TS. But honestly, I've experienced junior TS developers who were simply overwhelmed by TS. They couldn't be trusted to write proper TS since they already struggled with JS. It just required us to review more code in their PRs.
I'll take a project with naming conventions, proper unit tests & code reviews over TS any day.
Yes, it slows you down because you need to think about your domain and how that maps into types (whether you think those types exist or not, they do).
Having that opinion isn't backend bias - it's likely being exposed to a variety of programming languages and having first-hand experience with the pros/cons of static vs dynamic typing.
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:
I love Redux, I love your dedication to the community (also on Reddit), and I love your work. But this is the first time I find myself completely disagreeing with you.
The bigger a project gets, the more unreadably TS snippets you run into. The cost/benefit ratio is awful; I've sometimes taken the actual author of the code and myself to analyse it, and it would take us over an hour just to get to the bottom of something that would be incredibly simple in regular JS.
From your article:
> Ah, the joy of reviewing a PR for a lib you maintain, when the PR contains code that you are not even remotely qualified to pass judgment on...
And then that code. Look at that. That's not nice. That's terrible code, horrendous. That should be rejected for the simple reason that it's unmaintainable.
> I begged for help on Twitter, and got a solution from the community that worked. I don't even pretend to understand the type declaration, but here it is:
The problem in larger teams is exactly this:
Some self-important TS lover in your team spends 4 hours tinkering together some arcane magic TS definition by copy/pasting a ton of shit from StackOverflow, is proud that it works, commits and pushed it, creates a PR... and everyone reviewing it is clueless what's going on. But it works.
Hell, if he understands it and it works, it must be good. Accept PR. Merge. Fast forward 3 months. Someone has to add a feature to this particular part of code. They look at the TS definition and 2 weeks later they have a new job.
I've seen people flee projects because of endless amounts of arcane TS...
If I'm imagining the perfect project it's based on a few qualities that I hold dear:
1. Sensible unit testing in place
2. Well defined code review standards
3. Strict naming conventions for code
4. Optional JSDoc where it makes sense
5. Minimalistic but readable amounts of code*
* Meaning that code should be short and concise, functional programming to the max, but not one big clump of inline nested functions.
JSDoc in itself allows you to type parameters and variables, it even adds human readable comments to the mix.
Then, when reading the project's code, you'll stumble upon a beautiful and sleek code base that just makes intuitive sense from the start.
---
I recently had a chat with someone about us developers always inventing the next pain in the ass to deal with. I think TS is a pain in the ass. When I started out with Classic ASP (Visual Basic 6.0) it was basically functional programming (functions and subprocedures) and we'd get everything done in record time, blazingly fast.
If VB6.0 was released by Microsoft today, millions of people would be fawning over it and it would become the next best thing. "What a cool Python alternative, thanks Microsoft!"
Same with Perl. Cool language. Hardly anybody uses it anymore. It's mostly Booking.com recruiting endless amounts of Perl developers because they're almost as rare as the fossils they often are (I worked there, I'd know.)
When we switched to XSLT and XML it was basically Handlebars, except not restricted, full of features, and just gorgeous to work with. But it lost its sexiness for some reason; mostly because JSON isn't compatible with XSLT. So nobody uses it anymore.
Now there's JSX, and that will also disappear over time. Probably for no good reason at all. Look at Angular and VueJS, they offer alternatives that are vastly inferior in many ways (no intuitiveness would be one, you need to learn the damn frameworks before you can get started), but they're the new kids on the block.
TypeScript is too often too easily accepted as the standard addition to a project. And I've experienced it NEVER to be the right call. And I've gotten other developers on said teams to–sometimes after some prodding–agree with my assessment.
Every project would be better off without TypeScript. I fail to see any of the benefits people mention because I've never seen them, I've only seen the exact opposite.
I do think it offers benefits. I'm not a big believer that it will prevent many bugs as is often claimed from typed languages, but IDE's can help you develop much faster (when everything is in TS already) and refactorings become way easier. If that outweighs the benefits is another question. (I still prefer regular JS myself)
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.
I was an expert on JS way before TypeScript. I was kind of slow to adopt it because "the type hints are optimized away and can't even be used to boost runtime performance", but when I did start using it, I loved it and wish I had earlier.
The linked article says the vast majority love TypeScript, too.
I think the real dividing line is probably that people who haven't had to maintain a large project hate TypeScript.
(Which is still weird to me, because you can just turn off `no-implicit-any` and get all the benefits without drawbacks.)
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.
Maybe because React is small (API surface) and does (or is felt to do) “one thing”. It is easy to wrap your head around it, even without fully understanding, say, the Virtual DOM diffing. Angular is very different in that regard.
I recently had to read up on how Angular applies changes to the DOM. It was extremely difficult to get this information at all.
For me, React with TypeScript is king. It trumps Angular in three IMHO very critical points:
* Typed “templates” (a tremendous help with IntelliSense, too)
* No change detection magic (I firmly believe Zone.js is insane)
* Angular templates are typed, but until version 9 (coming out in a couple weeks, but I've been using the RCs and they've been fine), any variable created in the template itself was defined as `any`, creating gaps in the compiler's coverage. A vscode plugin provides IntelliSense.
* Agreed, this is an awful default and I don't understand why the Angular team hasn't already deprecated it. I suppose a slightly simpler "Hello World" makes Angular look a bit more approachable, but it just encourages accumulating unnecessary tech debt. The proper way to use Angular is to disable the magic (`OnPush` change detection) and use observables.
* Prod builds take a while and use a lot of memory, but local development is fine. (I haven't observed that prod builds are necessarily "slow" relative to what they accomplish.)
I like both Angular and React, but generally prefer Angular. The structure and universal consistency imposed by the framework and CLI are convenient (particularly when moving between projects or adding devs to an existing project), and the limitations imposed by Angular-HTML vs JS(X) are great for readability.
I think angular with zones will slowly start to fade away as the community moves more towards onPush components, with components hooks to trigger change detection. There is an ngrx proposal for a component that would handle this all nicely, but it's still only a proposal.
Weeeell, no(-ish). Angular templates are text. They are checked during AOT compilation or otherwise at runtime (were most type information is gone already). And maybe at some other point I don’t know about.
The Angular Language Service (which came very late) is a lot of help, if doesn’t fail to pick up component members yet again. I’m not sure whether it knows about types either.
It also has problems with some complex use cases: for example, we have a derived `CdkTable` attribute, yet it doesn’t pick up its input properties.
tl;dr: I don’t like text templates! I really like React “templates”! :D
There’s also a minor annoyance: I’m not very fond of having the components as elements in the DOM. At least with modern browsers they behave predictably!
On change detection:
While `OnPush` is required for any sane application, you really need to fully disable Zone.js unless you want your application to re-render pointlessly. That could cause problems with third-party components I guess...? Either way, it’s really not as straightforward as it should be.
In what sense do you mean that Angular templates (with the language service) more "text" than other programming languages?
Everything definitely has a type, and I'm not having any issues with syntax highlighting, mousing over things to see what they are, or peek / go to definition. There are a couple hiccups[1], but those are just tooling issues.
The template is ultimately compiled to TypeScript, which is type checked as one would expect. In my mind Angular-HTML is the same type of thing as TSX/JSX, except with the problem of being more unique / further removed from the target language, so not benefiting as much from preexisting tooling.
It's actually a minor annoyance for me right now that my existing code isn't yet compatible with the strictest compilation setting[2] because it was developed against the older, more lax compiler that littered its emitted TS with `any`s. If you're having trouble with the complex use cases (which I've definitely run into as well), Angular 9 / Ivy will be a welcome upgrade.
(And totally agreed re: Zone; it needs to die in a fire.)
---
1: 1) "Find All References" isn't working for me (I'll file a bug report if there isn't one already), and 2) I have to peek definition to see what something's type is; as-is it just says "(property)".
It surprises me too personally - the testing experience is worlds better, better built in modules than what you get in the React ecosystem (especially routing, http request layer, forms, testing, etc.), and opinionation that helps improve the overall experience of working with it. I miss my time with Angular sometimes - my only gripes is TypeScript being limiting with regard to function composition, and creating a component in Angular requires quite a bit of boilerplate compared to React.
To some degree, I feel there are a varying set of reasons why people have settled on React - some were never fans of AngularJS/Angular and some disliked how Google handled the migration story from AngularJS to Angular are probably the strongest reasons. TypeScript also not being terribly FP friendly is also a huge negative to some, whereas React enables more functional patterns overall. Some also dislike separate HTML templates vs. HTML in JS templating, some prefer to cobble together a bunch of small modules together, even if the modules are weaker on average.
Ultimately, I think Google fell short on DX with the change over to Angular 2+ and the damage has lived on since, which is a shame because as a framework it was built really solid.
I think it's the opposite. Angular1 was obviously dead on it's feet, and I respect Angular2 for admitting that. If anything I wish they had gone further and cleaned up some of the other smells around the Angular ecosystem.
My real problem with Angular is it's not great for either beginners or experts. There's so much boilerplate and Angular concepts a beginner needs to learn to use the framework well and for experienced developers that stuff tends to get in your way.
Basically this, I picked up angular 1 back in the day, for a while there was a lot of hype around it. The migration was very poorly handled and Angular 2 felt a bit alien when it was first released. React rose in popularity at exactly the right time and I think a lot of people felt a bit burnt by angular and didn't look back. Vue being released probably converted those still on the fence.
-No dynamic directives
-Nothing dynamic works with @ContentChildren, making anything that uses it the “last stop” for abstraction.
-DI system makes inheritance/mixins nearly impossible, and without dynamic directives there are situations where the only solution is a massive copy paste job.
I work in the framework every day and spend countless hours shaking my head at cryptic docs any time I try to do any type of abstraction.
I'd argue that inheritance and mixin patterns are both things you should stay away from, whether it's Angular, React, or whatever, they have proven to be poor patterns IMO and it is simple enough to create reusable abstractions without relying on those.
Code reuse is fine with Angular in my experience - it has been 2.5 years since I last used it though, as I have been working with React in that time and my frustrations about certain aspects of using React & the community has me in a the grass is greener on the other side sort of mindset from time to time, although I know things are not perfect with Angular either (I have some complaints there too).
I've basically learned to accept that using off the shelf libraries come with tradeoffs that you just have to accept as a dev.
Until you need a router or state management ect, then you've got a few tabs of docs open and a case of anlysis paralisis and a bunch of glue code to write.
> Just curious why so many people prefer React and mark it so positively.
For the exact same reasons you stated -- Angular is opinionated and has everything. React is just a framework - you get to make your own opinions and are not handed the whole ball of wax, so you can make your own choices.
When will this meme end. Angular is not crazy opinionated. The previous version more so, but it's really open to letting you do things in general ways. You want css scoped to your components? Sure. You want two way data binding? Sure, but wait you want one way binding? You go it. You can use rxjs, or you can avoid it.
There's some general ways to set things up, but it's nice to have a general approach to each project you encounter.
And the biggest thing is Angular wasn't designed to be used by a solo developer working on a side project. It's evolved to allow that, but it was designed with companies in mind. Multiple developers, multiple teams of developers, maybe with little communication to work together on single projects whilst allowing guide rails to keep things headed on the same track, but allowing many ways to move the track in a way that fits your style.
The idea that react is just a "library" (think you mixed up your words there) is absurd when you look at the majority of react in the wild. Using create-react-app, react router, forms library, animations, etc etc, and now look, you just pieced together a bunch of different libraries to form....Angular.
I stay away from angular (I don't do react either, prefer vue as long as I have a choice) mainly because of major time I invested in angular 1 and then they completely ditched it and kept the same name.
I think the comments in this thread captures it pretty well. If someone doesn't see the benefits of typed languages, TypeScript will just be something that slows them down for no apparent reason.
Same goes with RxJs, dependency injection, unit testing, and modules.
But Typescript is not a "typed language", rather a "language with types". Because of having to maintain JS compatibility it lacks the inherent type safety that other similar languages like Dart provide.
I also (as seen in at least one of your other responses) that people associate AngularJS and Angular when doing rankings in surveys like this one. There are many people who will never try Angular because of their experience with AngularJS.
Also, this isn't a scientific random sample survey, it's people who self-selected to take it. And I think that Angular specifically suffers due to that because it is more likely to be used at enterprise or large companies where devs often tend not to follow Twitter/surveys/etc at least, not in the same numbers as some other groups. Just my opinion.
Personally, I've switched from angular to vuejs after angular 2 (3, 4) came out. I found that vuejs was a better update from angular 1 than angular 2 was.
State of JS is always a fun and interesting survey, but I am wary about drawing conclusions from its results because of the self-selecting nature of the participants means they are probably not a representative sample of JS developers in general. They're inevitably going to trend towards English-speaking developers who read coding news sites, participate in social media.
Every year I glance at it, thinking maybe I will learn something about the state of JavaScript. Then I remember that it's a popularity contest and I get bored pretty quick.
I'm not sure why I should care what everyone else wants to learn. I guess it's worth finding out if there is a new popular framework this year. Sigh.
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.
I think it's just because "Mobile & Desktop" are grouped together. React Native is still number two in the list, so if they were separated out, you'd have Electron rising to the top on desktop, and React Native staying at the top on mobile.
Definitely Flutter. It's pretty easy for JS devs to work with Dart, and the Flutter architecture is basically like React - component-based (called widgets in Flutter) + RxJS (Streams and RxDart).
People are just writing native apps as far as I can tell. Swift and Kotlin are pretty pleasant to work with. React is brilliant on the web but RN is a bit of a shit show IMO.
I dream of an alternate timeline in which today we would release "State of ClojureScript 2019" with Javascript being listed as a ClojureScript flavor :)
Happy to see ClojureScript mentioned since it feels that Clojure is past the hype cycle for a long time now. But in reality what I see is Typescript getting huge. Almost every big project I stumble has Typescript definitions.
Sad to see Ionic in the avoid category. Their latest release I thought was quite polished, and I've enjoyed using Capacitor rather than Cordova. I think the key to further success is breaking away from Cordova entirely, and expanding the native features supported in Capacitor. Right now I find myself having to use both due to some things not being implemented in Capacitor yet.
At this point with React Native (or even Flutter if we're considering things apart from JS) there really isn't a compelling reason to build anything in a Webview as far as I know. Also in my personal experience their support team members have been pretty impatient and passive aggressive in the Github issues tickets so I'm not entirely surprised that they're building something that the community has moved away from.
There are a ton of compelling reasons to build apps targeting mobile web views, and despite Ionic's poor showing on this survey, we are seeing a lot of serious apps and brands doing so and picking it explicitly because of those benefits.
Perhaps the biggest is the overlap with web dev tech, team skill makeup, and the hiring market for web devs being incredibly vibrant. Vast majority of teams have struggled to go native and build/hire those teams, and are instead excited about using the web devs they already have or taking advantage of that hiring market.
One trend that is really interesting is that many teams have decided they need to be prepared for a PWA future and can't afford to have two separate efforts to accomplish that (i.e. app store apps and PWA). They see Ionic as a way to do both and be ready for the expansion of PWA adoption which is early but happening fairly organically, and has some key enterprise benefits that make it attractive for those teams.
Sorry you had a bad experience on our github issues. We're a small team relative to the size of the community and have had to resort to automation and tooling to figure out signal from noise. It's been a constant process of iteration on that front.
Not an expert, but the multiplatform story for ionic is pretty nice. One codebase to run on iOS/Android and Web is easiest with ionic and I see a lot of small-mid size businesses using it. It's usually not about top-of-their class apps though.
We’re sad to see it as well, especially because our recent releases have been so well received. I fear people formed their opinion years ago, especially with the move to Angular 2, and it’s been harder to get those people back. Oh well, we’re focused on continuing to make improvements and moving harder toward Capacitor and so far the community has been responding very well.
The other thing happening with Ionic is that our enterprise business has been doing very well. We’ve added hundreds of enterprise customers in the last two years and have really built a solid offering for medium to large businesses. We’ve also seen more and more huge apps built on the platform.
I’m guessing our focus on enterprise has also cost us a bit in this survey. Been a learning experience how to balance that and convey to folks we are both an OSS and enterprise co
And seeing angular in the “analyze” category makes me think the sample of folks responding to this survey are in a certain bubble that does not map to the broader dev ecosystem we see every day, so there’s that.
I've tried Native with a Kotlin, Flutter, and Ionic 4 with Angular and then Ionic 4 again but with Stencil. Out of all of them I'd probably gotten the farthest with Ionic 4 + Angular but I wouldn't recommend either of them.
Right now I'm trying no framework approach to make a web app with intension on using Cordova or Capacitor to hook into native Tensorflow.
EmberJS should not be in the "avoid' section.. it is one of the most well thought-out framework which just gets the job done.. and it is a bit contra-indicatory that Ember guys are the highest paid.
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 back to EmberJS. And that's why the salaries are higher for Ember developers: they're rare.
Fair enough, but I still think its a stretch to call MVC "outdated". And "outdated" kind of has a hint of "bad" and "should not be used", hence the question.
Oh yeah I also don't agree with OP. Separation of concerns is good. JSX isn't perfect either.
This yearly js poll always brings out the fanboys. The amount of "heard of it but would never try it" responses demonstrates that it's just a popularity contest
Completely agree, the framework garnered somewhat of a bad rap in the past for being "bloated", "magical", and having a high learning curve with a rigid philosophy of conventions over configuration. But fast-forward and today, ember.js is a fast, capable, full-featured, and well-supported web framework that allows building durable web applications made to last. It's used by many of the largest companies in the world including LinkedIn, Apple, Twitch, Netflix, Intercom, Princess Cruises, numerous startups and everything in-between. I highly recommend anyone with an interest to check out the coming Octane Edition which is about to land and is a significant step forward for the framework:
Agreed. Anyone who has not tried Ember should check out their getting started guide: https://guides.emberjs.com/release/getting-started/quick-sta....
Also, I highly recommend `ember-concurrency: An Ember Addon that makes it easy to write concise, robust, and beautiful asynchronous code.`
In modern Ember it is possible and even recommended to use normal functions :)
In Ember Octane with Native Classes and Decorators it is possible to use normal functions and if they need to have access to the this context of the class then they are decorated with the @action decorator.
The most interesting data in my opinion are the conflicting opinions on the overall state of the ecosystem:: https://2019.stateofjs.com/opinions/
While there is a sharp downtick of people who think that JavaScript is moving in the right directin, most agree that the overall situation in terms of complexity and velocity is getting better.
I don't have any explanation for this, but would agree: Developing in JavaScript feels easier to me than just a few years ago.
Generally have to agree there, but I do feel like there is a reason. ES6 modules (or typescript modules) and the simple fact that the variability is finally dropping:
It seems like there was one specific winner of all of the UI frameworks. React.
There is now pretty much one specific winner to package managers. Yarn.
There is one specific winner for language front-end: Typescript.
There are basically two front-end build tools left: Webpack and CRA (of which is basically a Webpack wrapper with babel and a million other things)
All of the latest npm packages are either coming with ES6 modules or, more interestingly either are completely written in Typescript or at least have @types now. And all that stuff helps people writing JS too.
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.
I've never understood that position. Hooks and redux solve completely different problems. Why would the introduction of hooks change anything about using redux?
I get Javascript fatigue, and all the criticisms aimed at the language, and while it's not totally ideal, I feel frameworks have helped tremendously by either being opinionated enough that you can do things in a predictable way (angular/vue) or are flexible enough to design complex flows and views as small, easy to reason about components (React/Redux).
I have seen some horrible stuff as an enterprise dev, from poorly constructed jQuery projects, to old frameworks like Struts/Stripes that just get out of hand. No real way to test, full of side-effects and bad choices, TONS of dependencies (outdated/unmaintained UI libraries etc). I often wonder if people complaining about JS and Frameworks have any experience developing or maintaining legacy web applications from the days of yore. Back when the web was young, there just wasn't a good blueprint for how complex web applications should be designed. We've come a long way, and for better or worse, the JS community has made improvements to the language, frameworks, etc, all of which make our jobs SO much easier.
I work with JS as a low percentage of my total work, and recently tried to bring a 2-year-old Vue-based project up to date with the latest versions of everything.
I failed in my task. With these frameworks, given enough time, there ends up being a lot of "deprecated boilerplate" code, either directly or via dependencies. E.g. Vue is closely coupled to Webpack, and Webpack deprecated so many things between versions 2 and 4, that there's essentially no mechanical way to migrate the code. One must figure out every detail of the auto-generated Webpack config from version 2 and figure out how to do the same thing in version 4. (I'm looking at you, CommonsChunk and splitchunks!)
Legacy applications from the days of yore didn't "bit-rot" like this.
Not saying that this isn't a problem, aka dependency hell. And giving some hand-wavy solution like 'well, be more careful about what packages you pull into your project' or 'well, f it, just don't upgrade your version of Vue or Webpack' is also not ideal.
There is another type of hell, where changes to modern browsers or the JS language itself cause the (long abandoned) library code that your entire application is coupled to to break completely. At that point, your only options are to tell your users they have to run the website in 'legacy-mode' in IE, or rebuild an application from scratch, teasing a decade's worth of business logic out of poorly designed code (i.e. business logic in JSP/php tags etc).
The "sharp downtick" is largely a shift from "strongly agree" to "agree". That doesn't seem too sharp to me. Mostly it seems like people are happier with where JS is now. There's less momentum behind changes the language, and fewer large developer-experience-changing features coming.
Maybe by now we're all conditioned to immediately respond with "argh it's moving too quickly" :P
But I totally agree. Things like the various cli tools, widely available documentation and good IDE support for frameworks has made JS a lot better in recent years.
I thought the interesting part was the fact the questions were strictly about JavaScript and not about the overall Browser/HTML/JavaScript ecosystem, which would probably have a stronger negativity bias I suspect.
I find it kinda strange that Flow has been relegated to the write-in "Other Flavours" section so soon. I know that it has been trending downwards for a while (as TypeScript trends upwards), but it feels like that story's not quite over just yet even if the conclusion is foregone.
Flow appears to be _effectively_ dead outside of Facebook. Or at least plateaued, at a very low peak.
For actual metrics, the NPM stats of TS vs Flow downloads [0] show TS usage skyrocketing up to >33M DL/month, while Flow has never gotten past 2.5M.
Purely anecdotally, I see numerous articles talking about projects migrating away from Flow, and absolutely nothing about actually adopting Flow at this point. Even projects like Jest, which started inside Facebook, have switched to TS to get more outside contributions. At this point, the only major project I can immediately think of that's written in Flow is (ironically) React itself.
FWIW, I wrote a blog post recently about my own experience learning and using TS as both an app dev and a Redux maintainer [1].
I started a core company project without types, than soon added Flow, then migrated to TypeScript.
I was very active, learned a lot of the intricacies and a lot of advanced typing with Flow, did lots and lots of experimenting to cover edges. I also was very active in the "issues" section of the Github-Flow repo, reading, answering and also posting issues.
I kept track of where TypeScript was though, occasionally posting issues there too. When it looked like they had feature and strictness parity, especially the latter, I switched over though. Reasons:
- Flow was on a downward path, TS on an upward path. Already nr. of developers and the ecosystem was far greater for TS.
- The Flow team was almost completely absent in the Github repo. There were some Facebook people but some of the active ones were not even from the Flow team. In contrast, the 2nd issue I wrote for TypeScript had a response from Anders Hejlsberg (TS inventor) himself, and his responses to issues can be found all over the place. Also, the Flow team's focus seemed to be almost completely supporting the internal use of Flow. It actually was a valid "open source" use case: "We write something for ourselves, here is the source in case you find it valuable.". Keyword being "ourselves", they did not care too much what other people wanted/needed unless it fit into their existing plans. TS was the complete opposite, it was written for others right from the start.
- We have a team with quite a lot of new (out of university) developers, most of them in another country (Eastern Europe) and not our own employees. Everybody but me was very reluctant to go with Flow (I had added it to the core library, they wrote apps using it, so they did not have to use it). TypeScript adoption was much easier, also for those who don't see themselves working on our projects "forever", because it clearly is a much more valuable skill then Flow in the JS-developer market.
- Strictness still was a bit more in Flow but the difference was insignificant by then.
- On the other hand, I actually removed lots of (inline) type annotations, concentrating on the types only in the function headers and when TypeScript could not auto-detect it (e.g. "new Map()" - what is the key type, what is the value type?). I followed what seemed to be the preferred TS style for type annotations. I hardly gave anything up in terms of strictness, but had far less "type stuff" in the code. Okay, this is not so much "Flow vs TS" but my own choices. In TS it's actually better to have less inline types (when auto-detection works), because while Flow - after I had filed an issue that was implemented - raises an error every time there is a discrepancy between an auto-detected type and a type annotation TS silently uses the type annotation in some contexts and does not complain when it is different from the auto-detected type. That sounds worse but if there is no type annotation it's fine, so I decided to go with it and not file an issue to ask for a change.
- Probably one of the most well-known TS advantages: Far better support, via the DefinitelyTyped repo, for types for all kinds of external libraries.
- When converting some very complicated "dynamic" types from Flow to TS the TS version was FAR easier to write. Especially conditional types help a lot. Don't know if Flow has something like that by now, it didn't when I made the switch.
As for "why types at all" raised here:
I happily wrote JS code without them since JS was invented (even though I wasn't what today would be a full-time JS developer, that happened only the last five years, and also used all kinds of other languages). Especially the last ten years a number of large corporate projects too.
I switched to types because, as somebody wrote here, types are there anyway, whether I annotate them or not. All input and all return values have a type even if I write plain JS.
----
Just an aside: I chose Flow at first because of - at the time - greater strictness, but mostly because it was plain JS plus JS types. TypeScript sounded like it was its own language. IT IS NOT! It took a while until I actually checked what it really is - the self-marketing is really bad in this respect. Unfortunately they bundle the "Babel" ("compilation", code transformation) aspect and the types, even though they are completely orthogonal. Apart from (unnecessary) namespaces and enums, both old features for which different pure JS (or TS-type) options exist now, TypeScript actually is 100% pure ESnext. If you strip all the type annotations and don't rewrite anything you are left with pure ECMAScript. Until they added namespace support the Babel plugin for TypeScript was very small and all it did was the same as the Babel Flow plugin: Just strip all the type stuff. No code rewriting took place. That's why until recently namespaces and enums where not supported by the Babel plugin, but those are features one can easily live without (Note: pure TS type namespaces in declaration files and as part of the types, and not of the JS code, can of course be used; I'm talking about the namespaces that are in "JS code space").
----
The great benefits of TS (first of Flow) for us:
- IDE live coding help and support. If I see some function, and I encounter this a lot in 3rd party code, I often have to go to the source code to see what it#s actually doing with those parameters to understand what I have to pass in.
- "Tracks" for other developers that reign in their fantasy and creativity. The types force them to stay on track with how they use some API functions of the library. That's even more important with new people. Of course, if the project is not too big and the same people have been working on it since the beginning, and very few team changes, then it matters less.
Maybe I'm misreading the numbers but ISTM that Flow, Coffeescript, and Dart could have moved up to the main list and the things they outnumber like Purescript could have moved down to the others? I guess when one sets up a survey one can set it up however one wants.
There was absolutely nothing like react at the time it came out, angular had none of its key features.
Today we have Vue and others are forming in other languages, but still today angular takes a very different approach to the front end. But react’s breakthrough in the virtual dom management was totally new and really changed a lot of things in our industry.
Redux has the largest shift towards "negative opinion" out of all technologies. Did people just get fed up with the boilerplate or is there something else going on?
Redux is a bit like Java: it's possible to write well-designed software with it, but it's also gotten a reputation for being used by the sort of programmers who blindly apply "best practices" and create nine layers of AbstractFactoryGeneratorBeans for everything.
I suspect one factor in this is that if you know enough to apply Redux's patterns well, you probably also know enough to implement them yourself without bringing in a third-party NPM package. (Of course, not everyone will choose to do this --- maybe you like the Redux debugger UI or something --- but I think enough people do that it lowers the perceived average quality of codebases that do use Redux.) The library just doesn't do anything difficult in the way that, say, React's virtual-DOM diffing and reconciliation algorithms are difficult.
We were tasked with bringing an Angular/NgRx application up to date at work, and it was quite out of date. As the only person on the team with prior NgRx experience (it was quite minor though), I was volunteered to take responsibility for that portion of the project.
I quickly learned the previous devs had no idea what they were doing. They used the libraries but appeared to have no conception of what the actual pattern was, and so were getting essentially zero of the benefits.
I tried to make some piecemeal refactors, but I gave up on that approach. Everything was too tangled together, too reliant on other portions of the system, that I had no choice but to completely rewrite all aspects of the state management system.
It took me over a month, and I came away with a diminished opinion of NgRx. I think without context, it's good (but oh my, the boilerplate; I used to pooh-pooh people who complained about it but after thousands and thousands of lines of it, I have now joined their ranks). The problem is that ...
(a) it is likely significantly different than anything a standard team has used before, and highly complex;
(b) it provides ample footguns -- following the pattern is just as important as using the libraries, and this requires self-control that some don't have (not to mention actual knowledge of the pattern),
(c) therefore there seems to be a high likelihood of inexperienced teams building complex state management systems that don't provide any of the guarantees you want from NgRx and which become impossible to maintain.
I'm a data point of one, but that's been my experience with the Redux pattern/NgRx at work.
I was in a similar situation, and ultimately decided to reimplement the state management using NGXS. Fortunately the app was relatively small at that point, but I found that it held the developers hands a bit more, which lead to significantly more readable code.
Things can still get tangled up once you start using "ofActionDispatched" lifecycle handlers, but overall I found them to be far more manageable over time than NGXS.
I started to realize that it just doesn't make a lot of sense. It doesn't actually have a real concept of how to deal with asynchronous things (like, http requests). You have to use weird things like redux-thunk, or god forbid redux-saga.
The event system is basically synchronous, and just changes data which will be displayed in the UI. Why use the event abstraction and all the boilerplate that entails for synchronous code which doesn't really benefit from events? It feels like a cargo cult.
What it boils down to is any function which will at some point change the UI needs to be written weird, so that it takes the "dispatch" function and calls "dispatch(nextFunctionEvent)" instead of "nextFunction()".
Lots of developers always implemented their own half-ass systems to eliminate some boilerplate by automatically defining events from handlers and state or vice versa or some other combination of the above.
React hooks have basically eliminated it's niche, and none to soon!
Oh, please. The projects I've recently worked on used only Hooks instead of Redux. It was a nightmare to deal with. Files with endless amounts of `useSomething`, you'd need to dive through 4 levels of files to get to something useful.
Redux offers a ton of tooling and developer comfort if you get it right. And getting it right means having proper pull request reviews.
There's a lot of developer tooling (debugging tools), too, and a lot of middleware available to plug and play and GO.
If you're just using Hooks and the Reducer and Context APIs you're setting yourself up for a lot of headaches down the road.
Redux already makes use of those technologies, but wraps it in something easy to consume with a LARGE community for support.
Not using Redux is setting yourself up for failure, in my opinion. I've seen it happen too many times in the past year...
Thunks are hardly "weird". The thunk middleware is only about 12 lines long, and it's just a way to let you write arbitrary code that has access to `dispatch` and `getState` without being tied to a specific store instance.
Thunks are our recommended standard way to write async logic in Redux apps [0], and our new official Redux Toolkit package [1] automatically sets up thunks by default as part of the store configuration.
Sagas are incredibly powerful, but most apps don't need them [2]. They're most useful when you need complex "background thread"-like behavior.
And no, Redux is definitely _not_ eliminated or replaced by hooks [3] [4].
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 Hooks APIs, MobX, GraphQL / Apollo Client, etc. These don't completely replace Redux, but they do overlap enough that there's not as much _need_ to choose Redux for everything.
- And, frankly, Redux _has_ been overused in a number of cases. Folks assume you _have_ to use Redux with React, sometimes because a senior dev told them so, because they saw yet another tutorial that pairs them together, or because it was asked for in a job listing.
Now, Redux is definitely not dead or dying. My own estimates are that around 50% of React apps are using Redux, and the overall total download trends are still increasing. But, it's also true that the market share will continue to spread out a bit over time.
I talked about these aspects in my Reactathon 2019 talk on "The State of Redux" [0] and my post "Redux - Not Dead Yet!" [1].
Besides all that, we're doing a lot of work to make it easier for folks to learn and use Redux.
- We have a new official Redux Toolkit package [2] [3]. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. It's now our recommended approach for writing Redux logic, and the feedback from folks who have adopted it has been amazingly positive.
- We are currently working on a major rewrite of the Redux core docs [4]. As part of that, we've already added a new "Style Guide" page [5] with our recommended best practices and guidelines for writing good Redux code, like structuring files as "feature folders" or "ducks", modeling actions as "events" instead of "setters", and so on. We're also going to completely redo all the tutorials and examples to show easier patterns to work with, drop outdated references to concepts and terms like "Flux" and "container components", and emphasize use of Redux Toolkit as the standard way to write Redux apps.
- Our new React-Redux hooks API [6] makes it a lot easier to work with Redux data in React components compared to the standard `connect` API, especially if you're using TypeScript.
So yeah, there are some repeated waves of annoyance with Redux that pop up on social media every so often, but there's also a ton of folks still using and learning Redux. My goal is to continue to make it easier for Redux users of all levels to use Redux.
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.
It's usage is probably being replaced with GraphQL + Apollo/Relay since the need for FE app state is reduced when you no longer need to make multiple round trip requests. Also Apollo (possibly Relay?) offer local state management too.
That would explain drop in use/popularity, but actually Redux is raising in usage, while sharply dropping in the other dimension towards "negative opinion".
Some of them look good but some of them are terribly designed. The rankings for testing graph shows storybook visually trending down when it actually increased in satisfaction.
I really don't see the point of strong typed programming. JavaScript is fine without it. I've been working with TypeScript for a while now and I never think "this solves a problem I had!"
On the contrary, I constantly think "why..."
I feel strong typing JS is just a result of backend developers not questioning their upbringings and failing to use proper naming conventions, progressive enhancement in the form of JSDOC comments, proper unit tests, and proper peer reviewing processes.
Honestly, I don't get it. In all my 20 years as a professional web developer (full stack and specialising in the frontend for the past 12 years) I have never needed it...
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 rest got past level 15.
I've been taking job applications where applicants get a limited amount of time to make their project. Let's say 20 hours, and it's a paid job. Everyone gets the same instructions.
Those who use TS are NEVER feature complete.
Coincidentally, those who use TS are also the ones who deliver one big DIV-soup and barely seem to understand CSS to begin with.
Strong typed JavaScript doesn't solve anything, in my opinion. And nobody has been able to convince me otherwise. TypeScript seems to be a reason for many developers to completely avoid documenting their code...
I mean, TSDOC or JSDOC allows you to write human-readable comments AND strong type your code where it matters. But they don't.
> At work we recently did a timed programming problem solving competition.
Thankfully, real world software development is not done under arbitrary time constraints with teams competing on who can be first to complete a prototype. High quality software is very difficult to produce, and taking the time to adopt sane development practices that reduce cognitive load and detect bugs early on in the process often leads to maintainable codebases far beyond their prototype phase.
> In any case, this article was a fun one to read:
It might be fun, but it reads like a movie review where the author gives arbitrary scores and somehow determines TypeScript's ROI based on that(?). The rest of the article mostly appeals to authority, as the author pushes his books, expertise and vast experience as proof, something you seem to be doing as well.
I feel like the mentioned "To Type or Not to Type" paper[1] is a more realistic study of the benefits of static typing, despite TS detecting "only" 15% of possible bugs. That's still 15% of bugs detected _during development_ that the programmer doesn't have to think about, and doesn't have to write thousands of very trivial tests to _maybe_ catch them locally or worse yet, in CI. This in practice never actually happens, let alone in code reviews!
Yes, static typing is not a panacea. But it's a tool that has high chances of producing higher quality software, something that is sorely needed in JS land.
Also, if you are using a statically typed language there are tools for property based testing like QuickCheck which eliminates the need to write those thousands of very trivial tests. I've seen one advertised for JavaScript but you can't guarantee it'll find everything thanks to typecasting.
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.
If you're looking at the kind of requirements that can be implemented in under an hour, of course a stronger, more static type system isn't likely to gain you much. It's highly unlikely that such a program is going to have lots of different people working on it over a period of possibly years, or that it's going to use lots of different but possibly related data structures, or that it's going to develop libraries with hundreds or thousands of little utility functions for working with those data structures.
However, drawing conclusions about the merits of a stronger, more static type system based on this sort of challenge is like arguing that a language where all code has to be in defined modules and functions is much less efficient than a scripting language like Python because in the latter you can write a "Hello, world!" program in literally one line.
Strongly typed programs tend to have less bugs. There's been a few systematic surveys of large open-source projects looking at the number of issues raised/bugs found and they all show the same results.
I recently joined a company that uses formal methods and Haskell for a globally distributed system and I can't imagine going back to JavaScript for something similar. Being able to reason about a system is important and it's almost impossible to reason about non-statically typed systems.
I don't seen how problem solving competitions are any measure of worth for a language. That's like saying, teams that wrote tests didn't complete as many of the problems, so we shouldn't write tests. What about maintainability, ease of refactoring, catching of bugs during compliation time etc. There are tradeoffs to everything, you just have to decide what matters most to you.
> 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.
Sounds like you just don't know how to cast a type for your specific case rather than a TS bug, which is fair to say as sometimes you need decent time to learn how to do it.
Suppose you're using an editor that actually gives you clever warning if types don't match?
Using plain vim with typescript makes no sense.
It gives me plenty of useful checks using TS. Lack of members, wrong types returned, missing return in switch statement etc.
Saying JS works for you fine sounds like "I have (or waste) good amount of brain memory on my program, so I don't need any further checking.", which can't be the case on code other people wrote.
TS is definitely oversold. I like the typed function signatures, a little bit better autocompletion and some refactor support. Personally I also think typing can be fun. But it doesn't increase safety or productivity, and it comes with costs: build setup, having to import type, libs that have misleading types, having to cast when TS doesn't get it, etc.
How do 3.6% of respondents have more than 20 years of experience in TypeScript? And 21.7% have more than 10 years?
EDIT - They don't. They have 10+ years using JavaScript
TypeScript was released in 2012, sure there are early adopters and beta users, but I seriously doubt that nearly 22% of the people using TypeScript prior to it being released.
I believe the question you are referring to is asking what general level of experience TypeScript developers have. I too was a bit taken aback when I saw that. I had to reread the question. They should have done a better job making that clear in the chart for people just skimming the data.
https://2019.stateofjs.com/javascript-flavors/#javascript_fl...
Either they are padding themselves on an anonymous survey for that sweet sweet ego validation or they have gaslighted their own experiences. Makes me pretty incredulous at the quality of this sample.
It could also be some prick who converts 80 hour weeks into years of experience x2.
I've rarely seen a technology so eagerly embraced by both bleeding edge tech enthusiasts and also enterprise behemoths (granted, tech behemoths, but still)
Having API documentation that is guaranteed not to go out of date with your code. Having a shared standard for describing your endpoints in a machine-consumable way. Being able to automatically generate typescript types from any schema (correct me if I'm wrong but I don't think there's any tooling that would do the same for arbitrary REST APIs). Being able to get autocompletion when writing queries for free ^ Those were all things I didn't know I needed until I started using them, and like Typescript, it feels painful to go back to not having them
You can write Swagger definitions to serve as contracts for your REST API. Swagger files are machine consumable and can be used to generate client SDK.
Charts in this report are very misleading.
In some cases 6% difference is 2 times bigger on chart than 5% difference.
I’m aware they have no scale, are simplified etc, but chart format has very specific meaning and I believe that visualisations could be chosen in a better way.
I also noticed that on the Front End Frameworks awareness chart where react and angular flipped places from second to first even though they are both at 100% and then I saw that the vuejs was in 3rd place although it was also at 100%
Something that jumps out to me in the demographics is how few respondents are from Japan (0.6% vs e.g. 5.1% from Germany). Does anyone have a good explanation?
The Asian markets typically have their own news letters. They will report the findings from the State of JavaScript 2019 from the western world, but they'll probably have their own polls.
We are primarily English speaking (myself being European and working in the USA now) and they struggle with English immensely, in general.
Many projects from Japan that I see have faulty English grammar in variable names and is documented only in Japanese characters.
I would be more interested as to why there is so little response from different demographics in the first place, even in Europe there’s little response, except for a few countries.
It seems to me they mostly targeted English speaking countries, which would explain why Japan (and Asia in general) has such low response.
Except they excluded the country with the highest English language proficiency on the continent of Europe, the Netherlands. I suspect there’s another reason.
(Survey author) The Netherlands doesn't have a large population, so it's never going to show up as a large part of the results. For next time it would be interesting to also let you toggle a relative view of participation vs population though.
It’s a small country but with nearly half the population of Spain, and the most densely populated country in the world outside of Taiwan. Not to mention a massive development community (and one of the largest internet infrastructures in the world). So, more relevant than you’d think :)
Taiwan and The Netherlands are not even close to being the most densely populated countries in the world. Taiwan is 652/km² and Netherlands is 418/km². Compare that to Macau 20,286/km² or Singapore at 7,804/km².
But I agree that The Netherlands has a pretty big development community, and generally their English is fairly close to being native.
That’s interesting, I’ve never done the math myself but I’ve seen it mentioned in many places that those are the two most densely populated countries in the world. Maybe they are only looking at the density in urban areas and excluding agricultural areas?
They were probably excluding city-states like Singapore and Vatican City (Macau is probably excluded because it is neither in theory nor in function a country, but is a special administrative region of China.) Or setting a minimum size or population threshold that has a similar exclusive effect.
Oh, I see now that the stats I frequently hear cited exclude small city-states, and have a smallish threshold of somewhere in the 10 to 20,000,000 range for the country population.
This is incredibly true. Testing libraries have not kept up with changes to JavaScript and web dev in general.
I long for a test runner that does as little magic as possible, doesn't try to be a build system and module loader, doesn't inject random libraries into the environment, it just loads URLs and reports back test results.
Test runners and assert libraries can massively slim down too if they because simple importable modules and don't modify the global environment or create plug-in systems or complex test lifecycles. Tests are async functions that resolve or reject, that's it.
I’ve used TAP and nodeTAP and always ran in to some problems. Then I gave AVA a try. Makes a pretty decent impression, though I have never used it in production.
It’s simple enough, fast, and I have yet to run head-first in to some problem.
Jest with Enzyme/react-testing-library seems to be consolidating things in the way React did for frameworks. It's batteries included, and everything "Just Works".
> What do you use Python for? 37% programming web parsers / scrapers / crawlers
I had no idea that much people were scraping the web. What are the most common applications? Users data collection, prices comparison, news aggregation...?
No, because these languages aren't broken and don't need a new ECMAscript standard every year (none of which can fix JS anyway because it's fundamentally wrong and unfixable). Other languages don't have a bunch of busybodies adding useless features to a broken language without any hope that all browsers ever will fully support it.
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.
i'm conflicted about this, but happy to see typescript overtaking the space. looking forward to the day we can all forget javascript the language as a bad dream and move on with javascript the vm.
I wish “salary” wasn’t the way people were asked about pay. Everyone I know who’s over 200k only has 1xxk salary and like 100% of that in stock compensation. It’d give a different picture of what more people are making.
Even then MVC is almost always far more than needed to get the job done well... as are most frameworks.
I have noticed in the big corporate space many people writing this code are formally educated to write code in a very specific way that isn't quite JS-friendly and they need the extra boilerplate to make JS behave.
I see some of my colleagues (mostly front-end devs) don’t even know how to write code that’s not SPA + API, it’s pretty sad. It over complicates every project, and like you said, MVC in most cases is enough.
The state of Javascript in 2019 is that it should be deprecated. I have never had more problems, undefined behavior, mysterious errors and malfunctions, dependency hell and generally shitty syntax as when dealing with Javascript. God, please, just destroy this language. The web needs something different, something not broken and flawed.
Tell me about it. I have tried my darndest to use types and tests to make things predictable. But there is always something that comes up.
It might be Javascript itself. It could also be the endless permutations of environments(browsers, resolutions, devices, etc) that we have to cater to.
It would be much easier without the moving target of new Javascript features that browsers have to keep up with. With a real, mature, nonbroken language there would be no need to add new features every year. Someone said that Python is badly suited for the web because not event-oriented, whatever that means. Well, JS didn't have async/await until recently, and there's still lots of code that uses promises, yet even promises aren't supported by ancient browsers. It would have been so much easier to use a language that had ironed its sophomore mistakes somewhere on the desktop, before the web limelight. Instead, they created an all-new "web language" to ensure decades of volatility and reinventing the wheel for all the world wide web...
Thanks, I appreciate it as I go on to the third day of trying to find why Javascript cannot get the correct width of an image but only under some circumstances unconnected to the JS code.
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 consistently. I know many people that can build a front end, myself included but are nowhere near mastering anything, especially animations and css transitions.
I write this in jest of course. As we all know, self-assessment is about as reliable as...