Angular ng-is ng-very ng-opinionated and requires a ton of boilerplate knowledge. It requires typescript knowledge, and I've noticed that (finally!) a lot of developers are realising that typescript actually doesn't make life easier at all.
React, on the other hand, is a very intuitive library instead of an all-encompassing framework. You can easily setup a React application in a few seconds and get started, adding whatever you want as you go.
The JSX syntax is infinitely more intuitive compared to the Angular way of doing things. Which also gets me to the point of Angular having a specific way of doing things, "the Angular way".
With React there's less thinking required to get things done. The learning curve is steep (as in: you pick up the knowledge quicker) because the amount of information to take in is relatively low.
Angular takes months to master. It's very opinionated. And it requires typescript.
I for one hate typescript with the passion of a thousand suns. I know it very well because I have to if I want to keep my job, but it's so freaking unnecessary...
Just the other day I had a look at a friend's customer Angular project. My eyes! I knew Angular from past experiences, but once again it stuck out to me that Angular devs tastelessly found it necessary to equip HTML with additional meta-syntax such as parens and asterisk as part of attribute names. Now I can get that some people dislike markup languages (SGML/XML), but going in there and invent a whole new syntax on top when SGML already has plenty (arguably even too much already, to the point that W3C found it necessary to invent the XML subset of SGML) just tells me Angular is made by people full of Java-ish MVC world-views but complete lack of awareness of prior art and established practices in the field. A similar thing is happening with HypeScript: bending a weakly-typed language to fit an outdated and obsolete OOP mindset when JavaScript has eg closures for modularizing event handling.
I probably wouldn't go around discrediting a large group of extremely knowledgeable devs with extensive experience. My opinion is generally, if I see something a ton of people have spent countless hours building and I think it's stupid, I should atleast think about why.
Angular uses parens to bind to existing element classes, so if you use an html element, and it has a src field, you want to pass a string just do the normal src="string" you want to pass something from javascript [src]="variable". Boom, you just learned the biggest part of angular template syntax, congrats. This allows for using any existing element, or newly developed elements, web components, without worry about clashing, (jsx class...).
I do agree they went a little to heavy with OOP thinking, it's a weird balance between the functional reactive pushed by rxjs, and a more classic OOP line of thinking. I believe Angular will move more towards a functional way of developing as the team is coming off of the rendering refactor, ivy, and the community is working on the functional reactive component.
I have to say, although I agree that type-safety is nice, in practice having worked on many javascript apps large and small throughout the past decade, type errors have never been something that slowed me or my team down. Lately I've been questioning whether the hype around TS, and the extra layer of complexity, is really worth it. I guess it depends on the team etc, but I certainly question whether it's a good choice for new or smaller projects.
I think people underestimate how often they encounter type errors.
Anytime you try to call a property on an object that's undefined, or try to call a function that doesn't exist - those are type errors. And they're the most common JS errors we encounter.
TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers.
My claim: TypeScript offers no benefit. Ever. That's 2 years of fulltime TS experience talking and 18 years of fulltime JavaScript experience, on top of a whole bunch of full stack (Java and .Net with C#) experience.
I think the popularity of TS is going to decline. And I think it's only popular because of the influx of backend developers coming into the frontend. Additionally, because "everybody does it so it must be professional so I should like it".
Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware.
Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.
Run time? Variables with types that stay static execute faster in JS engines.
Types keep code maintainable, and protect against any accidentally implicit conversions (rife in JS). Types still exist whether you define them or not, so being explicit gives the maintainer of your code much less mental overhead when working with your code. Knowing the contract that a function follows allows them to skip over any assumptions and know exactly what the code is meant to do. Break the contract, get a compile time error.
Anyone can write code, writing maintainable code is the real challenge. In my own 20 years experience this is always what separates the wheat from the chaff.
> Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.
React has proptypes that make contract guarantees -- ones that don't disappear at compile time. Most stuff is local to a single file. If your imports and shared objects are so poorly named and poorly understood that types become the major blocker, you have bigger issues.
> Run time? Variables with types that stay static execute faster in JS engines.
The biggest issue in JS engines is making functions monomorphic. Typescript is perfectly happy with every single function in your system being a slow, megamorphic call.
As to changing variables, judicious use of `const` is the real answer here.
There is definitely something to be said for enforcing object structure though. Adding and removing properties to an object is a significant issue. The non-type solution here is the addition of records and tuples to the system. Since they cannot be modified, the general performance will go up.
I like the idea of types, but dislike typescript. Most importantly, it is not a sound type system and the illusion of sound types is worse than dynamic types IMO. If I ever adopt a type system into my current project, it will undoubtedly be F# (fable) or ReasonML (ocaml) where I can gain sound types and better syntax without giving up the practical need for mutation (like with Elm where lots of garbage and poor interactions with JS libraries are the result).
If you think these same developers can't do it without TS, then you really haven't seen the sort of mess lesser developers make when they try with TS.
Unless the JavaScript developer has a strong background in C/C++/Java, they are going to truly fuck up a code base with TypeScript. I'm not making a static/dynamic typing argument here. I'm making an observation that thousands of developers that haven't seen what the hell a type even is are now somehow expected to operate on the level of creating coherent abstractions throughout the code. Good luck with that, once your team starts allowing "any" and "ts-ignore" everywhere.
9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary.
Getting typing correct is more nuanced than the pro-TypeScript group will ever admit, and TypeScript provides so many ways to dodge actual typing responsibility that it renders the whole exercise a colossal waste of time.
tl;dr: Good developers don't need TypeScript and bad developers pull good developers down with TypeScript.
I think I'm going to have make this my last comment as this is going in circles. I mean what is even your argument? Types exist whether you like it or not, implicitly or explicitly. You cannot get around this, it is simply a fact. When you have input parameters, or a return type, they follow a structure. That structure is a type. This is not nuance, this is just how things work.
'Good' developers is a subjective term, what is a good developer to you? Someone who can work without types? Wtf?
Anyway, I'll keep being productive with typed languages. You do you I guess.
9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary.
That sort of thing definitely happens, but the problem usually has very little to do with the choice of programming language. Front-end web development is the next generation's Visual Basic or PHP, the kind of software development that is easy to get into, but which as a result attracts a lot of people who have never really learned to program well. If you don't understand basic concepts like reference and value semantics, you're probably going to write bad code in any language, but you're also not particularly interesting from the point of view of what makes an effective language for a competent programmer.
> 9 out of 10 JS developers I have worked with do not know how equality and object memory references work in JavaScript. They do not understand deep vs. shallow equality. They are barely aware of type coercion. When faced with a TypeScript error, their primary concern is shutting up the compiler. By any means necessary.
I think the exact same problems exist with JS no? Except now there isn’t any compiler to shut up, and things just silently fail.
I'm totally in favor of using TS, but I agree that lazy devs can set up an absolute mess when they try to use TS without really learning it. I think probably the fundamental weakness of TS is that you really need a good understand of how it's limited to compile time type checking, and how easily you can set up situations where the actual run time types don't match what you have in TS.
For example, it feels like I'm in a constant battle with some of our front end devs about typing their models correctly... they don't seem to understand that they keep setting up the type system to lie to them. For example, if a property in our API is nullable, then the property will always be present in the json with an explicit null value, so the model should be typed `propName: string | null`... but they prefer being lazy when mocking out data on the front end, so they instead type the model as `propName?: string`. Likewise with properties that are date/times (ISO-8601 strings in the json) they love to use Date as the type for those properties, then everywhere they use that property they end up wrapping it with `new Date()` because "it doesn't work" otherwise. Yikes.
Typescript's inherent problem may well be that it's rules are too lax, it allows you to circumvent them conveniently. This keeps poisoning the code base piece by piece, leaving you with a false sense of trust.
Maybe it's because of the compatibility with Javascript but it does kill Typescript's type soundness.
> TypeScript slows down a project. Nobody seems to ever point out what benefits it supposedly offers.
Types slow you down a bit at the start, but speed you up forever after that. Untyped projects are fast to whip out, but slow piles of undefined behavior forever on. Oh and add unit tests, without types, and all you have is a checksum.
> And I think it's only popular because of the influx of backend developers coming into the frontend.
Benefit? When my friendly junior developers add a variable where it isn’t supposed to go the system yells at them.
This is much preferable to me yelling at them, or production getting broken.
Typescript may be a little bit slower if you never make any mistakes ever, and can keep the full state of your program in your mind at a given time. Nobody makes no mistakes.
If you don't require at least 2 approvals from medior/senior developers for your junior's PRs you're doing it wrong.
TypeScript is not a "little bit" slower, I've seen it take over 3 times more time (and frustrations, even for an experienced TS guru) to get simple things done.
TypeScript is a colossal waste of time that many sheep gladly embrace because they feel they're expected to. Nobody dares to ask "but why?" when someone else comes up with the idea of adding TS to a project. They should.
I wish I had the money to setup 2 teams of 5 developers each for 12 months. One team: JS only. The other team: TS only. Give them the exact same project instructions, same sprint length of 2 weeks, and the same expectations per sprint.
Here is my guarantee:
- The JavaScript team will get much more done consistently over the entire duration of the project;
- The JavaScript team will have a higher quality of code that is more intuitive to read;
- The TypeScript team will be the only ones that regularly fail to make deadlines;
- The TypeScript team will have to be reminded time and again that they should focus on UI and UX details.
And at the end of the road the JS team will have a far superior project, simply because they didn't waste time typing all of their code.
I've seen it so many times already. Once you use TS the devs focus on the code and forego the idea of UX, a11y, i18n, progressive web, offline capabilities, etc.
They'll often pair-program and waste hours of time to figure out how the hell they're supposed to properly type that one complicated piece of code.
Meanwhile, the JS team using React will simply use JSDoc, code reviews, propTypes, and defaultProps and be done with it.
I am reading your comments with interest. I do not find myself losing time using Typescript, quite the opposite, typing is in code documentation. And I find it much easier to read than untyped code. You say that TS dev focus more on code, maybe it is because they like to focus more on code that they use TS. I do agree you can waste time searching how to type a complicated piece of code. Meanwhile it is worth typing that piece of code if it is subject to change, or that the usage of it is not easy to understand.
I hear the frustration in your comment, and I wonder if it’s because you might not be using TS correctly.
When used right: TS infers most of your types, TS does not add to the lines of code you need to write to get something done (especially if you’re already using propTypes), and TS multiplies your productivity by reducing time spent debugging and by making refactoring super easy.
I personally dislike Typescript as it is most often a hindrance for me, but:
About 2 years ago I had a pull request from a junior Dev - I can't remember all of it but basically he had an event (passed from some slider component) if something in that event was undefined he set a variable to be null otherwise it was an array, then he did an if check against something else in the event, and inside the if he checked the length of the variable.
So of course I pointed out that getting the length of null would be a problem. I actually had to argue with him a bit because he thought it was necessary for reasons. I got him to go through his code again and stuff was refactored to be better.
Typescript would have solved that problem.
I am in a big react SPA right now, that also uses TypeScript, often TypeScript causes problems of the sort - I am in a place where X could possibly be one or the other type (null or an object) so you need to write a check for it, in reality it would never have gotten to that particular point if it was null but poor TypeScript cannot figure that out.
Often things are wrong because some library thinks something is an Element instead of an HtmlElement or similar type of problem etc. etc. you have to go fix types, which can take more time than it should.
Finally it can be that TypeScript gives you very cryptic messages about what is wrong and it can take a while to decode what is wrong with otherwise fine code.
I can also say that in the 8 months I have been on the project I think TypeScript has caught two bugs I would have been putting in.
This is based on 18 years JavaScript experience 1 year TS experience. So I don't think it offers no benefit, I think it offers some benefit and irritates me more than it benefits me - but that is not the same thing. I must say that if you've been using it for 2 years and never had that oh yeah, I didn't think of that experience - well that's pretty impressive as regards your attention to detail.
on edit: although I have 18 years JS experience I would say only 7 years major usage, full time doing major stuff with it.
Well, TS does point things out to me in the IDE that make me correct it right there. But, I would have caught that in my browser in under 2 seconds anyway. With proper .map files to debug things it's infinitely more clear what's wrong than with TS's sometimes very cryptic messages.
As for your junior dev, maybe that makes the case for TS. But honestly, I've experienced junior TS developers who were simply overwhelmed by TS. They couldn't be trusted to write proper TS since they already struggled with JS. It just required us to review more code in their PRs.
I'll take a project with naming conventions, proper unit tests & code reviews over TS any day.
Yes, it slows you down because you need to think about your domain and how that maps into types (whether you think those types exist or not, they do).
Having that opinion isn't backend bias - it's likely being exposed to a variety of programming languages and having first-hand experience with the pros/cons of static vs dynamic typing.
I recently wrote an extensive post about my experience learning and using TS as both an app developer and a library maintainer for Redux, and why I am now completely sold on using TS across the board. As part of that, I listed several benefits of using TS that I've directly seen myself:
I love Redux, I love your dedication to the community (also on Reddit), and I love your work. But this is the first time I find myself completely disagreeing with you.
The bigger a project gets, the more unreadably TS snippets you run into. The cost/benefit ratio is awful; I've sometimes taken the actual author of the code and myself to analyse it, and it would take us over an hour just to get to the bottom of something that would be incredibly simple in regular JS.
From your article:
> Ah, the joy of reviewing a PR for a lib you maintain, when the PR contains code that you are not even remotely qualified to pass judgment on...
And then that code. Look at that. That's not nice. That's terrible code, horrendous. That should be rejected for the simple reason that it's unmaintainable.
> I begged for help on Twitter, and got a solution from the community that worked. I don't even pretend to understand the type declaration, but here it is:
The problem in larger teams is exactly this:
Some self-important TS lover in your team spends 4 hours tinkering together some arcane magic TS definition by copy/pasting a ton of shit from StackOverflow, is proud that it works, commits and pushed it, creates a PR... and everyone reviewing it is clueless what's going on. But it works.
Hell, if he understands it and it works, it must be good. Accept PR. Merge. Fast forward 3 months. Someone has to add a feature to this particular part of code. They look at the TS definition and 2 weeks later they have a new job.
I've seen people flee projects because of endless amounts of arcane TS...
If I'm imagining the perfect project it's based on a few qualities that I hold dear:
1. Sensible unit testing in place
2. Well defined code review standards
3. Strict naming conventions for code
4. Optional JSDoc where it makes sense
5. Minimalistic but readable amounts of code*
* Meaning that code should be short and concise, functional programming to the max, but not one big clump of inline nested functions.
JSDoc in itself allows you to type parameters and variables, it even adds human readable comments to the mix.
Then, when reading the project's code, you'll stumble upon a beautiful and sleek code base that just makes intuitive sense from the start.
---
I recently had a chat with someone about us developers always inventing the next pain in the ass to deal with. I think TS is a pain in the ass. When I started out with Classic ASP (Visual Basic 6.0) it was basically functional programming (functions and subprocedures) and we'd get everything done in record time, blazingly fast.
If VB6.0 was released by Microsoft today, millions of people would be fawning over it and it would become the next best thing. "What a cool Python alternative, thanks Microsoft!"
Same with Perl. Cool language. Hardly anybody uses it anymore. It's mostly Booking.com recruiting endless amounts of Perl developers because they're almost as rare as the fossils they often are (I worked there, I'd know.)
When we switched to XSLT and XML it was basically Handlebars, except not restricted, full of features, and just gorgeous to work with. But it lost its sexiness for some reason; mostly because JSON isn't compatible with XSLT. So nobody uses it anymore.
Now there's JSX, and that will also disappear over time. Probably for no good reason at all. Look at Angular and VueJS, they offer alternatives that are vastly inferior in many ways (no intuitiveness would be one, you need to learn the damn frameworks before you can get started), but they're the new kids on the block.
TypeScript is too often too easily accepted as the standard addition to a project. And I've experienced it NEVER to be the right call. And I've gotten other developers on said teams to–sometimes after some prodding–agree with my assessment.
Every project would be better off without TypeScript. I fail to see any of the benefits people mention because I've never seen them, I've only seen the exact opposite.
I do think it offers benefits. I'm not a big believer that it will prevent many bugs as is often claimed from typed languages, but IDE's can help you develop much faster (when everything is in TS already) and refactorings become way easier. If that outweighs the benefits is another question. (I still prefer regular JS myself)
In my experience, people who have been experts on JS before TypeScript became a thing hate it. - It doesn't give them any advantages, while severely limiting their options and workflow. For newer developers with background in other languages it is quite nice though.
I was an expert on JS way before TypeScript. I was kind of slow to adopt it because "the type hints are optimized away and can't even be used to boost runtime performance", but when I did start using it, I loved it and wish I had earlier.
The linked article says the vast majority love TypeScript, too.
I think the real dividing line is probably that people who haven't had to maintain a large project hate TypeScript.
(Which is still weird to me, because you can just turn off `no-implicit-any` and get all the benefits without drawbacks.)
For developers coming from other languages, typescript and the tool support in VS Code is what makes frontend engineering tolerable these days. A big difference with just a few years ago. I insist on it in most projects I'm responsible for. I see no good technical reasons not to use it at this point.
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...