7 ms·

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 o

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 a more obvious stack to make typescript work. edit: just adding though, that this isn't surprising with a dev base of 2000 js developers.

kristaps 6y ago
The article mentions they have around 2000 engineers, at that scale investing in custom tooling can easily become a significant net gain in productivity and stability, especially when dealing with the JS ecosystem.
- robpalmer 6y ago
  Agreed. The article touches on this. When you have hundreds of projects that all target the same tightly-managed evergreen runtime, there's not much justification for having each project select and maintain a different toolchain. It just leads to the same problems being solved over again, and makes it harder for developers to switch between projects. The fact that we can consider high-quality sourcemaps a solved problem (during both debugging and consolidated crash telemetry) really helps developers focus on building functionality rather than debugging a build system. I think most large companies have dedicated tooling teams for these kinds of reasons. A related viewpoint in a related thread: https://www.reddit.com/r/typescript/comments/jrgi8z/10_insights_from_adopting_typescript_at_scale/gbu75vh/ https://www.reddit.com/r/typescript/comments/jrgi8z/10_insig...
JonathonW 6y ago
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 evolution.
- robpalmer 6y ago
  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 ECMAScript, e.g. preventing the use of "experimentalDecorators".
  - jgalt212 6y ago
    Bloomberg often gets accused of "not invented here" syndrome. But often times in the past, it's been the case that what they need hasn't been invented yet.
    - munificent 6y ago
      Would that make it "invented here" syndrome?
      - erikerikson 6y ago
        Traditionally NIH is the reason for rejecting things. The inverse would be accepting things because they are invented here.
    - ng12 6y ago
      This is endemic in the finance industry. Build something cutting-edge, rake in a bunch of money, and then let your tech rust.
  - yaacov 6y ago
    Why did Bloomberg adopt server-side JS in 2005?
    - exdsq 6y ago
      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!).
robpalmer 6y ago
It's more about setting up the guard-rails ahead-of-time to avoid falling into a hole, rather than getting out of one. We know the way to do this is to stick to standards like ECMAScript. ES Modules are the glue that binds the whole JS ecosystem together. Whilst ESM is the standard, today a lot of people are using ESM only as an authoring format that later gets converted to CommonJS before being published or executed. Many of today's tools rely on this, meaning the ecosystem is partially tied to CommonJS. Migration is happening but it's slow and non-trivial. In a way, we bypassed the CommonJS era and skipped directly from AMD to ESM. AMD and ESM are pretty much isomorphic and differ only in syntax. You just run a codemod to get from AMD syntax to ESM syntax - semantics are preserved. Whereas the step from CommonJS to ESM does not fully preserve semantics. CommonJS module initializers are always synchronous. ESM can be asynchronous - you can use `await` in the module initializer. The article covers a few of the things we've done to retain a very standard ES Module system that is ECMAScript compliant. I think it is this pursuit of standards and desire for robust interoperable packages that led to some of the surprising discoveries.
cryptica 6y ago
Corporations seem to be desperately trying to create more jobs at the moment. TypeScript, by being less efficient and adding complexity, allows massive job creation to take place. Nothing to do with bugs, efficiency, etc... It's all about job creation so that companies can justify receiving more, bigger government contracts and loans on favorable terms from banks and they get more political influence by coercing their employees into voting for specific candidates (more headcount = more voting power).
- robpalmer 6y ago
  Busted. It's true. The Big TypeScript lobby has been secretly working for years on a product called TypeScript Enterprise Edition. Many jobs will be created to support all those AbstractVirtualFactoryManagers. Undeniable evidence: https://twitter.com/drosenwasser/status/1259946589902106624 https://twitter.com/drosenwasser/status/1259946589902106624 This is just as serious as Bjarne Stroustrup's famous leaked interview in which he revealed why he created C++: https://www.stokely.com/lighter.side/stroustrup.html https://www.stokely.com/lighter.side/stroustrup.html

kristaps 6y ago

The article mentions they have around 2000 engineers, at that scale investing in custom tooling can easily become a significant net gain in productivity and stability, especially when dealing with the JS ecosystem.

robpalmer 6y ago
Agreed. The article touches on this. When you have hundreds of projects that all target the same tightly-managed evergreen runtime, there's not much justification for having each project select and maintain a different toolchain. It just leads to the same problems being solved over again, and makes it harder for developers to switch between projects. The fact that we can consider high-quality sourcemaps a solved problem (during both debugging and consolidated crash telemetry) really helps developers focus on building functionality rather than debugging a build system. I think most large companies have dedicated tooling teams for these kinds of reasons. A related viewpoint in a related thread: https://www.reddit.com/r/typescript/comments/jrgi8z/10_insights_from_adopting_typescript_at_scale/gbu75vh/ https://www.reddit.com/r/typescript/comments/jrgi8z/10_insig...

JonathonW 6y ago

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

robpalmer 6y ago
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 ECMAScript, e.g. preventing the use of "experimentalDecorators".
- jgalt212 6y ago
  Bloomberg often gets accused of "not invented here" syndrome. But often times in the past, it's been the case that what they need hasn't been invented yet.
  - munificent 6y ago
    Would that make it "invented here" syndrome?
    - erikerikson 6y ago
      Traditionally NIH is the reason for rejecting things. The inverse would be accepting things because they are invented here.
  - ng12 6y ago
    This is endemic in the finance industry. Build something cutting-edge, rake in a bunch of money, and then let your tech rust.
- yaacov 6y ago
  Why did Bloomberg adopt server-side JS in 2005?
  - exdsq 6y ago
    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!).

robpalmer 6y ago

It's more about setting up the guard-rails ahead-of-time to avoid falling into a hole, rather than getting out of one. We know the way to do this is to stick to standards like ECMAScript. ES Modules are the glue that binds the whole JS ecosystem together. Whilst ESM is the standard, today a lot of people are using ESM only as an authoring format that later gets converted to CommonJS before being published or executed. Many of today's tools rely on this, meaning the ecosystem is partially tied to CommonJS. Migration is happening but it's slow and non-trivial. In a way, we bypassed the CommonJS era and skipped directly from AMD to ESM. AMD and ESM are pretty much isomorphic and differ only in syntax. You just run a codemod to get from AMD syntax to ESM syntax - semantics are preserved. Whereas the step from CommonJS to ESM does not fully preserve semantics. CommonJS module initializers are always synchronous. ESM can be asynchronous - you can use `await` in the module initializer. The article covers a few of the things we've done to retain a very standard ES Module system that is ECMAScript compliant. I think it is this pursuit of standards and desire for robust interoperable packages that led to some of the surprising discoveries.

cryptica 6y ago

Corporations seem to be desperately trying to create more jobs at the moment. TypeScript, by being less efficient and adding complexity, allows massive job creation to take place. Nothing to do with bugs, efficiency, etc... It's all about job creation so that companies can justify receiving more, bigger government contracts and loans on favorable terms from banks and they get more political influence by coercing their employees into voting for specific candidates (more headcount = more voting power).

robpalmer 6y ago
Busted. It's true. The Big TypeScript lobby has been secretly working for years on a product called TypeScript Enterprise Edition. Many jobs will be created to support all those AbstractVirtualFactoryManagers. Undeniable evidence: https://twitter.com/drosenwasser/status/1259946589902106624 https://twitter.com/drosenwasser/status/1259946589902106624 This is just as serious as Bjarne Stroustrup's famous leaked interview in which he revealed why he created C++: https://www.stokely.com/lighter.side/stroustrup.html https://www.stokely.com/lighter.side/stroustrup.html