Why is Javascript considered bad for backend?

> inconsistent behaviour

Example?

node is in a useless middle position being too slow for real problems while also heavier than python

phptards can't into event driven architecture

Imagine having a programming language that was designed for an ecosystem that hates being given compiler errors, so whenever something goes wrong, it just continues to act like nothing's wrong.
Now imagine taking that language, and putting it in an environment where it'd be nice to know whether or not your code is working.

You can write whatever and it still just works

At work it's powering lots of a big website.
I don't really like it that much desu.

Your shitty ad-hoc scheduler using async and futures is outperformed by the Linux scheduler.

>not using promises
>not linting your code
>makes mistakes and blames the language

No it's not.

What the fuck even is a promise, and why can't I just run a function then and there?

Dynamic typing is pretty awful, in my opinion. The compiler should know more about your intention, not less. Just use type inference on everything and add type annotations as a kind of static sanity check where necessary. At least Typescript exists, but it should really be the other way around: dynamic languages compile readily to static languages, whereas static languages compiling to dynamic languages still have the useless dynamic features inhibiting their performance.

All dynamically typed languages are garbage. The Python, JavaScript and Ruby retards are all delusional.

It's fashionable to dislike javascript right now, on account of the types of people seen using it.

There is absolutely nothing wrong with using Nodejs for small non-CPU heavy projects OP.

Suppose you want to make an HTTP request and get the response, or run a child_process like FFmpeg. In both cases, it doesn't make sense for your program to freeze up and wait for the response to finish before doing additional processing.

Promises basically say "hey, I want you to do this, and once your done, run the stuff in the .then(...) block; while you do that, I'm going to keep doing my own thing, okay?"

Promises just address the fact that:
1. Node.js is single-threaded
2. You're going to be waiting on a lot of network operations, which is likely the main bottleneck for speed

I like how they tried to replace callback hell with promises, but that shit is just a syntax refined callback hell so then they tried to introduce the async keyword, which only exists to make your async code look synchronous. The whole ecosystem is top to bottom dogshit.

> complains about callback hell
> devs add async/await that fixes the problem
> whines

???

This

Both are shit

>doing web dev
If you must do web, compile to webasm

What language do you use for compiling to wasm? Rust?

Listen here,

JS is not bad at all server side such as NodeJS, etc. because it is based on event loop processing vs. parallelism like other languages.

If you need non-blocking I/O intensive applications that you can scale/up down it is very good.

If you have CPU intensive application or data intensive applications then a traditional backend language would be better obviously.

WebASM is still compiled based on JS. Do you still program in assembly as well?

You write your application in rust or clojure then compile to WASM.

So they're just callbacks?

A few examples:

1 < 2 < 3; // -> true
3 > 2 > 1; // -> false

3 - 1 // -> 2
3 + 1 // -> 4
'3' - 1 // -> 2
'3' + 1 // -> '31'

'' + '' // -> ''
[] + [] // -> ''
{} + [] // -> 0
[] + {} // -> '[object Object]'
{} + {} // -> '[object Object][object Object]'

'222' - -'111' // -> 333

[4] * [4] // -> 16
[] * [] // -> 0
[4, 4] * [4, 4] // NaN

The event loop processing isn't bad for some niche purposes, like if you're basically just waiting for IO (with a big dependency graph of calls that you want to wait for simultaneously)

But it's shit if you actually need to DO anything, which is sort of the point of the backend. I suppose it's not surprising that it sits side-by-side with the microservices meme, because I guess you end up with a lot of slow IO calls as you try to patch your gazillion-service shitshow back into something useful

this. async IO for "performance" is a meme

Because is has all the inherent flaws of a scripting language, without any of the benefits other than "convenience", since you're already using it on the front-end.

what do i use for clojure to WASM?

what is clojurescript then?

> if I intentionally do hacky shit, the language does hacky shit

Ideally you should be manually casting, but think about it this way:

'foobar' + 4

That's just a feature to make string concatenation easier when working with numbers, '3' + 2 is just an edge case where it looks weird. Should you do this? No. Do a manual cast, ie. String(4). C lets you do stupid stuff like index[myarray], but that doesn't mean you need to do that.

Subtraction isn't a defined operator for strings, so when you have two numerical strings, it just casts to a number. Should you do this? No. Any linter worth its salt will scream at you.

