node.js
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
>client
>server
>same language
>same code
>faster than PHP
Is there any reason not to switch to node.js? I've been thinking about learning it.
>>53134478
node.js community is full of faggots. Other than that, no.
Callback hell, though it probably won't bother you too much of you only do crud stuff.
>>53134478
>a dozen different "compiles to JavaScript" memelanguages
>"JavaScript is fine"
responds to every criticism with
>"it's fixed in memelanguage4"
>faster than PHP
Everything is faster than PHP. The real question is, why use Javascript for backend?
It's rubbish mate, tried to get it to read from a 40g 35million row database, it was a simple fucking script, connect -> setup a callback function -> start looping rows.
But it somehow manages to consume it's permitted 2gb of memory and errors seconds after starting with no output.
shit language, pure callback based execution is fucking garbage (especially for simple programs).
And anything is faster than php, that's a given.
>>53134523
>same code
I would think sharing code would cut down on development time immensely, like being able to do client-side and server-side data validation with the same code
Good luck scaling up. Use go, the language of the future of web development.
>>53134544
Were you reading 2gb of data? How would another language save on memory usage?
>>53134597
The database was mongodb, which uses cursors for its select querys, so it should of been loading and processing 1 row at a time then discarding the data.
>>53134628
>>53134544
found the script actually ..MongoClient.connect('mongodb://127.0.0.1:27017/local', function(err, db) {
if (err) throw err;
var data = db.collection('statistic_data');
var f = function(err, result) {
if( err ) return;
console.log(i);
}
for( var i = 1; i < 30000000; i++ ){
data.findOne({'_id': i}, f);
}
});
>>53134628
>>53134661
Thanks senpai, good insight
>>53134478
no there isn't
senior js fullstack here, got like 160 pending messages on linkedin from people offering a job :)
>>53134478
If only JS wasn't complete trash, this would be amazing.
Maybe I should learn one of the meme languages that compile to JS?
>>53134478
>Is there any reason not to switch to node.js? I've been thinking about learning it.
Erlang and Elixir exist.
>>53134628
>>53134661
>mongodb
Found your problem
>>53134762
You can try to hide javascript but you're still writing javascript
>>53134838
What if I was using some shit like ClojureScript instead? Would that make this more bearable?
>>53134812
I'll happily take advice on alternatives, I'm actively looking to migrate, looking to Cassandra, but not looking to promising.
>>53134869
What are your needs and use cases? Do you really need really high r/w performances? Do you just need to store documents?
>>53134879
very wide documents (4500+ columns), needs to be able to handle at least 80 random updates/s on an ssd, ideally run quite light on memory, given it's got an ssd to work with.
and some semi advanced query functionally, mainly needs to support bitmasking on any size binary data.
>>53134762
Since I'm relatively new to web development, what's wrong with javascript? I've only used it client-side and I've only had small problems like the lack of classes and constants
>>53134846
Also from what I understand, mysql is the most popular dbms for web development. Can I ask why you don't use it?
>>53134478
I found it nice for JSON api servers, since JavaScript integrates nicely with JSON.
On the other hand I wrote a 4chan API clone, and even something like that had "callback hell", which makes things harder to understand for newcomers, and just pulling it apart and calling the functions names, didn't seem to help either.
But I do understand the attractiveness the concept of having JavaScript as a general web development language, especially for new comers. This could also be seen as a negative point though. In the end it does it's job, and that's what's most important for some. I personally prefer Go for these things.
>>53135273
Can someone please explain this "callback hell" meme? Isn't all code execution some form of callback? Please explain it like I'm five years old.
>>53135346
basically insted of functions just blocking until they complete, they all have callbacks with get called once the function call has done it's job.
for a lot of things, espcially file and network IO, this is prefered.
but node puts it on fucking everything, to the point where you can't do simple tasks like reading from a database without going 6 levels deep in programming logic.
>>53135346
It's not a meme, it's real. For non-blocking code you give a function parameters, and a function to execute when it's finished. Now JavaScript allows anonymous functions, ie. for you, Functions declared within the parameter list. This can go on on on.
Pic related is a pretty mild example. You see, although by choice, the last few lines are only "});". And that's basically what people complain about.
>>53135373
Thanks buddy, I learned something new today.
>>53135408
Can't you just flatten this out and pipe/chain methods?
>>53134661
You are creating 30,000,000 asynchronous tasks.
so stupid.
>>53135373
>>53135408
Working on a Node.js web application, can fucking CONFIRM.
Couldn't you just write some kind of macro to close all the nested calls like`3
would expand to});});});
>>53135430
most javascript users are too stupid to utilize function composition or know what the continuation monad is
>>53135408
m9, how can you look at that sun of a theme?
other than that, yeah- node is a callback hell but it gets the job done
>>53135480
do you think people develop in notepad nowadays?
>>53134478
>faster than PHP
>>53134478
Because you need to install a fucking browser onto your server
Sure it just works, but if you have even a little enthusiasm for software engineering, you would look for something else.
If your job requires it, sure; use it.
>>53135629
It's a screenshot from github.
>>53134661for( var i = 1; i < 30000000; i++ ){
data.findOne({'_id': i}, f);
}
the fuck?
>>53135636
Wouldn't be hard to get your editor to match properly with that unless you are using fucking retarded editor.
>>53135408
wew lad meme freemodule.exports = (filename) => {
lwip.open('./img/' + filename)
.flatMap((img) => img.scale(150 / Math.min(img.width(). img.height())))
.flatMap((img) => img.writeFile('./thumb/' + filename))
.mapErr((err) => console.log(err));
};
Thank god they don't sell pizza using node.js.
>>53135734
So about arrow syntax..
Basically, you remove the function syntax, you place function parameters inside parenthesis and then use => to write the rest of the function.
Can you use arrow syntax only on a single line functions (since you don't use "return") or you can use it for multi-line blocks too?
>>53136014
>module.exports = (filename) => {
>>53134553
It doesn't share code between front- and backend, it only uses the same language
>>53136206
You can share code, see here:
http://stackoverflow.com/questions/3225251/how-can-i-share-code-between-node-js-and-the-browser
>>53136014
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
>>53134523
>>53136286
>How fast dynamic languages render a Mandelbrot fractalof bad design
>>53136318
damage control: the post
>>53134478
>>faster than PHP
Languages aren't inherently fast or slow. Their implementations, however, can be.
Only using a single language / framework as an absolute is a good way to make shitty software.
You are basically asking, "Should I switch from this hammer to that hammer?"
Anyway, a good reason to not use node is when your use-cases are CPU bound.
>>53135734
Hmm. Didn't know about the arrow syntax, but I haven't worked with JavaScript for nearly 1 1/2 years. Did that even exist (for node.js) in 2014, or is it ECMA 6?
>>53136424
ES6 you dork! Why the fuck haven't you been using it?
Why should I use JS over Haskell?
>>53136376
what a nitpicky, pedantic thing to post
>>53136450
Blunt honesty sometimes is.
>>53136206
>>53136218
>>53134523
>>53134553
using typescript for a small project for back and front end, which shares multiple classes for data manipulation
only a pain if you use module structures in the backend which is nice, but want to use part of the modules on front end too,
its possible but not straightforward for what i learned
>>53136449
Because you can't run Haskell natively in a web browser. You can write a Haskell interpreter in Javascript I guess.
>>53135346
>>53135373
>>53135408
Why don't they use Promises for that?
>>53136525
Because people like to shit on JS for no reason, now shut the fuck up.
>>53136511
I probably should have said Node, since I meant backend specifically. Although there does exist many Haskell to JS transpilers.
https://wiki.haskell.org/The_JavaScript_Problem
>>53136533
>"B-But muh javascript is p-perfect!! T-They're j-just shitting on it because they're meanie haters!!!!111 ;___;"
I have a project that I'm writing in PHP right now just because that's the language with the longest runway for me in terms of experience, but if you're not at a severe disadvantage using JS then you should start projects with Node.JS
If you're in the same boat I'm in, then my course of action is to prototype stuff in PHP since I'm familiar enough with it that I can churn out functionality much faster in PHP than other server languages, and if the project I'm working on seems to have legs, I'll start re-writing stuff in JS.
There are probably two factors worth thinking about when you get started though:
1) Is this supposed to be an open source project at some point? If so, then yeah you might want to make sure it appeals to more developers, who are more likely to want to hack around with (Node.)JS projects than PHP projects.
2) Assuming you're planning a rewrite, how deep into the project can you get before a rewrite would become too costly? Are you willing to rewrite 100 lines of code? 500? 1000?
The first decision is the do-or-die question; if you don't plan on "the public" seeing the code, then make whatever decision you want. PHP and JavaScript are both sufficiently well-used that you can find support for any specific issue you run into (same with Ruby and Python but I don't think you're considering those). The second question is the more problematic one. Assuming you plan on making it open to the public, you need to be aware of when you're approaching a point where a rewrite would be too costly (but these costs can be managed).
>>53136592
or consider if v8 + libuv packaged in a binary is of any benefit to you, I'm not sure if deploying that to every platform will be fun..
>>53136552
You can do that but you'd be retarded if you wanted to do serious front end web development with Haskell. All documentation will be JS specific and your team would hate you for making a ridiculous decision just because of an irrational hatred of a tool.
As for Node and the backend, I can't imagine Haskell having as many useful packages as npm. There is likely more documentation and support on Node's side. That alone from a software engineering point of view is a huge pro for Node. And I can't imagine Haskell being faster in most cases.
>>53136627
It's entirely possible I'm misreading you, but I think you're talking about setting up a server that'll run with Node.JS; if that's not what you meant, then the whole rest of this post will be a total red herring (sorry about that).
I actually don't think deployment is actually the issue it used to be. There was a time in recent history (after /g/ stopped being about guro) that getting your hands on a server that ran anything other than PHP (namely, at the time, Ruby) meant spending a marginal difference on hosting. Now you can get Heroku to run practically anything for free, and AWS makes it possible to instantiate a platform to your specs, which you can then push to as desired (with more control than you would have on Heroku).
And it's not just Amazon vs Heroku; there's Google (unless they killed it recently they have an engine for this stuff), Azure (which isn't as bad as it used to be, although I interned at MSR so there's that disclosure), and DigitalOcean has a huge subsidy if you can prove you're a student. And there are good guides on getting this stuff up and running with whatever environment you want.
There's a chance that I'm just more comfortable with this stuff because I'm more experienced, but I honestly think it's MUCH easier now to *not* use PHP and still have a live website than it was like... 10 years ago.
>>53136637
Haskell is pretty damn fast. I can understand why you say Node would likely have more documentation, but Haskell itself is self documenting due to the type system.
I would say the incredibly safety and development speed you get in Haskell is a fair software engineering trade off for slightly better documentation and support.
>>53136688
I don't think you can argue for safety and development speed just yet. There are way more competent and experienced Node developers than there are Haskell backend devs. Development speed is influenced by available packages not written in-house, and npm has that advantage. I also don't think safety is an issue for most webapps which are mostly just CRUD and developed Agile.
>>53136794
I kind of agree with this, although it's nice to see a developer that's coded in Haskell. It's (still!) a strong signal that the developer is competent. And I say "still" because I heard this years ago and usually when that kind of advice gets out into the world everyone and their dog learns that thing and it stops being good signal.
I think Haskell is just inherently confusing enough from an imperative developer's perspective that it's hard to "fake" the way other things are. If you started learning imperative languages, then Haskell forces your brain to work through problems in a different way than you're used to, and that makes you better at the abstract problem of "reasoning through problems".
So I wouldn't run a site in Haskell, but if someone's resume listed Haskell projects it would almost certainly merit an interview.
>>53134478
Because other languages exist other than php and node, and threads are a better concurrency model according to the IEEE.
>>53134502
It's fuckin confusing, I agree. But it asynchronous programming can be fuckin nice.
>>53137267
> asynchronous programming can be fuckin nice.
You should see how Go handles concurrency and parallelism. You will cry about how much nicer it is in comparison.
>>53134791
>Erlang
Pic related
>>53137267
>>53134502
Look in to ES6 generators + koa. It makes writing node.js servers waaaaay easier/faster than before.
>>53135433
29,999,999
