41–50 of 107 posts
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.
Earlier quoted context omitted.
There isn't much of a difference between regular enum and const enum when it comes to the usage of the enum keyword. The big difference is what they compile to - where const enum evaporates by inlining the values into the usage sites. enum is a keyword that is reserved in ECMAScript and therefore may one day clash with TypeScript. It's unlikely any ECMAScript-defined semantics for enum would match today's TypeScript…
Interesting. So even though the const form isn’t affected by the same runtime considerations, you do still prohibit it because of the potential conflict with a future use of the enum keyword by JS? I can understand the reasoning there, particularly at the scale you’re operating at. I wonder how likely it is that ECMAScript would introduce its own incompatible form of enum now that TS has become so popular. With stati…
https://www.slideshare.net/BrendanEich/jslol-9539395/110-Alw...
In terms of whether JS will introduce things that conflict with TS, it's hard to say. TypeScript team themselves are active participants in TC39, championing recent features such as Optional Chaining and Nullish Coalescing. So if there were any conflicts, or even opportunities for confusion, it would all be managed way ahead of time. Several TC39 delegates are users of TypeScript so there is no risk of accidents here (in my opinion).
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…
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 is not a language monoculture ;-)
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.
https://www.youtube.com/watch?v=ODgs0eWAIKc
The talk describes the system architecture and shows how the IDE is used to create applications.
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…
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.
Earlier quoted context omitted.
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…
> I hope TS doesn’t turn JS into Enterprise Java, The Next Generation. No chance. And frankly, I don't get the comparison you are making to C++/Java/C#. TS is fundamentally different than those languages. From structural typing to a default functional/imperative paradigm, it really is just JS with better static analysis. Your IDE is not as good for JS as it would be for TS. The entire impetus for TS is/was to provide…
Earlier quoted context omitted.
Interesting. So even though the const form isn’t affected by the same runtime considerations, you do still prohibit it because of the potential conflict with a future use of the enum keyword by JS? I can understand the reasoning there, particularly at the scale you’re operating at. I wonder how likely it is that ECMAScript would introduce its own incompatible form of enum now that TS has become so popular. With stati…
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/jslol-9539395/110-Alw... In terms of whether JS will introduce things that conflict with TS, it's hard to say. TypeScript team themselves are active participants in TC39, championing recent features such as Optional…
Sure, and again, at the scale in your organisation, taking an absolute position on this makes a lot of sense and I can respect the principled stance.
On the other hand, the trade-off in this case is giving up a tool that is widely useful immediately in exchange for a potential/hypothetical benefit later. For other development teams, perhaps those alternatives would be weighted differently. And then that in turn might affect how any future changes were viewed by the relevant language committees, who as you say would surely be aware of the implications.
Anyway, thanks for sharing your insights, both here and in the original article. It’s somehow reassuring to me that I’m not the only person in the world who wants their front-end code to continue working for more than five minutes, when it seems like a lot of the front-end community would consider that a pretty good working lifetime for code these days!
Earlier quoted context omitted.
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/jslol-9539395/110-Alw... In terms of whether JS will introduce things that conflict with TS, it's hard to say. TypeScript team themselves are active participants in TC39, championing recent features such as Optional…
I would never say never for any potential ECMAScript feature. Sure, and again, at the scale in your organisation, taking an absolute position on this makes a lot of sense and I can respect the principled stance. On the other hand, the trade-off in this case is giving up a tool that is widely useful immediately in exchange for a potential/hypothetical benefit later. For other development teams, perhaps those alternati…
type Color = "red" | "green" | "blue";
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.
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 applications.
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.