'' + '' // -> ''
You're concatenating two empty strings, and you get an empty string; what else do you expect?

[] + [], {} + [], etc.

'222' - -'111' -> As mentioned previously, - casts numerical strings to numbers, since the - operator isn't defined with strings. You're doing 222 - (-111) which is 222 + 111 = 333, that seems fine. Should you do this? No, lmfao. Do Number('222') - (-Number('111'))

-----

I started typing all of that above to defend JS, but jesus the casts are actually fucking cancer, and I really have no excuse for [4] * [4].

JS is pretty comfy though, it just gets hairy when you force it to automatically cast. I wish the language just threw an exception when you did stuff like [] + {}

Its fine, just limit your npm package usage to reasonable dependencies. Avoid framework trends. Don't become a cargo cult programmer. Otherwise its a faster, more C like, python.

/thread

It's great for robot control on embedded systems.

Attached: motto.jpg (500x500, 61K)

I definitely see the logic behind some of the reasons, and I've used JS at my last job and had no real issues. For a front end language I found it powerful, albeit a bit messy. Still for front end it's usually the right choice.

>pic related

Attached: 1537744022964.png (990x712, 67K)

use pnpm

JavaScript (emca6) is alright, but the lack of types is brutal.

Because Jow Forums only likes K&R C.
People who hate node have never compared its main competitors: Python's Twisted and Java's nio.

Commie faggot Issac BTFO!

Just because you have a lighter version of npm doesn't mean that the packages you use in a given app will be lighter. You need what you need and that ecosystem is a clusterfuck of dependencies.

Then don't add the dependency, lol. Nothing is forcing you to add a dependency. If you think a library is bloated, make your own 0 dependency library and publish that to NPM.

You're on the same page as me, I was just looking to complain.

Attached: 1528075486973.jpg (600x799, 107K)

Also, keep in mind that when you're using libraries in production, you should only be loading up the (non dev) dependencies, which should make things relatively lighter.

Do you publish to NPM? Not trying to imply something, just wondering

Also, since you both were legitimately trying to help a brotha out - even if it was bait on my end - I gotta say thanks.

The first correct answer gets no replies huh.

Attached: 1498797564561.jpg (402x972, 112K)

I have not contributed to the project at all but I'm learning a bit more of the stack as I'm gonna be on the move a lot soon and freelancing is probably gonna have to be my road bucks.

Enter TypeScript.

kek'd in ReactJs

>4641▶
>
>kek'd in ReactJs

use hyperapp

how do you know about these bleeding edge frameworks?

I have several peers who use the same stack, and we enjoy discussing new tech when we meet up.

I use Node.js a lot and publish libraries to NPM. My stuff is mostly garbage but sometimes I make something useful.

Here's something I made that's Jow Forums related: boards.4webm.org/wsg/thread/2361334

It’s just seething from boomers and MASSIVE seething from PHP cucks.

>PHP

Man don't get me started. Got a coop job with some people who use PHP. They refuse to use composer and make all their libraries in-house. They got no docs, no unit tests, and the libraries suck.

They don't do PRs, and instead verbally discuss branches in-person to determine whether it's good to merge into master.

I've never met such boosted devs in my entire life. They fucking think jQuery is modern for frontend, like wtf.

>which only exists to make your async code look synchronous
and? This is better for everyone

It's funny how the creator of JS hates gay people.

topkek, didn't know that

What is biwascheme then?

>3 > 2 > 1; // -> false

You're a fucking retard.

Not the same guy:
Yep, in a sense they're objects wrapping callbacks, so instead of nesting callbacks when you have many asynchronous calls to make, you can chain them, which results in slightly cleaner looking code.

But the thing that makes them 100x better are the async/await keywords, which completely hides them and allows you to write asynchronous code that looks like synchronous code. And when you have to write a slightly complex function that can't execute asynchronously and can't use the async keyword, you can just make it return a promise and it will still be usable by async functions with the await keyword.

It isn't bad for backends. It is much better than python, php, etc. Once you have a few hundred million customers, you will probably want to switch over to java for performance and reliability.

That is because it isn't correct and is written by school kid. Large applications are just a bunch of small services.

I can't believe this doesn't show up more in examples of shitcode when nearly every codebase I've seen does it.
this.buttonclick = this.buttonclick.bind(this)

That is the client-side you gay fag.

Vert.x / Kotlin master race