I'm choosing the third side: WebAssembly
this post was submitted on 08 Sep 2023
347 points (100.0% liked)
Programmer Humor
418 readers
3 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
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 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.
load more comments
(1 replies)
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.
load more comments
(1 replies)
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"
I haven't managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:
- following a basic tutorial somehow ended up spending multiple seconds just to transpile and run "Hello, World!".
- there are at least 3 different ways of specifying the files and settings you want to use, and some of them will cause others to be ignored entirely, even though it looks like they should be used.
- embracing duck typing means many common type errors simply cannot be caught. Also that means dynamic type checks are impossible, even though JS itself supports them (admittedly with oddities, e.g. with string vs String).
- there are at least 3 incompatible ways to define and use a "module", and it's not clear what's actually useful or intended to be used, or what the outputs are supposed to be for different environments.
At this point I'm seriously considering writing my own sanelanguage-to-JS transpiler or using some other one (maybe Haxe? but I'm not sure its object model allows full performance tweaking), because I've written literally dozens of other languages without this kind of pain.
WASM has its own problems (we shouldn't be quick to call asm.js obsolete ... also, C's object model is not what people think it is) but that's another story.
At this point, I'd be happy with some basic code reuse. Have a "generalized fibonacci" module taking 3 inputs, and call it 3 ways: from a web browser on the client side, as a web browser request to server (which is running nodejs), or as a nodejs command-line program. Transpiling one of the callers should not force the others to be transpiled, but if multiple of the callers need to be transpiled at once, it should not typecheck the library internals multiple times. I should also be able to choose whether to produce a "dynamic" library (which can be recompiled later without recompiling the dependencies) or a "static" one (only output a single merged file), and whether to minify.
I'm not sure the TS ecosystem is competent enough to deal with this.
This last part sounds nice in theory, but it's way outside the scope of what Typescript is intended to accomplish. I've been pursuing a similar goal on and off for 10+ years at this point, I even wrote an ORM for Backbone.js so I could use it on the server as well. Back then we called it Isomorphic Javascript, later on it got renamed to "universal javascript", nowadays I'm not sure.
But yeah, the problem is similar with any code, really... What you're often writing in software dev is just functions, but the infrastructure required to actually call said function is often not trivial. I agree it'd be nice to be able to have different "wrapper types" easily, but I'm afraid their usefulness would be limited beyond toy projects.
Javascript.
Because my exposure to Typescript is wading through over-engineered and bloated Angular front ends that could easily (and should) be thrown out and re-written in html/ js.
But also because I exclusively write simple shit that doesn't have a build step for the front end, because 90% of the stuff I make gains no benefit from needlessly overly complex front ends.
Modular front end design is convenient in the long run tho
Iβm idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday Iβll get WASM in there. One thing I will not do is use TS or JS.
To be perfectly frank, I've only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.
well, I mostly create SPAs, with big projects a type system is a necessity...
Truthy
!&&
Iβll be downvoted again but I agree.
After this and saying that you're a beginner to JS, I would instead suggest spending time to develop perspective from a place of knowledge and experience rather than... I guess, being proudly ignorant?
if you're a beginner, and you post an opinion and lots of people say that many years of professional experience make them disagree with you, why would you not take that on board? I wish you well on your learning journey. at some point you'll outgrow vanilla js and you'll have learned enough to configure transpilation and webpack etc. it'll be a good day.
The fact that you're doubling down on your ignorance is quite problematic. Typescript is not an enterprise system that forms arcane JS. It's literally JS with a slight adjustment that allows you to say "also this is this type". You write JS the entire time and can "disable" the typescript at any location you need to not be typed.
All the stuff I write is personal tools anyways so I do the same. They're small anyways.
I don't like blocated crap, so vanilla js es6 is the way
view more: next βΊ