Articles like this will certainly bring out the pro-Typescript people, so this got me thinking. I'd like to hear from people who tried Typescript and found they didn't like it for any number of reasons.
Note I'm not pro or anti myself, I've only just begun playing with it, but would like to hear from all kinds of people.
The article is correct in that it's important to understand that typing your code has a cost - it's not just all magical benefits. Personally (personally - not for everybody) the cost is that it inhibits my initial experimentation. I don't KNOW what types things should be while I'm faffing around researching and experimenting in a new domain.
I'm a huge fan of strongly-typed code, but I like to add the types much later, once all of the pieces are in place and are not in constant change, and mostly as a way to not have to write unit tests. If I type from the start I find I lock in to sub-optimal data structures and get "attached" to them. I already typed them, I don't want to break things!
Also, I live by the "What Would Rich Hickey Do?" school of thought... so when he mandates types in Clojure, I'll switch to TypeScript by default ;)
Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. Imagine you give a painter a brush that doesn't allow to be used freely, that's what TS does to a good JS developer.
But TS is at this moment really eating JS jobs, and that kinda hurts. I just don't understand the proponents, besides the job opportunity, give me one single reason to write in TS? If you want to go for a strictly typed language TS is definitely the worse choice. TS simply doesn't fit in the JS ecosystem. Look at (a part of) the dependency part of this package.json, from the beginning of a large project. Don't you agree something is going very wrong in the JS world?
> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something.
You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to write some code TypeScript is a godsend.
you mean Python and Ruby like languages are unmaintainable and therefore deprecated? I rarely have a problem with maintainability in JS because of types, but I do have problems with poor constructs, poor readability, dependency issues and so on. It's a typical illusion of TS proponents that code becomes magically maintainable.
JS developers moving to TS should at least do a few weeks of Assembly and C programming to first understand the origin of types. I've spoken too many front-end devs who don't have a clue what a type actually is and at the same time promote TS. It's a godsend we don't need them in scripting languages. Use tooling to catch issues, that's the future, TS is just a whim.
It's like using a bandage to prevent an injury. Yes it's good to have, but it doesn't prevent anyone from writing unmanageable code. Contrary it can make it even easier to write unmaintainable code.
You can say that about literally any technology. Nobody's claiming TypeScript will fix all your problems and discover all the secrets of the universe: it's just a useful tool that well outweighs the overhead it adds.
I just don't like having to look things up, or remember them, or tell someone else about them, or make sure the things I told them or that they told me are still true six months later, or check manually that I haven't typo'd a variable name, and so on and so on, when a machine can do those things for me.
The absolute worst case with TS is that I'm as bad off as I would be in JS (use "any", or "as", or provide a dummy anything-goes d.ts for a lib, or whatever). I haven't found that I actually need to do those things very often, even being fairly lazy and having a very low tolerance for time lost to managing my tools.
When dealing with binary packages I have to do stuff like iterating over an object to see what it exposes. I guess typings (if one exist) help a lot there. But for open source code you can just look in the source. Looking at other peoples source code is the best way to learn, so don't let TypeScript take that away for you. The projects with non-existing documentation is often the ones most easy to use. Maybe because the source code is so easy to understand that no documentation is needed :P
Most developers coming new to JS are Java and C# developers. They want to keep their old tools, and methods. And Microsoft want to keep selling it to them. Which is my main concern, once you're in you are locked in.
This reminds me of the idea that seemed to be very popular a couple years ago that everyone can and should become a programmer. Nothing is quite that simple.
It's really sad. The original idea is that application interfaces should make programming accessible. Think the vi editor as used by AT&T secretaries, or Excel spreadsheets.
Some concepts and interfaces simply can't be shrouded in clickable widgets that command the computer to perform some pre-scripted task. Just like people need to use math directly and require the ability to input and manipulate simple equations, some problems require the creation of small programs--variables, conditionals, and the encapsulation of these things into functions.
Maximizing the utility of computers means everybody should be capable of not only basic grammar or basic math, but basic computer programming. But that doesn't mean everybody needs to be taught to be an author, mathematician, or computer programmer. Rather, actual computer programmers need to design applications in a way that make it simple and easy to apply basic editing, mathematical, and computer science techniques to the task at hand.
That was the original idea back in the day. Then it was co-opted by social movements in a manner that completely misunderstood the notion. Indeed, they have it completely backwards. The way to make programming accessible (and to reduce the outsized power of the programmer class, sharing the wealth) isn't to turn everybody into programmers, it's to make programming a part of every job.
But the fact that programming is largely still the domain of programmers isn't the fault of those social movements. It turns out it's really hard to design interfaces and applications in this manner, and harder still to keep it consistent across unrelated applications so knowledge and experience readily transfer. Arguably the furthest we've ever gotten is early text editors, the shell, and spreadsheets.
The fact of the matter is that, broadly speaking, basic programming is a suite of cognitive processes that pretty much all come online at the same, reasonably above-average IQ, and they are irreducibly complex; they cannot be further simplified except by rote execution of formal process, at which point you should just let the computer handle it.
That's a pretty bold assertion. Or maybe your understanding of "basic" programming is much more advanced than necessary. I'd consider writing a slightly complex ruleset for filtering e-mail "basic" programming. I don't think that "Put that mail in this folder if the subject contains A unless it's from Jack, then put it in the Jack-Folder" a skill that only comes online at an above-average IQ.
I think one of the best newer success stories here is another thing that, like "filters" and "spreadsheets", doesn't even call itself "programming". The Android app Tasker [0] is a "total automation" tool with over a million installs.
While I understand why we don't really see them, I would love to see a much more involved comparison. A reasonably sized app would probably use redux/vuex, routers, async, etc. which changes things dramatically. Even just adding the state managers changes things completely. Then you have things like cost to maintain/upgrade.
I'm in the exact same boat. React never really felt comfortable for me, but Vue clicked immediately. Admittedly, I'm coming from an AngularJS background.
Unfortunately, this doesn't appear to be the case for me. I've been wanting to switch back to FF for some time but just opening a website causes my MBP CPU to go nuts, seems 61 is no different for me.
You wouldn't happen to be running Tab Session Manager, would you? That was causing me all sorts of performance problems on both PCs and Macs, and I only tracked it down by disabling all extensions and themes and then incrementally re-enabling them.
I am not, although you did remind me to try without any extensions enabled again. I can't do a straight comparison as I'm at work now, but my work laptop (2017 vs 2016) is showing improvements. For reference, my work laptop also had high CPU usage on previous releases (even with no extensions), so there's hope yet. Although not being able to use the extensions I normally use would be a deal breaker (blockers and such)
For me it just consistently hovers around 18% cpu. Chrome on the same site sites around 1%... could it be optimized for memory usage isn’t always better if it means more cpu usage?
Note I'm not pro or anti myself, I've only just begun playing with it, but would like to hear from all kinds of people.