[spoiler]lol[/spoiler]

[spoiler]lol[/spoiler]

Other urls found in this thread:

github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
destroyallsoftware.com/talks/the-birth-and-death-of-javascript
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
nodejs.org/api/cluster.html
twitter.com/NSFWRedditImage

back to /reddit/ shitstain

>supporting nodejs
back to sjwhub, sjw

i'll spare you the confusion on why your spoiler tags didn't work:

lol

show me better language then javascript for web development, I will wait.

http. Your site doesn't need obnoxious effects, parallax scrolling, and a thousand beacons.

HTTP isn't a language
JavaScript can be used for more than flashy effects
Kill yourself

well the free market decides that, if you think your non js site is superior then you should gain more users.

ECMAScript isn't a language either, what's your point?

not.an.argument

Braindead

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.

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.

github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js

>javascript is bad
>refuse to give an better alternative

go back to r/programming.

the only good one out of those is typescript because its based on js.

Name one thing that you must use emcascript for on a basic website, that is actually meaningful.

an upvote system

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

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.

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).

>implying things are ever taken out of JS

>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.

>implying people with js knowledge use them
>implying new comers learn about stuff like ```with```

Just watch this: destroyallsoftware.com/talks/the-birth-and-death-of-javascript

Why not just use C + asm.js? Seriously

>the only major feature the language needs are types
And compile-time imports.

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.

Still better than Python.

what should you be using then? GWT?

All the non-shitters are using Clojurescript, Elm etc.

>completely disjunct target applications
"A truck is a better sportscar than a bulldozer"

>yavascript
lel

But seriously, what should I use if I actually want users and money?

Cancer.

What I need is instead of

var leftpad = require("shittoloadatruntime.js");


something like import mysymbolicimport;

To catch more errors etc pp.

Actually, turns out something like this planned:

developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

Hopefully it happens at compile time.

Looking at CPython, I tend to agree.

Python is crap even in its own niche.

A sound business idea.

Even if browser started supporting asm.js/wasm, wouldn't the binary blobs be big as fuck?

Typescript or what just mentioned. Or Babel, to ease the pain.

yea, it's a little bit annoying, but i think that you can get over it

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.

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.

>There are only two kinds of languages: the ones people complain about and the ones nobody uses
- Bjarne Stroutstrup

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);

Are you sure you dont think html instead of http?

>there are only two shades of grey: black and white

It's called "callback hell" for a reason.

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

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

asyc/await has solved this. Callback hell is not a thing anymore if you just use that.

>It's called "callback hell" for a reason.

it's called "promises and futures" pattern for a reason.

Can I do two things at once with it?

probably not since it sounds like retarded synchronous bullshit in my async lang

>it's called "promises and futures" pattern for a reason.

Complete shit. Fundamentally broken.

Threads or GTFO

Threads are too hard to get right

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!

I'd like to not write it in JS, but some fuck decided to make it be the only language that browsers support

why do you need threading when you can have explicit message passing instead?

Why are you writing compute-bound software for the browser?

Because that's what the client wants.

if you're retarded, maybe

when is crockfords qt based thing becoming a standard?
i really hope it is becoming a standard ;_;

Fair enough! How heavy compute are we talking? If you absolutely need preemptive multithreading (i.e multicore), you can use Web Workers.

Good luck debugging without a back trace

Crockford is a crock of shit

you talking shit about my jsbandu?
you better not talk shit about my jsbandu.

>mfw everything is the same for x86
>mfw we are at step 5

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.

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.

He doesn't even understand monads, what makes you think he's qualified to talk about JavaScript?

Holy shit, have you never worked in industry?

>Seeing threading in socket driven applications and frameworks nowadays is quite strange.
wat

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.

I still remember the first single-threaded networking app I wrote in C using asynchronous IO. It was a good time.

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

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.

nodejs.org/api/cluster.html :)

>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.

>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.

>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.

>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