[spoiler]lol[/spoiler]
>>55152974
back to /reddit/ shitstain
>>55152994
>supporting nodejs
back to sjwhub, sjw
>>55152974
i'll spare you the confusion on why your spoiler tags didn't work:
>>>/v/
>>55153203
lol
>>55152974
show me better language then javascript for web development, I will wait.
>>55153704
http. Your site doesn't need obnoxious effects, parallax scrolling, and a thousand beacons.
>>55153757
HTTP isn't a language
JavaScript can be used for more than flashy effects
Kill yourself
>>55153757
well the free market decides that, if you think your non js site is superior then you should gain more users.
>>55153778
ECMAScript isn't a language either, what's your point?
>>55153786
not.an.argument
>>55153757
Braindead
>>55153786
In the free market ease of use beats out functionality every time. The free market is full of consumers who are pants on head retarded.
>>55153704
JavaScript is the "best" language for (client-side) webdev for the simple fact that it's the only one, being there no support for any other language that in the end is not transpiled to it.
Almost any language would be better than JavaScript, if only the webdev world wasn't this retarded to only support that piece of shit. Decades of advances in language and compilers research thown into the toilet because, well, JavaScript monopolized a promising niche and spread out from there like a literal cancer.
>then
It's "than", dumbo.
>>55153704
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
>>55153847
>javascript is bad
>refuse to give an better alternative
go back to r/programming.
>>55153942
the only good one out of those is typescript because its based on js.
>>55153819
Name one thing that you must use emcascript for on a basic website, that is actually meaningful.
>>55153999
an upvote system
>>55153704
Bruh, even the most popular JS book, "JavaScript: The Good Parts" acknowledges that it's a terribly designed language with a cornucopia of ill-advised features. It's a pile of shit that we just gotta live with. Because worse is better
>>55153757
>>55153778
He has a point tho. A good web page, and that includes an interface to a web hosted application, doesn't need overly complex javascript. You only run into these problems if you're trying to build sophisticated client-side business logic. Which means you aren't developing a web page at all, you are building a full client-side application that you want to disguise as a web page. The solution would be to just not do that.
>>55154018
but the javascript he described in that book is vastly different from the modern day javascript. the bad parts are vastly gone with es6/7 the only major feature the language needs are types (preferably ala flow).
>>55154061
>implying things are ever taken out of JS
>>55154048
>You only run into these problems if you're trying to build sophisticated client-side business logic
You got it, and in those scenarios you shouldn't be using javascript at all.
>>55154080
>implying people with js knowledge use them
>implying new comers learn about stuff like ```with```
Just watch this: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
Why not just use C + asm.js? Seriously
>>55154061
>the only major feature the language needs are types
And compile-time imports.
>>55154221
not sure what you mean but with http2 you can push stuff to the client so you could generate a dependency file and for example nginx could figure what stuff the client needs ahead of time.
>>55152974
Still better than Python.
>>55154085
what should you be using then? GWT?
>>55154255
All the non-shitters are using Clojurescript, Elm etc.
>>55154248
>completely disjunct target applications
"A truck is a better sportscar than a bulldozer"
>>55154154
>yavascript
lel
>>55154279
But seriously, what should I use if I actually want users and money?
>>55154242
Cancer.
What I need is instead ofvar leftpad = require("shittoloadatruntime.js");
something likeimport mysymbolicimport;
To catch more errors etc pp.
Actually, turns out something like this planned:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
Hopefully it happens at compile time.
>>55154248
Looking at CPython, I tend to agree.
>>55154291
Python is crap even in its own niche.
>>55154310
A sound business idea.
Even if browser started supporting asm.js/wasm, wouldn't the binary blobs be big as fuck?
>>55154310
Typescript or what >>55154279 just mentioned. Or Babel, to ease the pain.
>>55154298
yea, it's a little bit annoying, but i think that you can get over it
>>55154332
In theory no, because the browser ships with a lot of stuff already. In reality yes, because everybody ports his boilerplate framework to the new wasm target.
However, that is already the case with plain js.
>>55153071
Why do all white men hate nodejs?
I still don't get why the major browsers don't collaborate on a single c#/java-like language and then just implement it in their products.
Google had dart but had to go and fuck up the licensing.
>>55152974
>There are only two kinds of languages: the ones people complain about and the ones nobody uses
- Bjarne Stroutstrup
>>55154377
because they can't understand how callbacks work
If you use ES6/ES2015 along with an implementation of async/await (I use yortus' node-fibers based one; there are also Babel approaches which work in the browser too), things are far better. Mostly resolves callback hell, you can basically just write synchronous code.let foo = await(do_something_async());
console.log(foo);
>>55153807
Are you sure you dont think html instead of http?
>>55154383
>there are only two shades of grey: black and white
>>55154580
It's called "callback hell" for a reason.
>>55153704
JS is okay for certain, simple tasks in the browser, but that's because it's literally the only option for said tasks.
If you're talking about back-end languages, then just about anything is better
>>55153999
A "select all" checkbox
Arguing that JS isn't useful for a single thing just makes you look fucking retarded
>the next generation of programmers will only bother learning JavaScript
>everything will run on JS
>untold amounts of energy will be spent interpreting this shitty language
>untold amounts of human effort will be spent trying to make it run a little faster
>if we ever go into space again the rocket will be running fucking JavaScript
>all because some greedy fucks wanted to make people use their browser over someone else's
>>55156425
asyc/await has solved this. Callback hell is not a thing anymore if you just use that.
>>55156425
>It's called "callback hell" for a reason.
it's called "promises and futures" pattern for a reason.
>>55156964
Can I do two things at once with it?
>>55156997
probably not since it sounds like retarded synchronous bullshit in my async lang
>>55156994
>it's called "promises and futures" pattern for a reason.
Complete shit. Fundamentally broken.
Threads or GTFO
>>55157054
Threads are too hard to get right
>>55156997
Yes, multiple blocking I/O can be awaited in parallel. One approach:let results = await({
foo: retreive_foos_async(),
bar: some_other_slow_async_awaitable()
});
do_something_with(results.foo)
Compute is still single threaded, but if your software is compute-bound you hopefully are not writing it in JS!
>>55157076
I'd like to not write it in JS, but some fuck decided to make it be the only language that browsers support
>>55157054
why do you need threading when you can have explicit message passing instead?
>>55157099
Why are you writing compute-bound software for the browser?
>>55157136
Because that's what the client wants.
>>55157060
if you're retarded, maybe
when is crockfords qt based thing becoming a standard?
i really hope it is becoming a standard ;_;
>>55157147
Fair enough! How heavy compute are we talking? If you absolutely need preemptive multithreading (i.e multicore), you can use Web Workers.
>>55157127
Good luck debugging without a back trace
>>55157165
Crockford is a crock of shit
>>55157183
you talking shit about my jsbandu?
you better not talk shit about my jsbandu.
>>55156921
>mfw everything is the same for x86
>mfw we are at step 5
>>55157181
true. I suppose.
But it doesn't matter since async is better for I/O bound problems and you know it.
Seeing threading in socket driven applications and frameworks nowadays is quite strange.
Node.js or javascript weren't meant for compute bound issues.
>>55157177
It's not so heavy, I put together a quick and dirty Scala version that performs fine using really basic parallelization, but the JS version runs sluggishly even on my dev machine so it won't stand a chance on the average office computer. It's essentially doing lots of easily parallelizable physics calculations on demand.
I've never used web workers, I was hoping to avoid learning yet another web technology.
>>55157202
He doesn't even understand monads, what makes you think he's qualified to talk about JavaScript?
>>55157246
Holy shit, have you never worked in industry?
>>55157246
>Seeing threading in socket driven applications and frameworks nowadays is quite strange.
wat
>>55157310
o do you actually have a point?
just because the industry is stuck using shitty paradigms to solve problems better solved by literally anything else proves nothing.
major languages have async in their standard libs, operating systems have tons of async features, major socket libs are async.
you're a delusional fuck.
>>55157398
I still remember the first single-threaded networking app I wrote in C using asynchronous IO. It was a good time.
>>55157398
listen kid, pure single thread async, while sexy, isn't scalable. it has a clear upper limit. you've clearly never had to write an application at scale. the concepts you've learned are valuable and highly transferrable. I have to think about multi-datacenter, multi-machine, multi-processed, multi-threaded, async apps. because that's how you scale. don't go tooting your horn like you know the end all be all because async has some hot libraries that only use the eventloop. grow up
>>55157484
except it is scalable.
it's actually really easy to scale single threaded async shit because the problems you solve with async are generally share nothing by design.
if you need to share anything, you can just drop an event in one of the many async processes you have running.
https://nodejs.org/api/cluster.html :)
>>55157523
>it's actually really easy to scale single threaded async shit because the problems you solve with async are generally share nothing by design.
I agree 110%. designing async from the start is imperative for scale.
>https://nodejs.org/api/cluster.html :)
holy fuck my brain just exploded at the clusterfuck you will have to manage, might as well write in C. sure trivially parallelizable problems can be solved, but anything dependent is highly problematic. C# async/task libraries are quite brilliant for large projects for my preferred point of reference on scale.
>>55157645
>but anything dependent is highly problematic
of course!
kind of the point, no?
again, I guess you could do some really crazy message brokering between workers, but at the end of the day I would rather just write it in another language that's more "flexible" in it's paradigms.
as you clearly pointed out, C# does indeed have such features where it is useful and the conventional locking and threading when it's useful.
>>55157701
>kind of the point, no?
for node.js in the context of serving web pages. yeah that's the point and probably enough.
My final point to get across is single threaded async gets you 80% of the way there. i am a huge fan of it, and i believe some people used to writing in the mulithreaded world when they don't have should adopt some stylings, but end of the day you need all the tools in the toolbox. and i hate when people say otherwise.
lovely conversation sir, have a good life
