robpalmer

8 ms·

1.
by robpalmer 6mo ago
The article and (overall) this comments section has thankfully focused on the problem domain, rather than individuals. As the article points out, there are competing philosophies. James does a great job of outlining his vision. Education on
2.
by robpalmer 6mo ago
Congrats, all. The web has always needed a simpler tooling story, not just an easier one. And the credentials for this attempt are far more favourable than previous attempts. Glad to see Vite+ is now MIT licensed. That will immensely help
3.
by robpalmer 6mo ago
Yep. You can learn more about why we created this new blog here: https://bloomberg.github.io/js-blog/post/intro/ I hope you like it ;-) And if it seems like a surprise, you can blame me for not publicisi
4.
Temporal: The 9-year journey to fix time in JavaScript(bloomberg.github.io)
790 points by robpalmer 6mo ago|266 comments
5.
Source Maps: Shipping Features Through Standards(bloomberg.github.io)
9 points by robpalmer 6mo ago|0 comments
6.
by robpalmer 1y ago
Congrats to the Boa team! It's great to see an independent open source project thrive and become more widely useful. This is huge impact. On the integration with Kiesel and Chrome, I'm pleased to see that engines/browsers ca
7.
Node LTS now supports TypeScript(nodejs.org)
1 points by robpalmer 1y ago|1 comments
8.
by robpalmer 3y ago
Bloomberg are currently sponsoring Igalia to work on adding native Decimal number support to JavaScript. https://github.com/tc39/proposal-decimal This is an active proposal and was last discussed in the September 2023
9.
Bloomberg invests in Node.js – Shouldn't you?(nearform.com)
1 points by robpalmer 3y ago|4 comments
10.
by robpalmer 4y ago
>Once it is part of the language, that will help a lot :) If you want to follow along, the proposal to allow type syntax to be part of JavaScript is here: https://github.com/tc39/proposal-type-annotations (To repeat
11.
by robpalmer 5y ago
The FAQ addresses this: https://github.com/giltayar/proposal-types-as-comments#shoul... https://github.com/giltayar/proposal-types-as-comments#shoul... The idea is to avoid hampering competition,
12.
by robpalmer 5y ago
#private fields are not slow when used natively. It's true the down-levelled code that uses WeakMaps is slower. The decision to downlevel is in the hands of the user and is controlled by the tsconfig "target" option. The only
13.
by robpalmer 5y ago
You're looking at down-levelled code. Babel and esbuild would equally produce similar code. This is not a TypeScript issue. If you want "native" JS output, use the tsconfig option... "target": "esnext
14.
by robpalmer 5y ago
TCO is coming to V8? Is there a source for this?
15.
by robpalmer 5y ago
There is at least one more Evan working in this space who should be on that list. Evan Martin created the Ninja build system and works on making JavaScript builds fast at Google. He has blogged about it here: http://neugierig.org
16.
by robpalmer 6y ago
This is interesting. The things you list as problems are the same set of things we tried to solve: - automatic compilation that is fast - sourcemaps work - decoupling of packages to help compatibility - automatic tsconfig management I wond
17.
by robpalmer 6y ago
I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions
18.
by robpalmer 6y ago
For our purposes, the primary problem with enums is not the runtime overhead. The runtime code for TS enums is a little verbose but it's not huge. The semantics are a little wacky as described in Axel Rauschmeyer's article: ht
19.
by 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
20.
by robpalmer 6y ago
The scenario you are describing (TypeScript diverging from JavaScript) is unlikely in my opinion. Orta, a member of the TypeScript team, describes the reasons why in his video "How Does the TypeScript Team Try to Avoid Negative Effect
21.
by robpalmer 6y ago
I can empathize with this view. JavaScript is bound by backwards compatibility. It is expressed by the soundbite "don't break the web" . I would love for typeof null to not be "object" , and it seems appealing
22.
by robpalmer 6y ago
Thanks for the feedback - I'm pleased you enjoyed it. It's true the codebase has some gnarly advanced types (generic, conditional, mapped) for expressing types for constructs created prior to TypeScript being introduced. I suspe
23.
by robpalmer 6y ago
No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.
24.
by robpalmer 6y ago
Yes, you're right the JS@Bloomberg origin story deserves to be told in full. Probably by Andrew Paprocki. SpiderMonkey has a starring role. Until then this is as much as I can share right now: https://news.ycombinator.co
25.
by robpalmer 6y ago
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 somet
26.
by robpalmer 6y ago
That's a very real trade-off and something we have to carefully make a judgement call on every time. In this specific case the decision is made a lot easier due to the fact that string unions are often a simpler alternative. type
27.
by robpalmer 6y ago
The server-side JS architecture created in 2005 was presented at JSConf 2011 by Andrew Paprocki. https://www.youtube.com/watch?v=ODgs0eWAIKc The talk describes the system architecture and shows how the IDE is used to create
28.
by robpalmer 6y ago
Glad to hear you are finding TypeScript useful too! Just to expand on the conversion, whilst all of our apps (and hundreds of services) were migrated from C++ to JS, we still have much more C++ on the backend than we do JS. Thankfully it i
29.
by robpalmer 6y ago
I would never say never for any potential ECMAScript feature. Each time people say "JS will never do x", a few years later it does. Brendan Eich has a slide on this. https://www.slideshare.net/BrendanEich/js
30.
by robpalmer 6y ago
The majority of breaks are due to the checker getting better. So code that passed now errors. Most of the time pre-existing published DTS files still operate fine.

More ›