Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Insights from Adopting TypeScript at Scale

techatbloomberg.com

Post reply on HN
Print view View original

61–70 of 107 posts

Re: Insights from Adopting TypeScript at Scale

#61

Post by hvidgaard »

JonathonW wrote: post #7
coding123 wrote: post #5

I've seen some shops do things like this. Making their own tools to get around odd shitshows they've gotten themselves into. I suspect that there are a number of people within the org that aren't fans of Webpack or some other set of tools that would have made some of their decisions end up with the consequences in the article. They didn't quite state it but I suspect they're trying to use a specific stack instead of…

I think the key here is: > Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript Since their use of Javascript predates Node (and the rest of that ecosystem, like Webpack or Babel or whatever), they've built up their own Javascript environment that doesn't rely on Node or Node conventions at all. Not so much a "get around odd shitshows" situation as much as a parallel…

I still cannot understand why anyone would use JavaScript for server-side components. Even Python would be a better choice at that point if you could get around its multithreading limitations (and if they can build their own node, they can). Java was a well proven tech at that point.

My immediate thought is that by choosing JS, they attracted young (and cheap) developer.

Re: Insights from Adopting TypeScript at Scale

#62

Post by a_humean »

cutler wrote: post #23
lemming wrote: post #11

What is the proportion of JS libraries in the wild which provide TS type declaration files, either via DefinitelyTyped or provided by the lib itself? Is it normal to have to write your own declarations, or do most libs provide them these days?

As an outsider I'm puzzled how any TS library repo keeps up with the pace of change in TS. With JS you can more or less write it once.

The breaking changes don't change runtime behaviour, just the type checking. Its more like the the linter is getting stricter over time. Your test will still pass at runtime, but they might start failing at compile time.

Also, for the cost of dealing with a breaking linter once and a while it helps enormously with upgrading javascript libraries provided they have up to date type definitions. If an API changes you are immediately alerted to many of the places where your previous assumption are now wrong.

It also completely changes the way you write code. Often time you can just go to the leaves of your application, make the change you want, and then just follow the compiler errors all the way back up to the top. When it compiles there is decent chance that it will run successfully first time.

Re: Insights from Adopting TypeScript at Scale

#63

Post by exdsq »

yaacov wrote: post #60
robpalmer wrote: post #9

Earlier quoted context omitted.

Yes - you deduced correctly! There was a long period of parallel evolution. Over the last few years we've been able to get back on the standards track. The article describes this as one of the guiding principles. It's why we participate in TC39. Nowadays our tooling stack now uses TypeScript, Babel, Rollup & Terser which I regard as the most mainstream of choices. And we go out of our way to keep things aligned with…

Why did Bloomberg adopt server-side JS in 2005?

I really want to know the answer to this question, seems a hell of a risk to move to JS prior to Node (for me it’s still a risk even after node because JS!).

Re: Insights from Adopting TypeScript at Scale

#65

Post by agustif »

robpalmer wrote: post #21
agustif wrote: post #18

Earlier quoted context omitted.

Yeah TypeScript it's the only thing that makes me hate/doubt M$ a little less...

What about VS Code?

Yeah I use VS Code,

But yknow electron yadda yaddaa, I end up blowing it with too many plugins so it can be a little slow.

Also the telemetry...

Also although I love WSL for being able to use linux on my windows work machine, it is really slow for me. Trying to use a docker-magento image on windows under wsl gave me minute long page-loads.

I also hit a bug the other day that would put my vps server at 100% CPU when working remotely with the VSCode ssh remote extension...

So all in consideration, VS Code is Okay'ish but I'm not really a fan, for mac I like the new Nova editor from panic guys albeit it's newness that grants less community/plugins!

Re: Insights from Adopting TypeScript at Scale

#66

Post by pjmlp »

rattray wrote: post #36

Fascinating that Bloomberg started adopting server-side JS in 2005 and client-side JS only in 2012. And that they use their own deno-like JS engine.

Server side JavaScript exists since the language was introduced, Netscape had an application server that used it.

Re: Insights from Adopting TypeScript at Scale

#67

Post by robpalmer »

exdsq wrote: post #63
yaacov wrote: post #60

Earlier quoted context omitted.

Why did Bloomberg adopt server-side JS in 2005?

I really want to know the answer to this question, seems a hell of a risk to move to JS prior to Node (for me it’s still a risk even after node because JS!).

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.

Re: Insights from Adopting TypeScript at Scale

#68

Post by didibus »

> Back in 2005, the company started migrating those apps from Fortran and C/C++ to server-side JavaScript, with client-side JavaScript arriving around 2012

Okay, I need another article about why in 2005 they chose to rewrite everything to server side JavaScript? That seems like, I don't want to say a bad decision that also led to all the issues and effort this article describes, but it kinda seems like it. In any case, it seems like an odd choice to make, especially in 2005, and especially coming from a fortran/c++ code base. So would love to hear about that and a retro on it.

Re: Insights from Adopting TypeScript at Scale

#70

Post by cryptica »

Roboprog wrote: post #20
darksaints wrote: post #3

Oh wow they went from C/C++ to JavaScript? That's just trading one dangerous footgun for another. Glad to see they finally found a better tool. I can't function in JavaScript without Typescript...I constantly have to be looking up docs cause I don't have intellisense, and once something works I'm terrified to ever touch it again. Typescript made front end development reasonable again...not perfect, but not so patheti…

That seems to be pretty common statement about JavaScript, but strangely not one I share. I have been programming since the early 80s, and my experience with JS has been pretty positive, especially compared to the slog through the unreadable mud that is enterprise Java. (If I was going to rage quit on something, it would be the verbose, obtuse, repetitive Java sludge I’ve had to read the last decade and a half) Types…

What I've found is that senior developers with 10+ years of experience with many different paradigms and projects tend to enjoy JavaScript and many hate TypeScript (particularly because of the build step and complexity that it brings). But for some reason Microsoft is running a lot of propaganda campaigns to promote TypeScript. My guess is that they're trying to push all the JS devs to TS and then once they have enough adoption, they can slowly start diverging from JS standards and take ownership of the ecosystem - This is an old Microsoft trick.
Post reply on HN