- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Refusing rust and wasm is a signal you don’t care about code quality or security
See? You can keep playing that game all the way down to the most onerous language
Can wasm manipulate the DOM yet?
WASM allows arbitrary code execution in an environment that doesn’t include the DOM… however it can communicate with the page where the DOM is available, and it’s trivial to setup an abstraction layer that gives you the full suite of DOM manipulation tools in your WASM space. Libraries for WASM development generally provide that for you.
For example here’s SwiftWASM:
let document = JSObject.global.document var divElement = document.createElement("div") divElement.innerText = "Hello, world" _ = document.body.appendChild(divElement)It’s pretty much exactly the same as JavaScript, except you nee to use JSObject to access the document class (Swift can do globals, but they are generally avoided) and swift also presents a compiler warning if you execute a function (like appendChild) without doing anything with the result. Assigning it to a dummy “underscore” variable is the operator in Swift to tell the compiler you don’t want the output.
Actually, if you really care about quality and types on the front end rust+wasm is not a bad idea 🤔
Now that I’ve typed that and read it back, were people using TypeScript for anything other than front-end web dev?
Because at the end of the day TypeScript is still Javascript and it’s still bad. Just has some verbose formats to try and make weakly typed language (javascript) appear to be strongly typed. It adds more build steps to what shouldn’t be there; build steps make sense for apps, they make much less sense for libraries.
https://dev.to/bettercodingacademy/typescript-is-a-waste-of-time-change-my-mind-pi8
https://medium.com/@tsecretdeveloper/typescript-is-wrong-for-you-875a09e10176I’m sorry. Whoever wrote that should give up trying to write articles. It’s poorly written and will never convince anyone to change their mind. It’s shit. “I know how to convince people they’re wrong. Insult them. Setup a ton of strawman arguments. Genius.”
Whoever wrote that is bad and should feel bad.
Which one? There were multiple links in that comment.
Second one. Just realized there were two. Being close together and the first being long enough to get trailing “…” it all just looked like one big link when I first saw it. May just be Kbin displaying it that way.
It was used pretty frequently for back end APIs too
That is disturbing. From my perspective, anyway. There are already so many great (and more appropriate) stacks for web backends, why Frankenstein a Frankenstein into it?
Well, usually because you’ve got a team of frontend folks needing to do a backend.
There’s one other advantage, which is that you can have a compile-time shared model between backend and frontend. You also have that advantage with WASM, but not with a traditional backend/frontend technology split…
Compile time is my biggest issue with TypeScript. I’ve used JavaScript for decades with compile time measured in, what, a millisecond or two. Having to wait for TypeScript drives me nuts.
After having to use TypeScript in a project, I don’t see much usefulness. It feels more like a weird linter, than an actual language with extra features. It’s tons of ugly boilerplate for little gain, at least so far in my experience.
Reading the responses here, why are people so mad about types? Maybe I’m biased coming from a background of statically typed languages and mathematics. I’d rather have a good typing system that makes me think about data than just hoping I’ve thought about a problem right.
Man there have been hot take after hot take in the programming communities over the past few days. Here, I’ll give my hot take since nobody asked:
If I have to touch your code and I can’t tell what inputs it’s supposed to accept, what it should do with those inputs, and what outputs it should produce, I’m probably deleting your code and rewriting it from scratch. Same goes for if I can trivially produce inputs or states that break it. If your code is buggy, it’s getting fixed, even if that takes a rewrite.
When working with others, write readable and maintainable code that someone with much less context than you can pick up and work on. It really doesn’t matter if you need to use TypeScript, mypy, tabs, doc comments, or whatever to do it.
When doing your own project, it doesn’t matter. It’s your code, and if you can’t understand it when you come back to it then you’ll probably rewrite it into something better anyway.
This is the core thesis of the article:
It’s true that sometimes you have to write non-trivial types to convince the compiler that your data is correct.
That’s okay. Creating maintainable code with high quality often requires putting in the hard work.
There’s no real substantiation of the claim; just the claim itself.
Yes TypeScript is onerous but that’s just alright.
Maybe it’s true but it’s a weak argument.
Damn right. I care about getting features in the hands of my users. If code quality helps with that, if type script helps with that, I’m all in favor.
But the moment I care about code quality for its own sake you need to sack my ass like yesterday.
What an utterly blind, self-centered view. Write good, readable code so you can actually maintain it and so your coworkers don’t want to kill you.
What an utterly blind, self-centered view.
This is a really surprising retort.
In the end, the only thing that has value is what ends up in the user’s hands. The rest is only a means to an end, in the very best case.
This is not a controversial take in professional software development.
What is self centered and self absorbed is putting misguided notions of “craftsmanship” and maintainability over business needs.
If you can’t see that writing readable code is part of the means to that end, I don’t know what to tell you. If nobody can maintain the codebase because it’s a mess of spaghetti logic and 20-deep dependency trees (I’m looking at you, every JavaScript project I’ve ever seen), the end product is going to suffer while also making every single engineer working on it want to leave.
This is not a controversial take in professional software development.
Funny, it sure seems like “maintainability should not be a priority” is a pretty controversial take to me.
I think vzq’s point is that you can write good, readable code that doesn’t do what the user wants. Same with other metrics that are ripe for navel-gazing like code coverage.
It’s bordering on a false dichotomy… but I also believe that dynamic, untyped languages have proven exceptionally useful for rapid prototyping and iteration.
I must admit that I write that deliberately to annoy the “code quality is everything” brigade.
I have no issues prioritizing maintainability where needed, but in my experience people that dogmatically prioritize code quality are not honest with themselves. They almost never chase code quality in general. They are always looking to enforce some burdensome standard or specific tool or archaic process or fiddly CICD script, and if you push back they go cry in a corner about the abstract virtue of “code quality”.
Just be straight with me. You enjoy using type script. Tell me how it adds value to the product and the customer.
Stop trying to shame me into it. I can’t be shamed. I have no shame. I’m a professional software engineer.
You’re setting up a theoretically boogie man that no one said exists and then setup the extreme opposite point of view. You’re annoying the people that are actually sane. You’re being dogmatic in your one views and too extreme.
maintainability is arguably not a value-added for the end user. But still absolutely important. Robustness of code is arguably not visible to an end-user, until it fails. And that’s very important. Features are great, but quality is still important and is basically the mortar between the bricks that are features. Only caring about features leads to poorly written applications.
Less chance of security vulnerabilities, breaches, less bugs fixed more permanently, faster features, etc
Those things all sound like value adds for the end user…
Expect to see more posts like this. With a few projects announcing they’re dropping support for TypeScript we’re going to have developers worrying that this tech that they’ve sunk so much time into is suddenly becoming obsolete, so they’re going to evangelise hard in favour of it as a defence strategy. Same thing happened when Perl went out of flavour.
I’ve seen so many front-end libraries come and go over the 25 years I’ve been doing this. Be good at programming in general, and you can usually hop on board the incoming train pretty easily and hop off again before it goes off a cliff. You can’t really get too attached to anything in an ever changing industry.
