A lot of cool things have happened in the last year or so that really get me excited. We got to see .NET core reach all new platforms; TypeScript has quickly become my favorite language; we saw Angular 2+, React, Webpack and other awesome tools bring the web into the next generation. Five years ago, I wasn't a big fan of web development -- it seemed way too chaotic for my tastes. It took some time, but now I love that chaos! It doesn't bother me that my node_modules folder contains over 22K files.
I would be extremely happy if I spent 100% of my time programming in TypeScript by 2020. I have some wild dreams about what would enable that possibility. One possibility is I switch to using Node.js for all of my backend coding, foresaking more than 10 years of C# experience and the awesome power ASP.NET Core promises. I take the .NET framework for granted -- I know -- I worked in Python for 4 months and was constantly annoyed how disconnected all the libraries felt. The JavaScript community sees a lot more churn, though, resulting in something bigger and better coming around constantly. For example, one of the brilliant minds behind moment.js just introduced luxon, which may be the next big thing for dates and times in JavaScript (which is no small statement).
Doing some research last week, I stumbled across Node's N-API and Node-ChakraCore. N-API is an experimental API that aims to isolate Node from the underlying V8 engine, freeing native module developers from painstaking upgrades every time there's a major update to Node or V8. They're hoping to push it even further, porting it back to older versions of Node so newer versions of modules rewritten to use N-API will run on older versions of Node as well. Supposedly, they're hoping to move N-API out of experimental mode by the time Node 10 comes out and have already shown perfect support for the top 30 most-used native modules in use today. There's a massive effort underway to help existing module maintainers upgrade.
There's another, farther reaching advantage to isolating Node from V8... it might make it easier to run Node on other JavaScript engines. That's a big deal. Quite a while ago, Microsoft introduced Node-ChakraCore as a thin shim to translate calls to the V8 engine into equivalent calls to their ChakraCore JavaScript engine (used in the Edge web browser). In many cases, ChakraCore outperforms V8 on Windows machines. The obvious next step is to drop the shim entirely and directly run Node on ChakraCore. My hope is in the next year or two we will see Node running not just directly on ChakraCore, but also SpiderMonkey and JavaScript Core. If you don't already know, JavaScript Core is the JavaScript engine running in Safari and used to power iOS applications written in JavaScript (e.g., React Native). Imagine running Node directly on your iPhone!
I have a fuzzy, heart-warming feeling that in a not-too-distant future I will be able to work in Node.js and/or TypeScript without completely foresaking .NET. This is completely speculative, but I sincerely hope a JavaScript engine comes along that runs on top of (or provides access to) .NET core. To me, this seems like a natural evolution, on par with JPython or IronRuby.
I played around with N-API myself. This API is exposed using C classes. Being a C++ buff, I was glad to see there is already a nearly zero-overhead C++ library called node-addon-api. With relatively few lines of code and using node-gyp, I was able to expose some simple functionality to the rest of a Node application. As someone who learned to program using C++ (and an otherwise avid fan of the language), it was really refreshing to get to use those skills again. Needless to say the gap between Node and C++ is beautifully thin. And the development tools are stupid easy, too.
C++ has had it's victories this year, as well. Microsoft made great strides in introducing a module-based compilation model for C++ (https://blogs.msdn.microsoft.com/vcblog/2017/05/05/cpp-modules-in-visual-studio-2017/). These modules are similar in nature to Java packages, Python packages or ECMAScript modules, using export and import to control what classes are exposed to the rest of a library as well as simplify the compiler's job of determining dependencies. This is a major step forward for C++, dramatically simplifying how development will be done in the future. Rather than inlining #include-ed files, the compiler can "understand" the relationship among modules to cut down on rebuilding code. It also cuts down on the need for separating code/header files, nameless namespaces and worries about global namespace pollution. It will also make it easier for tool makers to support intellisense and syntax highlighting. Along with the language and standard library enhancements that came with C++-11, -14 and -17, this makes C++ a language I want to spend my time working in again.
There's something magical here. I feel like the gap that separates web development, embedded development, mobile development and so on is closing. I don't feel so shackled to my desktop. Similar to Python, Node can act like the glue that ties together native APIs for embedded systems or makes calls out to native UI controls on mobile devices. It can be used to build out web pages or used to host them. TypeScript is allowing me to build monster-sized applications quickly and safely. Very soon, I may be able to satify my desire to work in C++ without the fear or shooting myself in the foot or becoming a massive time-suck. All my passion let loose in a much bigger world to explore.