I’m choosing the third side: WebAssembly
Blazingly fast 🦀🦀🦀
You can even compile Fortran code to wasm and run it on a web browser. Who need Javascript’s puny 64bit floating point precision when you can have Fortran’s superior 128bit floating point precision?
I’d rather stay out of the frontend all together but I’d rather chop my balls off than go back to JS.
Plot twist: You are transgender and love working with JS
vanilla javascript? what are you, fucking Amish?
TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.
I dunno, Typescript can be nice at times but it always feels like I’m bolting on something that doesn’t belong on top.
I’ll still use it for now. Not sure JSDoc is as adequate for an enterprise app for me. I know Svelte and stuff do, but I’ll wait and see.
I’m not on Twitter, what’s happening?
I think there’s a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.
That’s not a positive, though.
Depending on how it pans out, it’s either not useful enough. Who the hell doesn’t use namespaces or enums. Or - as
These constructs are not in the scope of this proposal, but could be added by separate TC39 proposals.
implies - a door opener to outsource TypeScripts problem unto other peoples and not to investing into improving WebAssembly. That’s just MS being lazy and making their problems other peoples problems.
I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
It’s just annotations. No proposed semantics of a type system which your browser could check on its own.
Who the hell doesn’t use namespaces or enums
Uhhh, typescript devs? Enums were useful once, but typescript evolved everything else around it and these days using direct values is actually far better.
And I don’t think anyone uses Namespaces other than for defining external modules.
My bad, I’m not deep enough into our frontend stack to realize Hjeilsberg already did what he does best - ruining enums. (I guess he is not to blame for global imports in c#, so i can not add ‘questionable import module/namespace ideas’.)
And it seems like this proposal contains type declarations (in order to compensate for their enums), among other typescript specific things. So, guess it is option B, then.
I don’t see any practical use case for it as is as anyone wanting to use them would want the full TS feature set anyways, but I could see it being a good step forward for more meaningful features to be added in the future.
but I could see it being a good step forward for more meaningful features to be added in the future.
I think you are right. And that is unfortunate.
Typescript may have a million problems that make getting into it annoyingly hard and even seem pointless, but once it’s settled in your project and used well… Damn is it fucking good.
And I’m saying that even though I had to disable intellisense and most of those advanced features because the project I work for is too large and typescript would easily use over 20GB of RAM and get my computer to freeze.
But if you’re trying to use it like a traditional typed language, you’ll only see the bad side of it and you’ll certainly hate it.
I’m kind of a beginner… Can someone explain why you would make/use/have a dynamically and/or weak typed language? Is it just to not write some toInteger / as u64 / try_from()? I mean the drawbacks seem to outweigh the benefits…
The typical arguments for a dynamic typed language are that it takes less time to write something in it.
The benefits of static typed languages are that your development environment can be a lot smarter (ironically enough leading to faster development speed) and several classes of bugs being unable to happen. In a statically typed language, the IDE can detect if you’re trying to call a function that takes a number but you’re actually providing a string. In this case the IDE will let you know and you can immediately fix silly mistakes like that.
If you are writing small and simple apps it will give you more velocity and much less boiler plate.
As apps grow it becomes harder to keep track of things and can quickly grow into a mess. You then start to need external tools to give you the features of a strong static type system.
Also from a web point of view you don’t want the website to crash and burn with every error. JS will power through things like invalid types. Imagine if any error caused the website to just stop.
But a statically typed language would catch those errors before it even compiles…
The fact it doesn’t need to be compiled is also a big reason why it’s used on the web.
But I absolutely agree. I’m not a fan of dynamic typing at all.
Si you say I should use python for websites?
There’s no real alternatives to JS “for websites” (meaning on the frontend, the part of your code that gets executed on your client’s browser). That’s what JS was invented for and what it does best.
I say “no real alternative” because technically we also have WebAssembly, which is a tool that allows you to run code written with any language on the web, but if you indeed are a beginner approaching to web development you should just forget about this for now and stick to JS as you learn.
Of course this doesn’t mean that you can’t use Python on your backend, your server.
Unsafe rust is your best bet.
They used to be more attractive around the 2000s, before type inference became commonplace and when IDEs/editors were still a lot less powerful.
As for making a dynamically typed language, to my knowledge, they are actually easier to create than statically typed languages…
I’m on the side of NoScript.
From a privacy and security standpoint, both are evil and need to die.
You can minimize the attack surface with certain fingerprinting resistance settings at least.
I personally don’t see why easy interactivity would be inherently a bad thing, plenty of apps that you would have to install directly on your system can instead stay isolated in your browser and never have access to anything else outside of it, particularly useful for proprietary web apps that we’re forced to use, those same apps that go as far as to beg you to install their native counterpart on your PC, which is clearly an attempt at data harvesting and increasing user retention. Also useful for simple stuff you need once in a while and it would never make much sense to have installed
I like TypeScript for its types and type-checking, but I also want to write JavaScript to avoid having a local build step, and having to wait for things to transpile/compile/etc when running locally. I have a pretty large project where I’ve gotten both worlds by just using JSDoc and only using TS for type-checking. VSCode still offers built-in type-checking with JSDocs and ofc the type-checking can also be run separately if needed.
HTML + CSS. No need for any of that newfangled “*script” bloatware / malware.
If it fits the need…
What’s happening?
I am just a little “programmer” (if I can even call myself like that), and I’m using Typescript. Sure, it has it’s own shortcomings, as everything, but it looks better than plain JS (at least in vscode)
“In own my lane”