We zien dat u de website vanuit Nederland bezoekt. Wilt u de website in het Nederlands bekijken?
Hit enter to search
In CastIt there are multiple channels you can control, with multiple players running even the same channel. You need a way to monitor all of this activity and that is what I was aiming to rebuild with the task. The control panel was already built using react. Great. What else? CastIt is mainly built in PHP but the part I am calling and pinging for information is node.js.
So I started with Angular 4, which I will refer as it is called - Angular. Now, a little intro about Angular. Its main purpose is to build SPA apps, unlike Vuejs which can be used for SPA but also for different application types. Soon, I realized it’s not enough to go through the official Angular documentation.
There is much more you need to learn in order to get started. After some reading I decided to move and change the development environment. I started using Visual Studio Code as the new development environment. There are many reasons for doing that. Its lighter, much faster and it has great TypeScript and Git support. Using Angular with VS Code required additional effort and learning. I had to install and learn a bit about Node.js, to use NPM, Webpack. First, you need to install Node.js and NPM. You also need Webpack – a module bundler which simplifies your work tremendously. Without it, it would be pure hell. So I started with Angular command line interface (cli) as the Angular documentation suggested and installed a new application, which in turn gave me a template that included built-in support for TypeScript, Webpack, Unit tests. TypeScript support seemed natural.
As for unit tests, template had the Karma and Jasmine unit tests preset. Unit tests launch in chrome browser, with visual feedback for each test. So it was very useful and convenient to use. Visual Studio Code offers autocompletion, F12, “ctrl + .” support which is Visual Studio like. So, that’s really cool. And what is best, after a while or better said right from the start, I realized TypeScript has many similarities with .NET object oriented programming, which I found to be a great feature. Its type safe and I find that as an important benefit (because of my .NET background). You can make and use interfaces, you have constructors. Another thing that I noticed was code separation, that is, the Angular template initial setup structures files in a way that it separates html, css and TypeScript. I find that as a big plus as you keep away business logic from the html/css part, which should not be concerned of it.
Modularity is one of major Angular features. When coding with Angular, it is all about organizing code into the buckets. Angular also introduces services, which are placed where you can write reusable business logic, extract and encapsulate unique repeatable functionality. Also it is notable that Angular strongly relies on dependency injection. It is implemented in a simple way, which is nice. Another benefit of all modularity, components and services is that, in terms of coding styles, Angular guides the developer how and where to write code.
Some notes and ramblings. To reflect on Angular complexity. For example, animations do not seem like a great implementation by Angular – code syntax and results were way too difficult compared to yielded results – so in the end I abandoned using Angular animations. The situation is similar with pipes. Pipes are used to manipulate and transform data. Pretty weird term for what is usually called filtering. Actually it takes in data as input and transforms it to a desired output. In my case I needed channels table to be able to be sortable. Should not be complex, right?
No. So Angular uses pipes and for me that concept was kind of weird. It was like a separate piece that will not fit into the puzzle at all. Another note that adds to confusion is that Angular documentation suggest to use impure pipes with great care. If pipe is set as impure then they track changes and can easily leave an impact on the user experience, so be careful when you use it. It’s like, why have it simple when you can make it complex.
The syntax is also kinda inconsistent, you can write the same thing in several different ways. But make only one miss and it will not work, without any warnings. For example with pipes, arguments are separated with colons? Don’t know why. Syntax to do two way binding was unusual as well or transferring event data from one component to another parent/child component is not that natural as well. In the end I can’t escape the feeling that learning curve for Angular is just too steep and not backed up with enough docs. So it seems like too much of an effort at the end or better said an undocumented unfinished product (at the time of writing blog post).
Regarding the syntax, some parts are pretty similar to Angular. I am referring to template syntax like v-for and *ngFor or v-if and *ngIf. One note though - Angular syntax is case sensitive. But there are some special cases with vue as well, like with html attributes, where camelCase property names are using its kebab-case html equivalent. Note, however, that I spent no more than 2 weeks working with it so I would not be surprised if I missed many features and details and that many of them have their alternatives. It's only that I did not have enough time to learn about them. For example, later I discovered that there is a vue template that adds support for TypeScript. That said, it means that the same object oriented feeling I got with Angular, can be achieved with vue using that template.
Still we can say TypeScript is not there by default, so small advantage for Angular (in case you are into TypeScript as I am). I mean, TypeScript is not a 1st class citizen in vue. My final impression is still that Angular is more modular than vue. I also learned that, while Angular has all the functionalities you need within its framework, routing, state management, http, its validation, animations, … basically has everything under its umbrella, on the other hand, with vue I had to use some additional 3rd party libraries. For example, you don’t have built-in http/ajax support. Instead axios library is suggested as a 3rd party implementation. Even though it looks cool that you have it all when using Angular I could not find many downsides because of it. I can imagine it may cause some breaking changes over the time but Angular was prone to breaking changes within its sole framework too.
Well, even though it was a positive experience while working with vue in general, there are some things which I normally did not like. For example, at least on first try, a vue project template uses mocha, karma and phantomjs as a browser for unit testing. And using phantomjs as a browser is not as nearly convenient as it is the case with the default Angular setup. Also debugging and stepping through the code in console did not work well too. For example, setting a breakpoint would not work for some specific lines. It seems it is related to source-map setting, but I was unable to resolve it in the short time I had available.
Which is the chosen one? On one side you have Angular backed up by Google. Still vuejs seems lighter and faster, not supported by giants but still has some notable implementations like for wizzair, euronews, alibaba, baidu, facebook newsfeed. Later I found out that vue is supported by the Chinese retail giant Alibaba. Still, because Angular is powered by Google it has bigger influence on the job market. So if you consider to sell your expertise as a developer, Angular might be better option at the moment of writing this.