Things that don't make sense but exist:
> male nipples
> serverside javascript
Discussion
omg the amount of serverside shit written in javascript is too damn high!
My son calls them bipbips, and that makes all the sense in the world to me. Lol
Male nipples made for aesthetics :3
+> javascript in the database a la plv8
I come from PHP and am trying to learn a JS stack workflow. I am pulling out my hair with the confusing barrier between server-side and client-side JS! 🤦
I remember being scolded to the ground in a "developer" community, when telling a someone, that JavaScript is only a frontend world thing.
They tried to portray me as some n00b who has never programmed anything, ever. 😂
Yeah, like I'm gonna count in NodeJS & all that other bullcrap, which is basically the programmer's way of shitting in one's mouth.
Wait that barrier? You don't have access to the window object and stuff like local storage on server and you cant access filesystem in browser. Which is both wuite obvious.
What else am I missing?,
It's not a barrier, per se. I simply realized after working with it for a little that all the server is doing is creating a container and links to the JS, not rendering the page, and finding when it switched SSR to CSR wasn't immediately apparent.
Now I know that the default React SSR is super basic and doesn't contain any real content. Now I have another avenue to explore.
https://void.cat/d/Ag5kH4Rd8633AMjEwpL7sR.webp
(I didn't realize at first this only ran on the client. I thought this was server-side)
That's not a server side js issue. That's a React issue.
NodeJs on backend works perfectly fine and predictably.
With React things get a little confusing mainly because there is a huge ecosystem around react and everything can be another thing in different setups. (Like React Native vs NextJs vs React with Electron etc)
Once again tho, that is a react specific issue.
Oh! Interesting. Similar in Angular, Vue and other JS stacks or just React?
React specifically has the largest, most confusing and most diverse ecosystem. It's not entirely unique, but due to it's ecosystem's size it has some problems that are unique among it's peers. And even without the size. just like every other framework (no, it's not a library despite claiming to be one) it has unique problems stemming from the nature of how it's designed and/or implemented
What's the problem with servwr side Js? (aside from it being js)
It was designed as a clientside browser scripting language that leveraged browser callbacks.
For anything else, there are much better options.
Most languages in use today were developed for different purposes than what they are primarily used for today. That's a non argument unless it has significantly worse time dealing with it's past than it's competition which is debatable, but definitely not objectively true.
Everything else means, you have to learn two different languages with two different syntaxes. sets of quirks and exceptions, that you have to maintain two different codebases that cannot share any code (like types for instance) (specific exceptions aside), you cannot have type safe data from http requests, you can't leverage the largest and simultaneously fastest growing ecosystem of today...
I am not saying js (ts) is always the best choice, just that sometimes it actually is.
If it's more convenient and seems to work, why not?
I'm not trying to set up any purity tests, it's mostly a meme.
I wouldn't use python (even with type checking) in prod but I understand different people will make different choices.
That last sentence is the key. I for instance pretty much reverted to TS entirely despite previously kind of hating on it. Some people would not touch it with a 6' pole and that's ok. I wouldn't touch Java or Python for instance, but you'll never find me hating on people that use it or those languages themselves.