Been playing around with MeteorJS quite a lot lately. What is exciting and fun about it is the fact that you can access the db (mongodb) from the client just as you can with your server code. Until you setup publish and subscribe channels it’s unsecured, but once you do it is secured against malicious attack. If anyone has done anything with it let me know so we can talk how we might do something similar for web apps on The Safe Network. @Viv I’d love it if you could spend 20mins and look at a couple demos so we could discuss.

The web was originally designed to work in the same way that mainframes worked in the 70s. The application server rendered a screen and sent it over the network to a dumb terminal. Whenever the user did anything, that server rerendered a whole new screen. This model served the Web well for over a decade. It gave rise to LAMP, Rails, Django, PHP.

But the best teams, with the biggest budgets and the longest schedules, now build applications in JavaScript that run on the client. These apps have stellar interfaces. They don’t reload pages. They are reactive: changes from any client immediately appear on everyone’s screen.

They’ve built them the hard way. Meteor makes it an order of magnitude simpler, and a lot more fun. You can build a complete application in a weekend, or a sufficiently caffeinated hackathon. No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database, or wrangle an ORM layer, or swap back and forth between JavaScript and Ruby, or broadcast data invalidations to clients.


This looks pretty interesting, having a look.

Looks nice, thanks for posting.

From the documentation:

A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container

I am not sure how that would look in the SAFE environment.

This is amazing stuff; I started it, though put it down because had to go back to python django for one thing for a while;

If one has the time, this is definitely something to know.

This is interesting, I may need to pick this up. Although it would likely look a bit different in MaidSafe, all the principals would likely be the same.

@socketexception I’m still learning about this, but I’m thinking it’ll be one of two things, and someone correct me here if I’m wrong:

  1. Node.js can be installed on the client, in which case Meteor will communicate with the client and “server-side” (local) Node.js installation. A bit off-topic, but it would be cool to have server-side languages installable into the SafeSpace browser as modules. So I would choose which languages (and versions) I would want installed in my browser, such as Node.js, PHP, etc.

  2. If not the above, then Meteor is just an example of how dynamic apps would be made. Realistically, they will just run client-side javascript that makes API requests to the MaidSafe network.

1 Like

Exactly: I think a dynamic maidsafe web app could be done very much like Meteor. I wish I knew some of the Meteor folks. I’m not fully grokking the technologies behind each, but from what I understand this seems to fit perfectly.

1 Like

Thursday field trip to metoer js offices lol;

This video Geoff Schmidt: The technology behind Meteor – May Devshop SF
should give you a reasonably good idea of what Meteor is made of :slight_smile: I’ve been using it for over a month now, and I can’t really imagine going back to anything that I’m aware of that is out there to use. The ease of development is simply too darn fantastic :smiley:

As for Safe network: I dearly hope that people will try to think out of the box rather than attempting to clone what they already know/use. Meteor is a good thing to be inspired by, I think.


This is key to everything behind maidsafe! We can build something amazing for developers. There is always that fear that if things are too different people fear it. I put off learning meteor for this very reason. I was so concerned with separation of concerns that it felt wrong. But if there is no server…

To quote a great English mystic:

The cistern contains: the fountain overflows. (source)

MaidSafe is, by the standard of things as they are, revolutionary to its very core. If I understand its inner workings correctly, it is 100% decentralized and in the hands of users. If one gives to the people what was for over two decades (and at this point of our being on this planet it’s unfortunately a hell of a time) belonging to non-human entities, I think one cannot go more different.
The philosophy behind MaidSafe seems to be tremendously out-of-the-box, so why not create tools that go harmoniously with that rather than spill some fear into the very foundations? No personal criticism here, excuse me if it sounds so. But I really do think that if David and the rest of MaidSafe crew had the guts to dream against the established ways, we should only follow.

It will take time for people to understand and adjust to MaidSafe. The most important thing will be, I think, how easy it is to use it and how accessible and intuitive things are. Different is good :slight_smile:

1 Like

Sorry to bring up an old thread, but I was thinking about this recently and ended up coming to a different conclusion.

The entire idea behind Meteor is that the same code you write can be run on both the client and on the server–a great idea for modern applications, since it means writing much less code (client and server side form validation, for example, would only need to be written once).

However, for the SAFE network, I don’t see how this is useful. All apps, including websites, are going to be client-side, with API calls made to SAFE to retrieve data, or to retrieve more code. If anything, this means that websites are going to made using solely client-based frameworks, such as AngularJS or Ember. A developer would only need to install a SAFE module/plugin that provides a convenient API wrapper to SAFE.

Meteor is really cool, no doubt, I’m just thinking it’s not indicative of what an app on SAFE would look like.


Meteor client can be “exported” without the need of the server and theoretically if your backend isn’t reactive ( don’t provide Sockets, or even better a DDP connection ), you could somehow “feed” your Meteor Client with some “pooling” from a given API.

Considering we are here cause we believe in a “web of the future” i believe we shouldn’t be talking about outdated and ugly things like AngularJS, instead we focus on modern solutions, for instance Meteor + Ethereum ( there are already examples on the web ) / Meteor + Maidsafe and so on.

ps: If you into real Reactive Programming, you might want to check some other cool things like SuperCollider.

1 Like