Kaali

Abstractions need proper names and meaning. In this example the "abstracted" version would be a lot simpler if the names of the functions would be 'doB()', 'doC()' etc. and it is still hard to make sense of as A, B, C, D, E as an example doesn't really have an obvious meaning. Just an order. But if the main function describes a process that must happen in a specific order, then by all means keep the code in the single function if it makes it more clear.

Monadic error handling is quite nice for domain specific errors, but for exceptional situations which are not supposed to happen, you still need some sort of an exception system. And even with domain error conditions, exceptions has a nice property of saving a stack trace, which can make error hunting a bit simpler.

In Finland we call it "kissanhäntä" (cat's tail) or "miukumauku". "Miu" and "mau" are actually cat's meows, so "miukumauku" is kind of a "a meow, a meow" with two different words.

Nowadays it's usually called "ät-merkki" as in "at-sign" as "at" is spelled in Finnish.

Unity is the most popular engine at the moment. Saying that it is the best is going a bit far. I actually think that Unity is one of the best 2D engines available. For 3D the tools are really broken for production use, and Unity is quite unresponsive about fixing them. And the renderer quality is a bit of a far cry from CryEngine or Unreal Engine, but is getting there bit by bit. Except that those two are also progressing, mostly by doing actual new research in the field.

Still, new 2D engines are welcome as Unity still has the 3D package to work with in a 2D game.

True. I shouldn't have been that dismissive about React. My comment was really related to the explosion in popularity of client side rendered static websites. And React happens to be one of the more popular ways to implement them.

This is a great example of a modern looking website, that actually performs in a way one would expect from today's computers and browser optimizations. Instead it seems to be more important for developers to use the coolest new technology, even though it actually hurts the end-users.

React is all the hype right now. And it is a nice system for creating dynamic single page apps. But there is little reason to use it for static websites, which could be cached easily, instead of rerendering the website on the client with Javascript. And instead of having automatically cached static website, we use local storage and such to get something resembling a cache.

I would love to see some mechanical sympathy in modern web development, instead of cargo culting all the new tech.

There are women in the calendar.

Node.js is in an interesting position. There is a lot of libraries and new ones are coming out at breakneck speeds. It's also a way for frontend developers to transition to backend tasks. And it gets a lot of mindshare at the moment, with MongoDB and microservices.

But in my opinion a lot of Node.js ecosystem is a lot of mismarketed features. Many developers doing backend services with Node.js actually think that it's the fastest thing available, even though multiple benchmarks, e.g. techempower, shows that it really isn't. And even more people seem to think that it is a way to do simple parallellism, so they won't have to understand threads and locking, which are really complicated stuff. But as many have said here, Node.js does not support threads, or parallelism without running multiple different processes. Which can be fine if you don't have any shared state between your processes. And with no parallelism in process, it is quite easy to actually block the event loop by running anything that is CPU and not IO bound. This can be a loop that is too long, too much math, or even parsing a JSON string without using streams. All of these can block the event loop, which means that no requests are going through that process while one request is parsin a JSON.

And even though there is a lot of libraries and frameworks for it. The quality is often really, really bad. As in invalid MD5 algorithm bad, etc. But there are also some gems such as Bluebird for promises, which makes the callback hell more easier to handle.

You will also face immature debug support, profiling and static analysis. You barely get any refactoring help from your tools, even though IntelliJ IDEA does quite a good job with basic refactoring and debugging. And you will have to spend time with handling odd bugs with no logs showing up on crash, or stuck processes when something has gone really wrong in the code, with no way of knowing (if you don't have DTrace) where the code is stuck.

But there are stuff Node.js seems to excel at. It is really quick for creating a simple REST service, feedback loop is really quick as the services restart almost immediately (at least when you don't use all the latest ES6 transpilers). And if you want to create isomorphic applications, where the server can render a Javascript site on behalf of the browser for the first request, or even successive requests for mobile use, there is no better platform than Node.js. And if you know that you will not do anything that is CPU bound, just IO bound stuff, you can still use any library available. Where for example in Java or Python, you would have to find specific libraries that support your chosen async IO framework.

I would use Node.js between a backend server done in a more robust ecosystem such as JVM, and the browser. Where Node.js gets the data from the backend and does it's magic with isomorphic React for the client.

Accessibility is a point I didn't think about at all. Thanks for reminding me, it's really something that is all too often forgotten. JavaFX supports ARIA and all standard controls have accessibility built-in. But I have no expertise to actually comment on the quality of accessibility features in JavaFX.