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.
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
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.
Angular, on the other hand...
You are confusing your imagination with reality (or the history of your own experience).
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.
Same goes with RxJs, dependency injection, unit testing, and modules.
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.