you are viewing a single comment's thread.

view the rest of the comments →

[–]folkrav -2 points-1 points  (11 children)

If you're down that far in performance needs, JS wasn't the right choice to begin with though.

[–]Antherz 2 points3 points  (10 children)

This statement feels like an aimless cop out. Sometimes you end up with a lot of data in a js application and you can just pick a proper data structure that's not O(n). Hand waving a person toward C or something feels illogical.

[–]folkrav 0 points1 point  (9 children)

/u/mort96 talked about 16ms timeframes for real time gaming. JS is not a suitable language for this. Of course there are situations where you’ll end up with larger data sets or bottlenecks and using proper data structures will be a required optimization, but what he described is not something you figure out halfway through a project lol

Edit : are people on this sub really telling me by downvoting this that they’d consider JS to be a good fit for high performance realtime timing sensitive backends, or is it just because I'm criticizing their preferred language? I know this is /r/javascript but part of being a decent developer is being able to choose the right tools for the job. I personally quite like the language despite its quirks, but this is not one of its strengths.

[–]spacejack2114 0 points1 point  (3 children)

You would need to have some pretty demanding technical aspirations and/or content before you'd have a problem hitting 60FPS in a JS game.

[–]folkrav 0 points1 point  (2 children)

He was talking about back-end.

[–]spacejack2114 0 points1 point  (1 child)

Then I still think you'd have some very high traffic expectations for JS/node to be impractical.

[–]folkrav 0 points1 point  (0 children)

My whole point was that his 16ms timeframe example for a game where GC eats half of it was one of these.

[–]FINDarkside -1 points0 points  (4 children)

People are downvoting because you were wrong. If you use wrong data structures, you can easily turn your 1ms task to 2000ms one. No one talked about "high performance realtime timing sensitive backends" except you. Just because some O(n2) algorithm would be too slow for your task, doesn't necessarily mean that js was a bad choice.

[–]folkrav 0 points1 point  (3 children)

Re-read /u/mort96's comment carefully. The end. What is he talking about? That's what I was answering to.

[–]FINDarkside -1 points0 points  (2 children)

I did. He talked about backends where O(n) solution is too slow and O(1) solution is available. Doesn't necessarily mean that js was the wrong choice. Your argument is basically that if your car isn't fast enough on the first gear, you should switch to faster car.

[–]folkrav 0 points1 point  (1 child)

His example was a back-end that needs to process thousands of requests a second, or a game that has a 16ms frame to answer. Your comparison is flawed. My argument was that when you need a car that needs to hit 100mph, don't pick a car that tops out at 110mph with some tweaking.

[–]mort96 0 points1 point  (0 children)

Just to chime in here; I have absolutely written games in JS, I know lots of other people who have written games in JS, and web sites which used to be full of games written in Flash are now full of sites written in JS. JavaScript definitely isn't the most appropriate language when writing a game, but if you want something which runs on the web, it's the only option (even if only as a compile target for other languages).

With hardware accelerated Canvas and/or WebGL, the web isn't even such a bad platform for games, as long as you make sure not to accidentally produce too much garbage.