Piṭi is a simple card game that my grandfather taught me - think of it as bridge light. Like Hearts, Euker, and many other games, Piṭi has the notion of ‘following suite’ and trumps. It’s a light-hearted, quick four player game that consists of thirteen rounds.
Whenever I go back to India, I play this game with my relatives, and I was looking to learn a new framework one weekend, so I decided to get my boots dirty with Angular 2. The code can be found at my Bitbucket here, and the new website,
piti.notablog.xyz, is live.
Typescript is awesome
Typescript is awesome. When I first heard that Angular 2 was shipping typescript by default, I was incredibly skeptical. But I’ve since become a huge fan. Microsoft is doing some awesome work lately, and Typescript is only the latest proof. The typing works really well, and it helped me catch some gnarly errors on the server side.
Angular 2 Is Not Ready
It’s really, really not ready for prime time yet. Seriously. The website is cool enough, but once you get into the weeds you start seeing all the places in which it is falling apart. The tutorial asks you to import
'@angular/router-deprecated', which by itself should make you pause.
And of course, once you get to the ‘Routing and Navigation’ page in the developer docs, they tell you the non-deprecated, completely new way to do routing.
Add to that the fact that you can’t really google / stack overflow your solutions, since nearly everything that’s posted will be in reference to either Angular 1 or to an older, deprecated version of Angular 2 (possibly back from when it was in its alpha phase). Ultimately, I had some gnarly troubles getting started.
Or the fact that I would frequently just have to put
ngIf=variable in my templates because who knows whether Angular had made my variables available yet or not - no, seriously, prefacing all your templates in a huge if statement is the preferred solution. Wat? This was for a simple web app which had no database or any significant network calls, by the way. Running on localhost…
ngModel setting - surprise - didn’t work for radio buttons. Not all of these are Angular’s fault per se - that last one actually makes sense - it’s just that when you’re learning Angular for the first time, Angular 2’s documentation isn’t nearly sufficient enough to really understand what’s going on. Running into things like this on a regular basis is rather discouraging for a first timer.
Half the time I would end up looking into other people’s repos and copy pasta-ing some example code.
The biggest issue, though, is that currently the tooling is simply not there. Chrome, for whatever reason, handles the Angular errors out of the box a bit better than Firefox. But ultimately, unless you have some nifty external hotloader, you are absolutely screwed when it comes to debugging.
Angular Is Doomed
Even if Angular fixes all of the above, I think Angular is doomed in the long run.
Any system that prefers runtime errors to compile-time errors is, in the long run, doomed. Particularly for projects that get truly massive. I think the Angular team, to a large degree, realizes this and switched to Typescript precisely because of this reason.
The biggest issue is that Angular does not detect type errors (or even syntax errors, really) in its templates. Rather, it will simply default to the blank ‘Loading’ screen upon any error at all. So you sit and wonder what exactly you could have done to cause it this time, as you slowly backtrack through your changes.
This Medium article, from which the above image came, captures the difference perfectly. JSX does a bit of type checking and syntax checking, at least, which Angular simply does not doe. Heck, it doesn’t even do type checking within its templates!
If I have a component that takes an object
A, and I instead pass it object of type
B, it cannot detect that. Think about that for a second - a system that relies on Typescript cannot detect such a simple type error. Ultimately, for me, that was the final nail in the coffin.
This comment is promising that at least some of these things will get better. And I hope they do. But at least for now, React is the clear winner. And if they don’t, it wins in the long-run, too.
To be honest, I don’t understand the raving praise behind Node and the entire NPM ecosystem.
NPM’s default behavior is insanity - it forces everything to memory. Which is why on most deploys your
npm install keeps getting killed. So you add a swap file, great. Why would this be the logical default? Store everything in memory, seriously?
Node in general is overrated to me. Between callback hell and single threading, I don’t see any advantage beyond having the same language on the frontend and backend - which, if you’re an engineer, is not a real advantage. Learn a language or two, it won’t kill you.
Don’t even get me started on the myriad of random issues that keep popping up because of random versioning issues and how ‘easy’ it is to upgrade node itself. The number of days I’ve spent debugging node, npm, nvm versioning issues… It’s 2016 people. Come on. The fact that there’s an in-depth guide to do something as simple as uninstalling speaks volumes.
I think it’s time to go back to my roots. Good old Python.