undefined | Better HN

0 pointsrobpalmer5y ago0 comments

In the early 2000s it was recognized that the C/C++ code-build-run-debug development feedback loop was taking too long for efficient application development. 10-30 minutes to try out changes. It would have been risky not to try something new.

JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.com/watch?v=ODgs0eWAIKc

The main competing technology at the time was Lua which would probably have been a fine alternative. JS won. Four years later Node was released which took server-side JS to a mainstream audience and helped validate the choice. Ten years later saw the ES6 renaissance and the rise of JS as a credible language for application development. Now TypeScript takes it to the next level, enabling large robust systems to be efficiently built using JS.

I'm pleased we bet on JS.

0 pointsrobpalmer5y ago0 comments

JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.com/watch?v=ODgs0eWAIKc

I'm pleased we bet on JS.

0 comments

5 comments · 2 top-level

SiVal5y ago· 2 in thread

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?

apaprocki5y 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.

SiVal5y 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.

1 more reply

0x4454425y ago· 1 in thread

> The main competing technology at the time was Lua

The main competing technology for what exactly? I could easily think of 10 other server side choices off the top of my head from the 2005 time frame; like Java or C# to name a couple. Something is missing here.

addicted5y ago

Interpreted languages with no compile time it seems.

j / k navigate · click thread line to collapse