On the one hand I am glad they are continuing to enhance TypeScript. On the other hand I am concerned that TypeScript is becoming a very bloated language. If you have seen the latest edition of Stroustrup’s C++ Programming Language book you know what a bloated language looks like. Is that where TypeScript is headed?
Programming languages are not like your Word or Excel where more features is better. Some programming language designers take pride in how small the language is, for example Kernighan and Ritchie. I worry that as long as Microsoft has Program Managers and Development Leads assigned to TypeScript and their job performance is measured by the number of features they add, TypeScript is going to get more and more bloated with obscure features.
As a PM on the team, I actually _share_ your concern! ;)
In fact, we're very mindful about the cognitive overhead of new features, but we're also motivated by pragmatism. These features have been highly demanded to help them write real-world code. My coworker Ryan has written up a pretty good explanation of why we tackled the feature set that we did: https://news.ycombinator.com/item?id=16277367
Keep in mind that TypeScript strives to model JavaScript as it's written broadly. While we could always take the stance that you have to rethink the way you write JavaScript, that would be unnecessarily stubborn. Hope that gives some insight!
It is a bit dizzying that the type system keeps getting even more expressive (the next release might have type conditionals!) while the core language and its dynamic semantics is necessarily limited to tracking Javascript (so no operating overloading, no pattern matching).
TypeScript itself doesn't really add new language features; it just tracks the ECMAScript spec and considers proposed features for implementation after they hit stage 3.
The enhancements coming out in new TypeScript releases are largely related to typing expressiveness / type inference precision (covering more edge cases where one might have previously resorted to `any`) and strictness (catching more errors at compile time).
Indeed, the only Typescript feature I can think of that isn't purely for type checking or lifted from ECMAScript is Enums, and Enums have been around forever.
Well it has supports for JSX and decorators which AFAIK aren't in the spec yet. It also has a syntax for class mixins without actually doing any desugaring when the code is transpiled. So it's not quite just JS + types.
Ah, I forgot about those. Nonetheless JSX and Decorators were added to the language back in 2015, so they've been sticking strictly to ECMA features for nearly 3 years now.
It has public, private and protected members (checked at compile-time), which is a bit of a mess because ES is gaining an independent notion of private fields (checked at runtime).
The strongest point for TypeScript is its tooling and editor support that made it so easy use to use it in development. Even anyone writing JS in VSCode gets to use some checking from TS. But that bloat in the language and the amount of features added with every release is making me a lot worried.
ReasonML is great but it still so immature with little issues here and there that might be annoying to some people. I expect it to be a great alternative in the future but not now.
That's for example what makes something like Elm much better. How Elm dealt with the whole echosystem to make it use separate packaging system, not bad editors support (needs a lot of improvement for VSCode IMO) and the simplicity of the language made it a really powerful alternative that I'd use instead whenever possible.
Looking at the 2.7 updates, they don't really seem to be adding more features that result in bloat - instead there is a lot of work to make existing features more predictable and catch potential mistakes. Sounds good to me.
If they add features the same way they do with C# I don't see a problem. C# has been extended a lot from V1 but it doesn't feel bloated at all. I think C++ started from a much less solid foundation and is still suffering from that.
> On the other hand I am concerned that TypeScript is becoming a very bloated language
I came to say exactly this. Are there actually people out there asking for all of these nuanced features?
I've been excited about TS for a while and used it for several side projects with great success...but with each new release and new set of "features" my excitement wanes a bit.
I do some of the feature planning / prioritization for TypeScript.
The strict class property initialization check was the one of the highest-voted, most-commented, and most-duped "unfixed" issues on the issue tracker.
Definite assignment assertions are a necessary co-feature for class property initialization checks to work ergonomically.
ES module interop is just TS keeping up with the evolving ES6 / CJS interop story. TS has to support ES modules.
"unique symbol" is type system support for the long-present ES6 symbol concept.
Cleaner/prettier console output should be uncontroversial as an incremental improvement.
Numeric separators are an ECMAScript feature that need to be supported. TS has to support ES syntax.
Fixed length tuples were a long-standing proposal (nearly 2 years old) that had a lot of positive feedback from the community. Among people who were using tuples, the prior behavior was seen as very much wrong and we were convinced by the use cases. People not using tuples are unaffected, naturally. It's more of a bugfix than a feature.
Better narrowing under "in" and "instanceof" were also long-standing issues. The "instanceof" behavior in particular just looks like a bug; only from a spec-lawyer perspective is it really a feature per se. It's more of a bugfix than a feature.
Smarter object literal inference again basically amounts to a bugfix; TS was allowing extremely broken code, essentially due to some implementation details of how types' representations are optimized. It's more of a bugfix than a feature.
It's definitely understandable that the most exciting features are already in the language, but I don't see anything in this list and see "bloat".
Thanks so much for taking the time to respond in such a thorough manner :)
I really appreciate the work that the TS team is doing, and understand that they are up to a very difficult task in trying to keep up with JS while also augmenting the type system capabilities to cover more cases.
With regards to making the language more complex, yes, i agree that it's not something pretty, but at the same time i find these kind of additions similar to the recent JS additions: you can still ignore them if you don't need them. E.g., you can still code perfectly fine without using classes, or symbols, or whatnot. There is the issue of having to deal with different "dialects" of JS/TS when reading others' code, but that still happens in pretty much every mainstream language i know of :/
JS is a big language. It continues to grow without removing features. One codebase can be very functional, another dynamically typed C++ from 2004, another pythonic. As long as they support the entire language while adding static typing (not an easy feat), it's going to grow. In that sense it is very much like C++, though it's still not in the same league of complexity of C++.
If you want a small language, look elsewhere. I had fun with Bucklescript over the weekend, and it is amazing how expressive it is. The syntax sucks in places [| Reason is a small upgrade |], but that's probably where you want to look. Maybe Elm if you are fanatic about it.
Kind of(maybe). But that's beside the point. Typescript is a separate language that happens to compile to Javascript. The TS team is in no way bound to support every style of programming that Javascript supports (and they don't, just by virtue of having strict typing).
They don't have to, but as long as they want to market themselves as a "typed superset of Javascript" (see homepage), they do. For many people, that is the point.
Yep. And this is important, it allows people to move most JS projects incrementally to TS projects. If they fall far behind the features that many JS projects are using, that won't be true anymore, and those people will start using Flow instead (flow.org)
Similarly it is useful for TS to track the Stage 3 proposals of future features and offer them early, as JS users may pick those up with Babel or other polyfills. Typescript's own transpilation behavior of Stage 3 proposal can sometimes be a useful test for the feature while browsers work on their own implementations.
> Programming languages are not like your Word or Excel where more features is better.
I‘d contest that even for those categories adding more features is necessarily better. In fact, Word in particular is an excellent example of how adding features can result in a worse product.
On the other hand, I like programming languages with either a “batteries included” philosophy or a large ecosystem of easily usable libraries that allow you to solve common real-world problems quickly.
If that’s bizarre consider the fact that Microsoft does credit check on employees every two years, as a condition of employment, and you can be fired if something really bad shows up. This is for employees that work in the Azure division and the purpose is to reassure customers who host their data on Azure.
If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.
Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI.
I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:
We were precisely talking about composition and now you say there is only one? I guess you are talking about small apps where you have small dedicated views?
That is a very narrow definition of MVC. I am talking of large interactive software with multiple views on large hierarchical data trees data with different levels of focus and granularity. The kind of software I am thinking of big programs like Photoshop, Premiere, an IDE, Ableton Live...
Disclaimer: I worked for Ableton for quite a 5 few years, and have spent most of my career building interactive software (I work as independent consultant now). Most of the software of that time and age is built around MVC. It kinda works, but as a lot of people in the industry building software of that size will tell you: scale brings the the pain. Because of composoability. In the C++ world, see also talks from Sean Parent--who worked on Photoshop--and is also a strong proponent of "value-based" approaches (he is a great source of inspiration for me). Sean claims that something like 70% of bugs in Photoshop are in UI-related code typical MVC wiring up stuff.
In the end, just pick the right tool for the job. If you are writing small apps and MVC does not explode at that size and fits nicely with the underlying frameworks, go ahead and use it (I strongly suspect you are an iOS dev and understand how conformity with the native framworks is very important there).
But if you are building something large, highly interactive, with lots of views and concurrency, try to move to a more declarative/unidirectional flow/functional approach. It is still an open field and there are many alternative approaches, but it builds down to composability, denotational reasoning and decoupling of effects/logic.
@arximboldi, I wouldn't use MVC for implementing something like Photoshop or and IDE, that's not the kind of application MVC is good for. MVC works well for applications that navigate through multiple screens.
Yea basically this. Built a 'big data app' using Ember, which was all well and fine until some of the routes essentially became their own apps, that were more akin to apps like photoshop. MVC really broke down for us here, and it wasn't until we introduced react / redux and slowly refactored the application until things got more manageable and sane.
OOP was very different in smalltalk too. Industry software dev has really strayed away from the theoretical origins it was based in, although I think the tide is starting to turn back now.
Templates frequently need loops and conditionals. In the case of .tsx this logic is in TyprScipt so you can debug it just like any other TypeScript. In the case of Angular such logic is written in an undebuggable custom syntax.
So basically you prefer something more along the lines of Model View Controller. Me too. When React was first released it was advertised as “the ‘V’ in MVC”. Unfortunately the developer community took it in a different direction.
JSX standard is independent of React and can be used with Web Components. Also, HTML import is unnecessary to use Web Components. The key technologies in Web Components are ShadowDOM and Custom Elements.
None of these problems are unique to web development. How do you solve these problems in iOS? In iOS you use MVC, and the Application object holds the state as a tree. MVC has a better solution to all these problems.
Being able to do so is certainly a cool feature. But I've built a lot of apps prior to Redux and never felt like state replays were a must for debugging.
There are various ways to debug state in a React app that uses setState. React devtools show each component's state, and you can combine that with breakpoint debugging as per to figure out how you got there.
Yeah, you can use breakpoints, but...that's awful. Like, it feels like crap to do, you end up stuck in half-transactions and other nonsense because you have no better options. The use of Redux (or any other functionally-oriented action-based state system, I was writing them in Java and C# long before I ever used Redux) enables powerful stuff that, yeah, might not be a "must"--but being a "must" and being a transformatively powerful tool that requires very little cognitive overhead to leverage aren't that far off.
Redux is unnecessary complexity. Anyone considering it, please do yourself a favor: check out an MVC framework and see how simple it is. Remember, when React first came out they described at as "React is the V in MVC." Adopt MVC in your project and watch your productivity soar.
Note: Some people believe that MVC implies two-way data binding. This is false.
Trying to shoehorn MVC into the front-end is also unnecessary complexity.
You can get very far with setState before you need a library like Redux to manage application state. And you can get even further if you use something like Apollo or Relay to handle data fetching. Then your productivity will really soar!
(For me, React + Apollo feels as magic as Rails did ten years ago.)
I've spent most of my time as a back end developer, occasionally dabbling in some front end code in various MVC frameworks. I always hated it and found it to be tedious.
I recently took up react+redux for a new project and for the first time feel like I'm developing for the UI in a way that makes sense and feel like I'm able to accomplish things way faster than with other clunky frameworks.
Note that JSX is not limited to React. You can use JSX (or TSX in the case of Typescript) as a better replacement for Moustache or Handlebars. See here: https://github.com/wisercoder/uibuilder
I didn't think JSX made sense until I used it in Typescript (TSX). Having type safety and refactoring support in views and templates is wonderful. I know that both Vue and Angular have worked to build Typescript compiler plugins to support type checking their view files, but TSX is out of the box, has great editor support, and gives you the full power of Typescript's downleveling transpiler, too.
For what it is worth, the project I'm primarily using TSX in isn't using React either. It's built with Cycle.JS which uses competitor virtual DOM Snabbdom.
Programming languages are not like your Word or Excel where more features is better. Some programming language designers take pride in how small the language is, for example Kernighan and Ritchie. I worry that as long as Microsoft has Program Managers and Development Leads assigned to TypeScript and their job performance is measured by the number of features they add, TypeScript is going to get more and more bloated with obscure features.