2019: Time to Play

It is known that the kids are learning through play. Adults are the same, it's just called differently — gaining experience. Mostly because playing is considered as not an adult thing. But actually, it's the same... with a pinch of responsibility, of course.

During 2017 and 2018 I was playing with Angular (2-4-5-7...). 2019 for me was a time to play with as many different frameworks/libraries/compilers as possible. Real clients. Real projects, that need to be finished on time.

Ionic 4 / Angular

The year started with a mobile/web application. I chose Angular because I was pretty sure I can do whatever is needed. And Ionic 4 was something I was interested to play with. It was still in beta at that time. But has web components under the hood, which sounded interesting.

There is just one big flaw with Ionic: stack navigation is still keeping all the pages open and running. Just to keep the state and scroll position to make the page transitions nice. And this can be a serious hit to performance if the application has more than a few pages.

Other than that, Ionic is IMHO the best mobile component library. It has almost any component needed in a mobile application. And since they are already targeting the desktop with PWAs, I hope the components will get better suited for the bigger screens too.

About the web-components... well, they just work. And that's great. But if you want to change some of the rare CSS-properties, which are not changeable through variables, that can be a problem. Because of the Shadow DOM.

Firebase

This year five of my projects were using Firebase as a backend solution. And I want to use it even more: free, fast, web-sockets push out of the box, cloud functions in JavaScript.

And if you don't need the constant sync or think the library is too heavy — there's even a way to use it as a REST API.

There are a few things like Push Notifications and Remote Config, that I want to explore and get some experience, but next year I'm sure I'll get a chance.

And the service they are missing for now is an integrated SMTP-server. Yes, I understand that they don't need the fight with the spammers, but I'm missing the functionality much and don't like to use external service for that.

Vue

I've already written about my Vuexperience. A brief recap here: change detection through auto-created getters and setters sounds cool, but the rest of the experience was not so cool: component objects with not typed fields and not obvious connections (can I use computed values in the data props?) don't sound like 2019.

Of course, all the specifics can be learned and remembered but... you won't be able to use this knowledge elsewhere.

IMHO, if you are not already using Vue, wait for v.3 and the new component API.

Svelte and Sapper

I've heard about Svelte in May (famous Rich Harris' talk). The time I was finishing my Vue project. And I wanted it right away, but since there wasn't a project for it, I decided to rebuild this blog with Svelte (and Firebase).

And it was easy. Verry. Well, there isn't any complex logic, but compared to any of the other frameworks mentioned here, everything was so plain and simple... No classes. No decorators. No jQuery magic. Just plain and clear javascript. Well, almost — export let is IMHO not the best way to mark an incoming property.

Compared with Angular/Vue the templates are fine. But I have to admit, that I like more JSX's JS-constructs.

And then came Sapper. The SSR companion library that... just works. After playing with Angular Universal and even Gatsby, Sapper is still the best experience for me: file structure based routing; clear separation between what runs on the server-side and the client's part; excellent `sapper export` command that walks through the links and generates static files for every page available.

And this blog wasn't the only thing I used Svelte and Sapper for. We had a little project to generate a couple of hundred static pages. With page transitions like mobile OSes: slide up for Android or left for iOS. And the built-in transitions in Svelte not only work in the SPAs but in the exported static pages too. Keeping the removed element in the DOM during the transition. Out of the box!

And the output size is so tiny... still can't believe.

React. With Hooks!

I had some previous experience with React. Knew all the base concepts like setState to rerender, differences between class and function components, HOCs, Virtual DOM, and so on. But when v.16.8 was released, everybody was talking about the Hooks. And I cannot resist the hype. Again.

My first React project this year was another Ionic 4 mobile/web app. Ionic React was not even beta. I was hoping the React version will handle the pages in the stacks better than the Angular version. But the beta release was doing the same — keeping pages running with not even shouldComponentUpdate optimizations.

The fun part was that Ionic starter is using TypeScript by default (you can create .jsx-files too if you want/need) and that was great. But I had some troubles with the redux's compose HOC and some other libraries not typed well.

Anyway, the hooks are great. Leading to a compact and easy to read code. Not super clear when the component will rerender, as with setState, but more obvious than HOCs.

Flutter and Dart

Another hyped technology. Of course, I wanted to test it, so I started another personal project. Small mobile app to track my kids' development (height, weight, etc) — The Kids Log.

Initially, everything seemed so easy: Dart looked like some kind of strict TypeScript; Flutter widgets cover every possible situation; and dev environment lets you do everything from VS Code window... a perfect world.

But then, suddenly, on the third weekend of writing the app (I don't have much time to spend on personal projects), I realized that I don't want to continue the development and prefer to watch some movies or TV shows instead. Not a good sign. Both for Flutter and my will.

Thinking about that, I can say that there are three things I didn't like in Flutter:

1. Dart is much stricter on types than TypeScript. Much. Especially when it comes to complex Maps and Lists with objects in it. The data is not that easily transformed and updating the redux state is not that elegant.
2. Too many widgets with specific settings. Plus multileveled styling properties. Typed. It's just hard to remember and a lot of unneeded code — you are not able to set non-valid values anyway.
3. Unlike HTML elements most of the widgets aren't flexible by default. And that's not I am used to. A lot of dimensions errors are just not possible with the HTML model.

Results: the current state of the app is a mess of too big widget trees with too many boilerplate code to set just a few props.

Maybe I'm missing something, maybe I should invest more time in theming or creating my own widgets to make the code cleaner... I don't know yet. But I'll write when I find out.

2020: Don't Stop Me Now

Well, it's a long piece already. So instead of any conclusions, I will tell you that I'm looking forward to 2020. And I hope to have an even more interesting year ahead.

I would definitely finish the Flutter app. I want to try also Flutter for Web.

For sure will have not just one React project and want to spend some more time with MobX this time.

Stencil is something I'll love to use on a big project.

And for sure there will be a big WordPress project where I'll work together with a WP expert.

Oh... and Vue 3 is coming... well, I don't know :-))

And an interesting new year to you!