Going Native

A lot of things happened behind the scenes. Due to some unflexible cash flow my company closed Korea branch, and I moved to a small company and got dual role of system engineer and developer. Well, the company first expected to do engineering and development works in 50:50 manner, but in practice I concentrate on development itself. I think it's a good start for a ex-hobbiest-programmer where the customer changed their feedback from negative to positive after my application is delivered to them.

And, during the time I thought of the techonlogy stacks I should bring with myself. Though Qt can cover everything from desktop to mobile, and is equipped with a lot of powerful features, after applying the tool to the work situation things dragged me of my legs. For example:

1. It's BIG. HUGE. OK. It's good to have a lot of things, but the size of library grows bigger with any new addition of the features. For simple tasks, I can't avoid the feeling of using zweihander to grass cutting.
2. SLOW. From Qt Model-View framework which is a failure and needs restructuring, to container classes like QList or QLinkedList saying "we're concentraing on convenience while STL stresses on raw speed," and the speed of database manipulation is not that good eighter. For databases, I found out it's far faster to use SOCI after converting things from QString to std::string. From my experience, for the same task Qt took about twice or more time to perform the same task against others(e.g. STL or wxWidgets).
3. Developer is "locked" into the Qt ecosystem. Well, I admit its rich feature gives developers more development convenience, but after adopting to Qt I don't feel good with using it with other libraries or environments. Sometimes I feel I'm working on Java instead of C++, in terms of not only structue but also running performance of the system(meaning that it's slow, unlike C++). During coding, I'm not sure whether I'm using Java or c++. Ah, of course signal-slot mechanism and QString is such a technologicla advance in a decade.
4. It has some holes here and there, for example, Qt Quick. I love the approach and structure of Qt Quick and I admit it's such an accomplishment, I see occasional "broken" frames on Windows/Intel environment, or I see too long time for the first run on Andorid(they existed until Qt 5.9. I heard that the bytecode compilation in Qt 5.11 resolved the slow first start a lot, but I had no chance to test it). Or, for me a MinGW user, in Qt 5.10 qdoc(and that Qt documentation) suddenly became unavailable because MinGW 5.3 couldn't compile libclang(......). And the new autompletion with libclang in Qt Creator is said to be toooooo slow....... And so on and on and on. 
5. Sometimes there are things infeasible to programmers. Qt hides the implementation details in its private layer, which makes it too difficult to debug when some bad things happen, especially when it's related with some specific feature of Qt itself. What's more, due to the behavior of QURL to force percent-encoding(and which is malfunction in specific context), I had to give up QNetworkAccess and adopt libcurl(with additional coding where I had to implement about 3/4 of my network coding again......).

Well, anyway it's BIG enough to be tackled from anywhere, but you know, now I can say there's no one library/framework that fits too all. So I looked for any alternatives and asked for help from my close friends. And guess what? Now I'm dropping the dependency against Qt and bringing development staks close to native "recommended" environment.

1. C++ / wxWidgets & more: whoever says what, C++ is my main development platform. And I concluded wxWdigets, thin wrapper of native widgets, can replace Qt Widgets. Thinking of my past experience, I had to save my time so that I had to use Qt Widgets anyway(and Qt Quick took relatively too much time to develop). wxWidgets consumes less memory and bootstrapping is faster, which fits to my philosophy of "relatively fast running."
2. Ah. I changed my compiler from MinGW to VC++. I was using MinGW to expect consistency against platforms, namely Windows and Linux, but nowadays I had to use some Windows API which doesn't exist in MinGW(:P). And it looks like VC++ looks good from VC++ 2017. I think I should conquer the differences between compilers with some nuts.
3. Javascript: Javascript is the language of web! As soon as I'm done with my current project, I'd like to start learning vue.js and node.js(especially Express.js) and apply them to the work.
4. Kotlin: OK. Now the desktop is done, but still "mobile" remains. Kotlin is native in Android(and I strongly feel that Google pushes it harder than ever after it lost the case against Oracle), and when Kotlin/Native is copmlete iOS can be "natively" supported. It's a good choice for me, who won't touch Apple ecosystem for a few years but no idea after that.

Originally I added Python and Rust to the list, but I found out that I don't have to dig deep Python though it's used in the product I currently engineer, and I concluded that from Rust I can adopt the structure to C++ so I don't have to worry much. And I also considered Go but its structure was not of my taste......

So that's all. At present, I just want to close the current project and have some time to learn Javascript.