6 ms·
Perhaps some people don't want to touch JS/TS
by h8hawk 2y ago
Perhaps some people don't want to touch JS/TS
- mapcars 2y agoTS is actually has better typing than Python (mypy). And the whole React (Vue, etc) infrastructure around it. Without these two things I wouldn't even bother writing frontend code.
- pphysch 2y agoThe browser doesn't support TS though. The browser does support Python via PyScript/pyodide/etc. You can't run TS in the browser unless you jump through the same hoops that PyScript is.
- wiseowise 2y ago‘npx vite build’ is what you call hoops?
- pphysch 2y agoYou can offline transpile anything to JS to later run in the browser, TS isn't special in this way. With PyScript you can see and modify the actual code in your browser, just like vanilla JS.
- pjmlp 2y agoYet, type annotations are being discussed for JavaScript, eventually the browsers will be running Typescript.
- pphysch 2y agoThe browsers are already running anything via custom WASM interpreters, like Pyodide for Python.
- pjmlp 2y agoWith a huge performance hit and leaky abstractions.
- infamia 2y agoI thought I read somewhere that the Chrome team tried typed JS, found out that there was a performance hit, and they ended the experiment? Is this a continuation of that or a new effort? Sounds interesting.
- pjmlp 2y agoMaybe as part of the Flutter/Dart sales story? Here is the current status of the standard proposal. https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/
- infamia 2y agoIdk they're just different tradeoffs to me. Types are real and enforceable at runtime in Python (e.g, pydantic). Types in TS/JS are a fake veneer that add a build step. Is that categorically better? I don't love Python typing syntax.
- mapcars 2y agoI want my types to be verified before runtime, what should I do with type error at runtime? Yes it will leave me a better error message in logs, but build-time type check will prevent me even rolling this code out. So yes, its categorically better.
- infamia 2y ago> I want my types to be verified before runtime, what should I do with type error at runtime? It is weird to me you cannot think of uses for types and handling their errors at runtime. Look at projects like FastAPI (which uses pydantic) for an an example where having types at runtime has been handy. Also, if types are enforced at runtime logging is better, debugging is better, and you have more options for data validation and doing dynamic or metaprogramming likely more easily because you can evaluate these things at runtime. By types being built in, the language gives you a richer set of tools to work with and more options when and how to enforce types.
- mapcars 2y ago> Look at projects like FastAPI (which uses pydantic) for an an example where having types at runtime has been handy. What is it, they have nice error messages? I don't expect them to fix code at runtime when type error happens. > Also, if types are enforced at runtime logging is better, debugging is better These can't even happen with type checking in the first place. > you have more options for data validation In my experience serializing/deserializing data is pretty much the only place where its useful, and it doesn't have to be built-in on a language level, Pydantic is doing it well enough. > doing dynamic or metaprogramming likely more easily This is where you lose me, I have never seen it being useful in reasonable large projects in popular languages. Dynamic or metaprogramming only works in a very specific category of languages (lisp-likes), doing it in any other language will become a problem sooner or later. > more options when and how to enforce types Again its only on serialization level, apart from that type checking will cover everything before runtime, it's weird to me how you can think that encountering problem later has any advantage of doing it earlier.