Node.js: fork - yes or not?

I think use Node.js is much better than RoR. (IMHO)
Changing the language will be famous news.
But i think this is not loved thema.
Changing anything big will take many time and financies.
Diaspora hasn’t any financies (i think) and time can be used for other features/improvements.
But when will somebody fork this project and rebuild it to Node.js what will say the crew?
Do you accept forks of your project or will you continue with justice?

Thank you for any answers


Note: This discussion was imported from Loomio. Click here to view the original discussion.

No. The amount of effort to shift from one platform to another does not justify the result. We would basically have to rewrite all of Diaspora from scratch.

Instead, I think a better motivation would be to ensure that Diaspora can be set up and deployed easily.

While it’s true that currently most Rails apps run on cloud services such as Heroku and Amazon, the Flynn project intends to take the capabilities of a Heroku-like service and put it on any Linux server you have, making application deployment that much easier.

diaspora* is free software so everyone is allowed to create forks.

As @steffenvanbergerem said it, diaspora is a free software.
As long as you respect the terms of the license, you can fork it, modify it, change the language if you want.

You can find more about the license and the copyrighted content (like the name) here: https://github.com/diaspora/diaspora/blob/develop/COPYRIGHT

In me opinion the big brake for diaspora is installation, updating and administrating.
I have one installation on me own server, but installation wasn’t as easy as i think.
I don’t have idea to update or setup autoupdate.
Administrating and changing design is one big nightmare there.

Anyway, when will be there solved updating, administrating and customize design it will be famous software.

When I sad about administrating i have idea about administrating area with possibilities do the updates, delete users, create design changes etc…

Ah, another manifestation of shiny-new-shit syndrome. Now that Rails has become older and more stable, web developers look for the new bleeding edge language/framework and seek to rewrite the universe once again. Even if it were true that node.js and JavaScript were technically superior, which is not true, the amount of work required to rewrite an established codebase would only ensure that diaspora makes no real progress towards its actual goals. You’re free to fork, of course, but I wouldn’t expect any contributors to follow you.

Node.js is fast, yes, is the last up-to-date thing, yes, but what about JavaScript? Well, the little I saw is not so good: it seems (at least for me) that that language wasn’t created for big projects…

I feel more comfortable using Ruby, and Ruby on Rails is a big and nice framework to start and continue a project like this, not to mention that is also Free Software (as in freedom). Also, there are lots of tools that make everything a bit more easier (like modifing the database and templates for controls and view).

Well, I prefer that we concentrate in things like an easy and fast install instead of using our efforts to rewriting all from scratch.

I still remember all the headaches that identi.ca had when the site migrates, Evan promised three months before it really started to work! Later, it had lots of errors and, maybe there still are more. I think he was very enthusiastic but he couldn’t accomplish what he said and, in my opinion, it was because all the tools he used including the JS language. However, I like what identi.ca achieves: a great federational feature, but it did thanks for the relatively easy install (it tooks me only 20 minutes + download time!).

That’s my point of view about this…

I think one of the reasons for choosing Ruby on Rails for this project was that Ruby is considered a very easy language to learn, which lowers the barrier to contributing to the project. Very important in an open-source project like this…

Ok, thanks for all suggestions.
And one little information for me:
Is it on plan: customizing design (for example use self css or scss in case update), administration area and updating the project with updater or autoupdater.

Thank you all

Once the federation is in it’s own gem, outside the diaspora server code, anyone can port the federation as a node module and create a server in node. Who says diaspora* has to always be just RoR servers?

I mean, we already have Friendica talking with diaspora* servers.

@jasonrobinson While your point is valid, it wouldn’t really be Diaspora, just some Diaspora federation-compatible application. :wink:

@seantilleycommunit in a way true, if you talk about diaspora* as the server software. I’d rather talk about it as a network :wink:

@maxsamael you should check out Libertree!

That’s fair, but Diaspora’s definition as a network has traditionally been mostly a network of Diaspora pods and Friendica servers. The groundwork we use to make this network communicate is sort just a bunch of partial implementations of standards and rubber bands duct-taped together at the moment.

It works, but I suppose it’s worth asking ourselves whether we should improve the foundations for federation and data before encouraging people to build apps and sites that are a part of our network. We do, after all, want to offer a congruent experience for everybody on the network. Especially when you consider how many decentralized social platforms still don’t federate with each other.

@christophe I don’t want use anything else as diaspora project.
There is many negatives.
I want support the diaspora with new modules (plugins), improvements, servers, bug fixes, donations, etc…
In all means there is much to work and I don’t waste me time with X other projects. I <3 diaspora and I want use it :slight_smile:

whether we should improve the foundations for federation and data before encouraging people to build apps and sites that are a part of our network.

Yes! Definitely.

I realise I’m saying this, knowing that I won’t be able to help at all with this task…

Node.js is meant to be run as client-side javascript. RoR is a server-side technology. It doesn’t make sense to run D* in a javascript layer, and if you have much experience with javascript, you would cringe at this thought. That’s not what javascript was built to do. I vote no.

@ram518 Please check Wikipedia: “Node.js is a software platform that is used to build scalable network (especially server-side) applications.”

@ram518 You don’t have truth at all.
Node.js can be used as server side only. Alternatively you can use Angular or other infrastructure. In this case is there client side javascript.
Anyway you can check some comparsions about speed.
Node is excellent software for API, you can divide the user area and API.
In case speed is RoR now good, but not brilliant.

Next point, i think decentralization and security is in all means answer to this type of network. (IMO)