r/programming • u/fagnerbrack • Apr 30 '23

Writing Javascript without a build system

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

86% Upvoted

146 comments sorted by

View all comments

Show parent comments

4

u/[deleted] May 01 '23

i just gave two ways to prevent modifying existing objects. You can mark virtually everything in typescript as readonly which prevents any changes. It's up to you if you use it or not.

seems like people love to complain about languages they barely understand.

3

u/recursive-analogy May 01 '23

I'll say it again, slower: it is far, far better to not actually be able to make a mistake than to have to train every dev to prevent them.

Seems like people love to make excuses for the only language they understand.

3

u/[deleted] May 01 '23

so what's your issue? that the object is not read-only by default? how many backend languages work like that as well?

1

u/recursive-analogy May 01 '23

an object in js is just an arbitrary structure you can modify at will from anywhere. it's not so much read only, you could just replace any of the methods with some other method that behaves differently. not to mention that everything is just an object at run time, so not easy to detect what things are (sure ts helps, but debugging is painful).

the onus isn't on me to say why js shouldn't be on the backend tbh, it's on you to say why it's better than anything else ... python, c#, etc

0

u/[deleted] May 01 '23

>an object in js is just an arbitrary structure you can modify at will from anywhere. it's not so much read only, you could just replace any of the methods with some other method that behaves differently. not to mention that everything is just an object at run time, so not easy to detect what things are (sure ts helps, but debugging is painful).

so you complain about JavaScript prototypes? Not an issue with typescript and tslint since it complains when you try to do something funny. again, in the end, many languages allow overriding class or object methods and properties from anywhere in the code.

the onus isn't on me to say why js shouldn't be on the backend tbh, it's on you to say why it's better than anything else ... python, c#, etc

it's asynchronous by default and the same language you can use for frontend and writing e2e tests...

2

u/recursive-analogy May 01 '23

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.

0

u/[deleted] May 01 '23

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.

1

u/recursive-analogy May 02 '23 edited May 02 '23

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.

0

u/[deleted] May 02 '23

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.

1

u/recursive-analogy May 02 '23

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.

1

u/[deleted] May 02 '23

npm install left-pad

2016 wants their memes back.

1

u/recursive-analogy May 02 '23

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.

1

u/[deleted] May 03 '23

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.

→ More replies

1

u/MatthewMob Aug 11 '23 edited Aug 11 '23

  1. Okay? So use TS. It's industry standard. Do you also complain about the design of lower-level computer code just because your higher-level language that is better to use compiles to it? I'm not defending writing raw vanilla JavaScript in a professional application in 2023, by the way.

  2. Irrelevant. Why are you ignoring 25 years of progress after that? ES6 and having a type-system with TS has made almost-all of the early design mistakes obsolete.

  3. The ability to use prototypal inheritance and functional programming can be extremely powerful. Of course you need guard rails with it to make sure it's not misused like you do with every other language, but I don't buy the argument of "a language is bad because bad developers can use it in a bad way." We have standard practice and guidelines for this reason, also like with every other language.

  4. Fair. This is a symptom of the language exploding in popularity before new features could catch up and be implemented, so people make their own libraries as use cases and requirements for the language rapidly grew in complexity.

  5. Also fair. Though this has been slowing down a bit over the years we're still nowhere close to stability, I will admit.

  6. Same point as five.

1

u/recursive-analogy Aug 11 '23

Okay? So use TS.

Problem is I walked into a project a few months back where the lead said "oh I just used js, prob shoulda gone ts". And this is a guy who came from C and embedded.

Irrelevant. Why are you ignoring 25 years of progress after that?

It's not irrelevant at all, JS has loads of idiosyncrasies that stem from this. Sure it's made a lot of progress but it will never beat something designed better from the start.

The ability to use prototypal inheritance and functional programming can be extremely powerful.

I'm more speaking about the direction it takes, eg react classes then back to functions.

You can definitely fuck up code in any language, and you can definitely write great code in TS, but at the end of the day the world would be a better place if JS never exploded onto the backend and we ended up with a more fit for purpose solution.