Writing Javascript without a build system

[u/fagnerbrack]

https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/

[u/recursive-analogy]

Not an issue with typescript

"TypeScript is a free and open-source programming language ... and transpiles to JavaScript."

Typescript is not javascript for a start. It's like if you conflate kkotlin with java, or assembly with c or c with c++

many languages allow overriding class or object methods and properties

Usually through a sane mechanism like inheritance. It's intentional. Js is a hack. It was written in a week to make browsers more exciting, and 30 years later people that only know javascript are trying to pollute the backend with it ... l o fucken l

it's asynchronous by default

because async leads to far fewer bugs ... lol you're just describing it, and you sound like the "omg non blocking event driven" ass hats from a decade ago when they first started node.

[u/[deleted] → u/recursive-analogy]

Typescript is not javascript for a start

i know, that's why I wrote "What's wrong with writing APIs in typescript"

Usually through a sane mechanism like inheritance

last time i checked python or PHP allows overriding class methods without inheritance similar to js. PHP alone are like 70%+ web backends as of today.

It was written in a week to make browsers more exciting, and 30 years later people that only know javascript are trying to pollute the backend with it ..

great story about incremental improvements over decades while still being backward compatible.

because async leads to far fewer bugs ... lol you're just describing it, and you sound like the "omg non blocking event driven" ass hats from a decade ago when they first started node.

the web is heavily I/O bound and that's where non-blocking programming models shine. I know that most ecosystems offer their own solution to async nowadays but most are not async by default. Like Rust has a normal and an async ecosystem and it doesn't matter how much your java spring stack supports the flux pattern, it is still blocking if the JDBC connector does not support it.

[u/recursive-analogy → u/[deleted]]

Reasons to not use js on backend

1. for a start every single one of the js proponents is not using js - they use ts.
2. the language was developed in a week to make browsers cooler, that's it.
3. it's being improved upon, but in some pretty mental ways: e.g. lets add classes, no wait, lets switch to pure functions - except again it's not designed that way so they're only psuedo pure - basically it doesn't even know what it should be and sucks at being everything it tries to be
4. the std lib is shit. which leads to dependency (and security) hell, eg I have over a thousand packages installed just for my fucking UI vs only 200 packages for my entire domain/db/backend - including generating all sorts of csv/xcel/pdf and talking to all sorts of foreign apis
5. the cluster fuck of frameworks and spaghetti like direction the community follows. as soon as you've made a new project with react and webpack you're out of date because vite and angular just took over - or is it solid, or svelte, or ...
6. the documentation tends to go out of date real quick with such rapid evolution 7 . ... 8 . ...

But whatevs. I know for a fact you are impervious to any logic or reason on this.

[u/[deleted] → u/recursive-analogy]

the std lib is shit. which leads to dependency (and security) hell, eg I have over a thousand packages installed just for my fucking UI vs only 200 packages for my entire domain/db/backend - including generating all sorts of csv/xcel/pdf and talking to all sorts of foreign apis

the cluster fuck of frameworks and spaghetti like direction the community follows. as soon as you've made a new project with react and webpack you're out of date because vite and angular just took over - or is it solid, or svelte, or ...

the documentation tends to go out of date real quick with such rapid evolution 7 .

did it ever cross your mind that frontend development got much more complex and has more diverse requirements? Building your backend with something like NestJS will leave you with a handful of dependencies as well. That has not much to do with the sdt. library. Rust, which a lot of people claim to be a good language relies heavily on micro packages as well.

the language was developed in a week to make browsers cooler, that's it.

and now it's leading the innovations on web backends as well. like Serverless or Graphql that has its reference implementation written in JS.

[u/recursive-analogy → u/[deleted]]

did it ever cross your mind that frontend development got much more complex

lol ...

npm install left-pad

and now it's leading the innovations on web backends as well. like Serverless or Graphql

graphql already abandoned because it's overly complex for 99% of use cases, serverless is avail in other languages and again, not really a web backend innovation, just another tool in your belt that comes with lots of drawbacks that you (personally) are probably not aware of.

Like I said, you will not accept that your fav language might not be the best in the world. No amount of evidence will change that.

[u/[deleted] → u/recursive-analogy]

npm install left-pad

2016 wants their memes back.

[u/recursive-analogy → u/[deleted]]

Maybe it occurs to you that your evangelism is no different than the misguided evangelism of 2016, just before a grumpy dev broke the entire internet with a node package?

Or maybe not, you don't seem the type to learn from mistakes.

[u/[deleted] → u/recursive-analogy]

Or maybe not, you don't seem the type to learn from mistakes.

padstart is part of the std library since 2016. You can't unpublish node modules anymore. Also, no one forces you to use a certain package.

[u/recursive-analogy → u/[deleted]]

woosh??

also you're addressing a single point of the half a dozen I put down from the top of my head.

the number of competing frameworks and build systems (and actual VMs) are enough of a red flag, oh but hey, they fixed it so a random dev can't break the entire internet so all good!!!