131–140 of 147 posts
I switched this year to working at a company who uses typescript for backend systems after working as a python dev for 3 years. It’s not that I hate it, it’s just that TS/JS does not give you anything in terms of built-ins. This testing suite is so fragmented, it’s this ugly thing that I dread working with. Anyone have advice for repos I can use that have rich testing frameworks? Or books? I’d love to learn to love T…
The number one problem with typescript is how slow it is. Compiling a 14k line project takes 5s. This is absurdly slow.
Earlier quoted context omitted.
> TS is known to produce app bundles that perform slower than handwritten JS code Wrong. TS doesn’t bundle files. TS doesn’t produce code unless you target an earlier ES version than what you write, in which case there’s no way around it: native for-of loops and await/async will always be faster regardless of what you use to transpile it. I think you’re confusing the tool with something else.
Ts does produce code, ie. for enums, modules/namespaces.
Turning `export function a(){}` into `exports.a = function a(){}` hardly qualifies as generated code, much less "slower than hand-written"
Earlier quoted context omitted.
I liked AS3 quite a bit, but it was limited to Adobe products. I don’t think it was ever given a chance to make an impact beyond Flash and Air.
Well no it wasn't limited to Flash, since it was supposed to be ES4. This is why ES4 doesn't exist as a standard, Javascript went from ES3 to ES5.
I think MS, who had a browser monopoly at the time, was never going to agree to something that made Adobe Flash more important. It seems crazy now, but at the time it seemed like a real possibility that browsers could end up mere shells for the real internet runtime, Flash Player.
am I the only one who hates typescript?... development time is extended because you need to create all the types / interfaces for every variable and function. And you blow up the already complex / almost unreadable code with type definitions. Some of the definitions can be very complex, a dev needs time to decrypt what other dev wrote and what I can finally use as a parameter in a function. Sometimes even if you put…
I don't "hate" TS. I understand how useful it can be. But I don't enjoy working with TS code - especially in large codebases which have been touched by many developers, each with their own understanding of how to use TS. When it comes to the world of professional web development it's up to me to adapt to the project's coding requirements, not the other way around.
Earlier quoted context omitted.
Well no it wasn't limited to Flash, since it was supposed to be ES4. This is why ES4 doesn't exist as a standard, Javascript went from ES3 to ES5.
I'm aware of how they were related... AS3 was based on ES4 ideas, and, as the major implementation of ES4, AS3 influenced the evolving direction of ES4. But ES4 was never really finished to the point where everyone who needed to actually agreed on it. I think MS, who had a browser monopoly at the time, was never going to agree to something that made Adobe Flash more important. It seems crazy now, but at the time it s…
type Foo = { prop1?: number; prop2: string; prop3?: boolean };
I'm sure there is some value to having this than not having it at all, but I find it hilarious the amount of times I'm writing TypeScript that I can't even trust the types given to me. Of course this isn't a fault of TS itself, but I think what TS has inadvertently done is give programmer yet another outlet to express their bad habits.
Earlier quoted context omitted.
This is closer to my opinion. I write a fair amount of Typescript, but it's frustrating to see it used so ubiquitously, when in a lot of cases it's just not necessary. A strongly typed language definitely has a place in web UI development though. But my hope is to see it replaced by a WASM based language, or better still, a choice of WASM based languages.
In what cases do you see it when when not necessary?
Granted, a checkout, or a clinical case management form (for example) will definitely benefit from the kind of precision a strong type system will encourage.
Beyond that, we should think more about the how and why, because type wrangling can slow down delivery, experimentation, and cannot guarantee the prevention of bugs.
Gmail and Google Maps for example, at least when those projects started out, had no TypeScript in their UI code.
Google Maps, even in it's earliest iteration, far outstrips the complexity of most TypeScript applications in the wild today. And also has a greater requirement for precision than many of the applications that we can call to mind, outside of Finance, Transport, Construction, or Medicine.
People seem to talk as though certain applications were impossible to build without without TypeScript, but that is simply not true.
So TLDR, answering the root of your question, TS is not at all necessary. But it can be helpful. Yet we're in a position now where it's almost intractable, and I don't think that's an ideal situation.
Earlier quoted context omitted.
Yes, that's exactly right. I just include pixi.min.js which exposes the "PIXI" global variable. > If that's the case, you could add the libraries .d.ts to your project and augment the global.Window interface Do you know where I can find an example of this? I've been able to do "npm install pixi.js", which gives me access to the .d.ts file but I'm not sure how to then map those types to the global PIXI object exposed…
Here is a minimum "repro" of your use case: tsconfig.json { "include": ["index.d.ts"], "compilerOptions": { "target": "es2015", "lib": ["es2015", "dom"], "moduleResolution": "node", "allowSyntheticDefaultImports": true } } index.d.ts import * as PIXI from 'pixi.js' declare global { interface Window { PIXI: typeof PIXI } } index.ts console.log(window.PIXI) There is still an import but because it is in the .d.ts file i…
Great post/looking back at the core decisions/bets that worked out really well (from the post): * "Impose no runtime overhead on emitted programs." * "Align with current and future ECMAScript proposals." * "Preserve runtime behavior of all JavaScript code." * "Avoid adding expression-level syntax." * "Use a consistent, fully erasable, structural type system." I also really liked the callout of their approach to "inno…