Hey Sup Forums.
Why is ExpressJS more popular than ROR?
Coding a web application with ROR take few hours, coding a website with express take few days.
Why ?
Hey Sup Forums.
Why is ExpressJS more popular than ROR?
Coding a web application with ROR take few hours, coding a website with express take few days.
Why ?
Node.js and asynchronous programming are the reasons, friend.
Well you're right. Express is way more flexible and surely way faster for big operations, but I don't understand why ror loosed so much popularity last years
Web frameworks in other languages copied the ideas of RoR, which meant that people did not have to learn ruby, to use RoR. Besides RoR, ruby has nothing else to offer, so as the popularity of language stalled / declined, the framework was ignored as well.
That's the answer I was looking for, thanks user.
Don't see how express website would take a few days. Often the server part of a website is just an API and and then make a front-end client to consume the API.
>Asynchronous programming is always better than the alternative and is a suitable model for every type of web application
Unless your API is doing a lot of intense calculations. It kind of is.
Unless you're writing a server application that needs to handle thousands of concurrent and low-traffic connections (e.g. a Slack real-time message distributor) it's completely unnecessary and you end up writing code that's harder to manage because a function can 'finish' before the operation it's waiting on has requested data.
what is wait/promise/notify
fuck yourself you uneducated plebian
>le i have no idea what im talking about
Mechanisms for writing synchronous-style code with async APIs, thus proving that no-one actually wants to write asynchronous code but they think they need it for their shitty API because the Internet said so and they believe that their app is so incredible that it can't scale using threaded workers, which it probably can.
The reality is that the language runtimes should be enabling the kind of efficiency gains that async programming allows for, while allowing developers to write 'blocking' style code, because it's much easier to reason about.
Sadly these tools aren't common, but I hope that in the future they will be.
>I don't understand the actual difference between blocking and non-blocking IO and am just parroting the usual garbage I read on the web
faster, huge community and Javascript everything
both are terrible
wordpress user here
>something makes your code easy to read
>they don't take the hard way to write code, therefore, they do not deserve the functionality
You must be a fan of C then.
same reasons as 59569819 plus the less need to context switch when coding the client side js.
JS is really popular for web only development because you can use the same language for the frontend and the backend. It's kind of obvious really.
They are both memes, but at least Ruby offers a syntactical upgrade path with Crystal that is basically a better golang.
PS: Don't believe the async nonsense some Noders spout. They don't know that internally the VM is single-threaded and blocking, so for doing actual work in the JS code you need to spawn another process.
>They are both memes, but at least Ruby offers a syntactical upgrade path with Crystal that is basically a better golang.
>PS: Don't believe the async nonsense some Noders spout. They don't know that internally the VM is single-threaded and blocking, so for doing actual work in the JS code you need to spawn another process.
Source ?
For the first part? Check yourself.
For the last part? The JS spec. VM8 and therefore NodeJS are no exception.
So what's so point of clusters in NodeJS? I doubt it's useless
Most likely the equivalent of Pythons multiprocess.
I don't even python, used to at school for algorithmic comprehension but that's all
ES6 on the front-end, ES6 on the back-end
No cache misses. No PHP joes (or Ruby in this case) to mess your shit up.
SANE stack 4lyf.
It's a library that makes handling multiple processes just a clunky replacement for threads instead of a major pita.
Not that multiprocessing is wrong per se, but sometimes it isn't the right tool for every job.
>ES6 on the front-end, ES6 on the back-end
Can't wait for WASM to support GC and DOM access, then it will be
>no ES6 on the front-end, no ES6 on the back-end
The cluster module? It's just an easy way to bounce HTTP requests to multiple threads and use all cores of the CPU.
To do heavy async tasks you do the same as in any other programming language. Offload to queues/microservices.
>The cluster module? It's just an easy way to bounce HTTP requests to multiple processes and use all cores of the CPU without the advantages threads offer and all RAM.
ftfy
neither, use elixir with phoenix
Node.js doesn't deadlock pending network operations. It has something to do with how it processes JS code.
Didn't know this, might have a look when I'm done with Express and ROR. thanks user
Express is not all-batteries included like Rails. If you want something like that for Node check Sails.js
Woa that's what I'm looking for, ty user
Both horrid, though RoR is a bit better. Use Django instead.
RoR is bloated as fuck, and Express is inspired by Ruby's much simpler (and arguably better) Sinatra framework.
The language of Ruby itself is good, but Rails is garbage. That said, I wouldn't use it for tasks requiring decent performance, like a webserver.
>Often the server part of a website is just an API and and then make a front-end client to consume the API.
Yeah if "often" means only popular in the past ~4 years while also not being done by a single major company
go ahead and look at web requests through your browser network inspector of any site you browse and tell me if it's doing the faggy piece meal delivery of a million separate API calls like you pretend is common
This, to be honest.
>Node.js doesn't deadlock pending network operations.
...if you are lucky and your database drivers support the overall scheme. Otherwise incidents like with Redis happen.
>The language of Ruby itself is good, but Rails is garbage.
this
unfortunately often enough
For example, a lot of shitty blog providers like blogspot or medium work that way.
>413 packages installed
I don't know about the node scene. I'm trying to choose between RoR, Django and Node.js and while I like the idea of writing JS for everything this package meme seems to be getting out of hand.
Django looks like the option I'll end up going with just because it seems like everything that's comparable to it in the node world has hundreds of dependencies. What if one of those packages breaks or stops getting updated? What then?
Django is nice. Very easy to write secure code with Django. But node with express is OK.
>What if one of those packages breaks or stops getting updated? What then?
the volume of stupid packages is a legitimate argument but the version control on node packaging would make atleast fixing broken packages easy (at the same time increasing your fuck ton of packages), you would just revert the broken package where if it had any dependencies that had earlier versions would download those too and it would be "isolated" to still work even if you have other packages using newer versions of those packages
I love ruby but it's not something I'd recommend for a team without some serious style/idiom rules.
Isn't Express supposed to be incredibly barebones? I suppose it's worth having a look at if only for a learning purpose.
> you would just revert the broken package where if it had any dependencies that had earlier versions would download those too
It didn't even occur to me until now that some of those packages would have dependencies of their own.
RoR I might take a look at if I can get around my hiccups with Ruby's syntax.
Django is no swiss-army-knife either. But yes express is lean and probably more apt to compare it with cherrypy, but it gets much easier using with something like feathers.