Hacker News new | ask | show | jobs
by SiVal 2051 days ago
It wasn't an option back then, but now, if you wanted both a typed language and rapid code-build-run-debug for the server side, you could go even faster and simpler (snappy single-step compile to native executable) with Go. If you were starting now, would that work even better for you, or would other benefits of server-side JS outweigh the more complex toolchain and deployment?
1 comments
apaprocki 2051 days ago
One benefit of working with JS is that it was an easy transition to providing both client-side and server-side JS within the same application/project. Go would work on the server, but integrating it into a native MSVC Windows app, yet alone Chromium, would be... not fun.
link
SiVal 2050 days ago
This seems to imply something about the client side of your strategy that I wasn't aware of (but maybe I should have realized) that probably matters: that your clients will (almost?) all be Windows machines running the new-MS-strategy MSVC native apps written (at least partly) in JS, where "JS" on Windows now (as in Node) means Chromium specifically.

In a situation where you get to build the client all the way to the hardware, you're like Apple. You can probably get more advantage than most by matching client and server more deeply than the usual talk-to-the-API level. In your case, it sounds as though it's Microsoft's TS-in-Chromium spanning both.

link
apaprocki 2048 days ago
Yes to Chromium, not so much for anything specifically MS-related. Using Chromium as a low-level GDI replacement lets you leverage higher-level constructs and work in web-space to implement rendering, and TS nicely spans between client-side Chromium and server-side V8.

Note -- it doesn't need to be specifically Chromium or specifically Node. It just so happens that Node bet on V8 and Chromium is embeddable, so you can get even more leverage out of using the two together. (We actually also use TS with server-side Spidermonkey as well, so TS has definitely proven itself as a better way to interop at the tooling level across these different implementations.)

This all comes with a Titantic-iceberg-sized caveat, however. Keeping up with Chromium is difficult. Any embedder is not Google and embedded use cases are not the web. You can leverage all the collective work put into making the web work quickly, but you have to back it up with your own resources to leverage the source and make changes and contributions where necessary.[1] It's definitely a balancing act!

[1]: https://github.com/bloomberg/chromium.bb/branches/active

link