State of JavaScript 2019
2019.stateofjs.com
2019.stateofjs.com
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...
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.
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.
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.
"Expert: Being able to style an entire front-end from scratch following a consistent methodology"
Meanwhile, "Advanced: Mastering animations, interactions, transitions, etc."
I can certainly "style an entire front-end from scratch" without "mastering animations".
CSS architecture (for a lack of a better term) is completely different from its more playful aspects. Stacking on on top of the other is just silly.
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.
I miss being able to focus for just 2 hours on a task that would then give me a clear view on how well I knew the important mental models of a topic.
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.
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.
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."
Ok, I'll bite: can you explain that little more please?
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.
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.
So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.
Why then is it important to think of "branch" as referring to one rather than the other? As evidenced by the isomorphism, they're the same thing.
A branch is a separate concept, it's not even stored in the history DB but in a different dir. See it as a label attached to a commit, since a commit can have several branches attached to it, or none. A branch will be moved across the history, while a commit will keep his place in the history.
A branch is designed to be easily created, deleted, and moved around, freely, from anywhere to anywhere.
A commit is designed to feel immutable, and unmovable, and although this is not strictly true, this is how you will mostly use it.
A chain of commits is like a rail track, it goes in one direction, each commit composing it never changing (again, conceptually), and never moving. You stack commits, you grow the track, piece by piece.
The branch is more like a flag you put somewhere on the rail track (most often at the end), to let the workers know where to put the next piece.
Picturing it that way let you best use its properties:
- branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want.
- moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast.
- you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working.
- deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink.
- this branch is so good it should be master? Sure you can. Just swap the labels. But let everyone knows :)
Etc.
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?
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.
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.
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.
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.
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.
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.
Wikipedia puts it well:
> 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.
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.
Your question is essentially a proxy for server-side architectures and applications, not nodejs itself. It 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.
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)
Asking them to self rate themselves is useless however, as their answer showed.
That's how I interpreted the comment and I'm pretty confident that's correct.
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).
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.
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?
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.
I think the best CSS compatibility across the board was during the time of ACID series tests, and has declined since.
"You have selectors and styles, and I can just can look them up, so I guess I know all there is to know about it."
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.
On the 60% line
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.
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.
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".
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.
Build tools wise, a simple Webpack/Babel config from 2014 would be relatively straightforward to update to the latest versions.
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.
Hard to get over the initial assumption that dark red means negative, and bright happy blue means positive.
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;
If you know React, look at the "Ten minute introduction to MobX and React" to see if it's for you. https://mobx.js.org/getting-started.html
- Simpler. You change values with `=` not some method call.
- Faster, as the svelte compiler dynamically creates bindings at build time, vs a virtual DOM that has to dynamically track binding at run time
- Smaller, since Svelte's output doesn't include Svelte.
Then there's the missing Typescript support...
That's what happens when you create your own template syntax...again.
I'll continue to use React so I can simply use Typescript for my components, not some random syntax.
My styles are typed, my components are typed, my state is typed. Why would I ever go back?
> I'll continue to use React
React also created it's own syntax. Svelte's syntax looks more similar to preceding work than React's syntax did.
Templates are 5 steps backwards, Svelte overall is a leap backwards.
Familiarity != simplicity.
The only thing I'd use Svelte for is for simple websites, but oh no you can't because it requires JS...
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.
JSX is simply a way to write JavaScript that looks like HTML.
I know when I develop in React there's no magic. I know JSX are just functions, everything else in the code is as is.
That's the biggest misstatement of the day. ️ We understand that you prefer React, but this is utter...
I'll continue to use the one framework that supports typing styles, components, and state.
I'll continue to use the one framework that can bridge to every major desktop and mobile OS's native UI.
I'll continue to use the one framework backed by both Facebook and Microsoft.
I'll continue to use simple JS functions to build every part of my app.
You can use Svelte, lol.
Oh and don't use "we", you're one person.
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.
https://stefankrause.net/js-frameworks-benchmark8/table.html
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.
https://cdnjs.cloudflare.com/ajax/libs/preact/8.5.2/preact.m...
> 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.
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 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.
https://krausest.github.io/js-framework-benchmark/current.ht...
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)
Vanilla JS 144kb
Inferno JS 163kb
Svelte JS 146kb
Preact JS 153kb
Vanilla JS 3.3mb
Inferno JS 4.8mb
Svelte JS 4.4mb
Preact JS 7.5mb
Vanilla JS 20.3ms
Inferno JS 21.6ms
Svelte JS 20.4ms
Preact JS 19.4ms
Vanilla JS 1882ms
Inferno JS 2033ms
Svelte JS 1883ms
Preact JS 2031ms
Why would I want to choose Svelte?
Assuming those ratios hold up for larger apps, that would be one reason to consider Svelte.
https://github.com/batiste/blop-language
Not sure why they claim proxies are complicated... I found it was a piece of cake to implement a working library for state management using a Proxy.
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.
numbers.push(numbers.length + 1);
numbers = numbers;
numbers = [...numbers, numbers.length + 1];
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.
numbers = this.state.numbers;
numbers.push(numbers.length + 1);
this.setState({ numbers: numbers });
Similar docs for redux: https://redux.js.org/recipes/structuring-reducers/immutable-...
There's no good way around it without doing deep equality checks everywhere which is not reasonable.
Also, maybe it's a conscious choice and they want to make any data update explicit with reassignment.
Angular, on the other hand...
You are confusing your imagination with reality (or the history of your own experience).
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...
TS shows you just how bad JS can be without very, very diligent processes to keep it in check.
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.)
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".
As for React, well, great argument, I guess?
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.
That's not the only reason why it's popular.
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.
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.
'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.
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.
Maybe it's because of the compatibility with Javascript but it does kill Typescript's type soundness.
Edit: rephrasing
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.
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.
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.
https://github.com/tc39/proposal-record-tuple
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).
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.
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.
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.
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.
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.
If you’re interested, I wrote a book about how to use TS, targeted towards intermediate/experienced JS programmers: https://www.amazon.com/Programming-TypeScript-Making-JavaScr...
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:
https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
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.
Beyond that, yeah, we'll have to disagree, per all the reasons I listed in that blog post.
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.
Rollbar aggregated the 10 most common JS errors, and virtually all of them are type errors: https://medium.com/@Iren.Korkishko/10-most-common-javascript...
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.
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.
-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.
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.
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.
Same goes with RxJs, dependency injection, unit testing, and modules.
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)
* Build time
* 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.
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.
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)".
2: https://next.angular.io/guide/template-typecheck#strict-mode
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.
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.
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.
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.
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?
Maybe people use NativeScript, I don't know. Just found it interesting that the trend seems to go down for ALL mobile development tools.
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.
Neither RN nor Flutter fulfill the promise of, "write once, run everywhere", whereas Ionic, warts and all, does today.
Maybe Flutter web will work out though, we'll see. If Dart evolves then Flutter becomes a pretty compelling stack.
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.
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.
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.
https://emberjs.com/editions/octane
https://octane-guides-preview.emberjs.com/release/getting-st...
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.
Personally I prefer anything that is restrictive, I would take the price of less flexibility for the ability to stop people doing stupid things.
What ? why ? care to elaborate please ? and what do you use instead ? MVVM ?
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
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.
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.
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.
Seems like within React, Redux/Apollo/plain is splitting the data layer again too
But the yarn/npm is a tiny difference and data layer is much more application specific
In addition, our new Redux Toolkit package [2] and React-Redux hooks API [3] are making it easier than ever to use Redux, and we've gotten a ton of very positive feedback from users who have adopted those APIs.
[0] https://blog.isquaredsoftware.com/2019/03/presentation-state...
[1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
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 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.
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).
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].
[0] https://npm-stat.com/charts.html?package=typescript&package=...
[1] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
Although perhaps I'd agree, actually. I'm not sure. It's at least not a huge deterrent.
But there are many alternatives to Flow.
Angular is 4 years older than React, and generally speaking front-end frameworks have been probably the single most competed/overcrowded area...
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.
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.
- Greatly helps refactoring and rewrites.
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!
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].
[0] https://redux.js.org/style-guide/style-guide#use-thunks-for-...
[1] https://redux-toolkit.js.org
[2] https://redux.js.org/faq/actions#what-async-middleware-shoul...
[3] https://blog.isquaredsoftware.com/2019/03/presentation-state...
[4] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
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...
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.
[0] https://blog.isquaredsoftware.com/2019/03/presentation-state...
[1] https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...
[2] https://redux-toolkit.js.org
[3] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...
[4] https://github.com/reduxjs/redux/issues/3592
Why use mobx? To write less boilerplate? To be more productive?
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.
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 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.
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...
I really don't understand the charm of it.
- "proper" naming conventions
- JSDOC comments
- unit tests
- peer review
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.
In any case, this article was a fun one to read:
https://medium.com/javascript-scene/the-typescript-tax-132ff...
It's not even about using types. Sometimes you get stuck trying to resolve Typescript issues that are not part of your core problem.
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.
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:
> https://medium.com/javascript-scene/the-typescript-tax-132ff...
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.
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.
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.
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.
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.
It could also be some prick who converts 80 hour weeks into years of experience x2.
Good to also see Typescript making a foothold - it's a great alternative to pure JS.
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
Thanks for all the memories, Atom! <3
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.
We see React go 93/93/91/89, but the 89 circle is higher than 91 and at the same level as 93?
We see Vue go 87/91/91/87, but the second 91 is at a higher level than the first and the 87 is way below the first 87.
It seems like the React line should be straight, then dip down a little bit, then dip down a little bit more.
The vue line should go up a bit, then be straight, then dip back down to the original position.
It seems to me they mostly targeted English speaking countries, which would explain why Japan (and Asia in general) has such low response.
But I agree that The Netherlands has a pretty big development community, and generally their English is fairly close to being native.
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 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.
It’s simple enough, fast, and I have yet to run head-first in to some problem.
• Go 2018 — https://blog.golang.org/survey2018-results
• Go 2017 — https://blog.golang.org/survey2017-results
• Go 2016 — https://blog.golang.org/survey2016-results
• Rust 2018 — https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
• Rust 2017 — https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Resul...
• C++ Global Insights 2019 — https://isocpp.org/files/papers/CppDevSurvey-2019-04-summary...
• C++ Global Insights 2018 — https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary...
• StackOverflow Insights 2019 — https://insights.stackoverflow.com/survey/2019
• StackOverflow Insights 2018 — https://insights.stackoverflow.com/survey/2018
• StackOverflow Insights 2017 — https://insights.stackoverflow.com/survey/2017
• StackOverflow Insights 2016 — https://insights.stackoverflow.com/survey/2016
• StackOverflow Insights 2015 — https://insights.stackoverflow.com/survey/2015
• IntelliJ, Dev Ecosystem (All) — https://www.jetbrains.com/lp/devecosystem-2019/
• IntelliJ, Dev Ecosystem (Java) — https://www.jetbrains.com/lp/devecosystem-2019/java/
• IntelliJ, Dev Ecosystem (C) — https://www.jetbrains.com/lp/devecosystem-2019/c/
• IntelliJ, Dev Ecosystem (C++) — https://www.jetbrains.com/lp/devecosystem-2019/cpp/
• IntelliJ, Dev Ecosystem (C#) — https://www.jetbrains.com/lp/devecosystem-2019/csharp/
• IntelliJ, Dev Ecosystem (Go) — https://www.jetbrains.com/lp/devecosystem-2019/go/
• IntelliJ, Dev Ecosystem (Javascript) — https://www.jetbrains.com/lp/devecosystem-2019/javascript/
• IntelliJ, Dev Ecosystem (Kotlin) — https://www.jetbrains.com/lp/devecosystem-2019/kotlin/
• IntelliJ, Dev Ecosystem (PHP) — https://www.jetbrains.com/lp/devecosystem-2019/php/
• IntelliJ, Dev Ecosystem (Python) — https://www.jetbrains.com/lp/devecosystem-2019/python/
• IntelliJ, Dev Ecosystem (Ruby) — https://www.jetbrains.com/lp/devecosystem-2019/ruby/
• IntelliJ, Dev Ecosystem (Rust) — https://www.jetbrains.com/lp/devecosystem-2019/rust/
• IntelliJ, Dev Ecosystem (Scala) — https://www.jetbrains.com/lp/devecosystem-2019/scala/
• IntelliJ, Dev Ecosystem (Swift & Objective-C) — https://www.jetbrains.com/lp/devecosystem-2019/swift-objc/
I had no idea that much people were scraping the web. What are the most common applications? Users data collection, prices comparison, news aggregation...?
- GraphQL
- Jest
Not much useful there for someone who just, you know, plods along with mere vanilla javascript.
And when I flipped to 'inverse' (because of the blinding white) ... there went the color scheme.
Strongly agree: 7.3%
Agree: 16.9%
How?
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.
It might be Javascript itself. It could also be the endless permutations of environments(browsers, resolutions, devices, etc) that we have to cater to.
Front End Web Development is hard.