Live data from Hacker News

Feathers 2.0 – a minimalist real-time JavaScript framework

blog.feathersjs.com

21–30 of 83 posts

Re: Feathers 2.0 – a minimalist real-time JavaScript framework

#22
post #4

The title (which is not the title of the original article) makes it sound as if Meteor is not open source. Meteor is open source, and MIT-licensed at that.

Ok, we've replaced that with (a less baity approximation of) the original title. Submitted title was "Feathers 2.0 – An open-source alternative to Meteor".

Re: Feathers 2.0 – a minimalist real-time JavaScript framework

#25
post #11

Earlier quoted context omitted.

Disclosure, I'm one of the creators of Feathers. You are right Feathers is MIT and so is Meteor. They both do real-time, albeit a bit differently, so we like to consider Meteor an alternative to Feathers and vice-versa. We are trying to be as transparent as possible and because we don't currently have any formal support from anyone except for the contributor's time and energy, we rely heavily on the community and nee…

Except, claiming you guys are "Real Time" just because you offer a basic websockets implementation and positioning your offering as anything that compares to Meteor is a sham. You don't have real time. You have web sockets that anyone can trivially hook up with NPM. You're undermining Meteor's exhaustive real time functionality when you say that. You are also tricking would-be users who don't know any better. They wi…

Ouch. Meteor's data syncing is great, but it's not a mandatory part of real time.

That said, from their web site:

> Feathers is completely open source and is community supported, whereas Meteor, although open source, is venture backed and has raised $31.2 million to date.

A license is either Open Source (it meets the OSD) or is not. There is no 'completely open source'. I think Meteor's overvalued too, but you're not 'more' OSS than Meteor is.

Re: Feathers 2.0 – a minimalist real-time JavaScript framework

#27
post #22
post #4

The title (which is not the title of the original article) makes it sound as if Meteor is not open source. Meteor is open source, and MIT-licensed at that.

Ok, we've replaced that with (a less baity approximation of) the original title. Submitted title was "Feathers 2.0 – An open-source alternative to Meteor".

can't even scroll page

Re: Feathers 2.0 – a minimalist real-time JavaScript framework

#28
post #4

The title (which is not the title of the original article) makes it sound as if Meteor is not open source. Meteor is open source, and MIT-licensed at that.

I think a much more interesting title would be "An alternative to Meteor supporting 15+ databases and 4 ORMs." I'd imagine a lot of people (myself included) have cooled somewhat on Meteor as SQL support has failed to materialize, so Feather's DB flexibility seems like a standout feature.

Only: there's no real-time db support like what Meteor with livequery does. The term 'real-time' is abused a lot here. Not only does neither Meteor, nor feathers offer real-time in the real meaning of the word. A better word is 'reactive'. But feathers just provides the very basic infrastructure (basically just websockets). Meteor also supports any type of DB, but only Mongo comes with reactivity... (Although their 'apollo' project is looking to change this).

Re: Feathers 2.0 – a minimalist real-time JavaScript framework

#29
post #24

> exposes both a RESTful and real-time API automatically through HTTP/HTTPS and over websockets. Why not both at once with HTML5 SSE?

I think SSE has two limitations that might not make it too useful for some scenarios:

- Each SSE channel would require a separate TCP connection. And as the connections for a browser are limited, you can not support a lot of of different SSE channels. This is mainly a HTTP/1.1 problem, HTTP/2 fixes this. But as browser and server support for HTTP/2 is still limited you might not bet on it.

- SSE can only send chunks of text in each notification, where the possible payload is additionally limited by the SSE encoding (you can't send text with \n\n in it). So if you need binary or abritrary (JSON?) text objects you would need some additional encoding. Like object -> json string -> byte-array representation -> base64 string. This works, but the overhead for your application (must do the encoding) and the browser (must to all the decoding and look for the \n\n) is not ideal.

I'm currently experimenting with using HTTP/2 and fetch API with readable streams to stream arbitrary objects on a bigger number of parallel channels from server to client. This seems to work and looks quite promising for the future, but due to missing browser and partly also missing server support the solution is definitely in it's infancy.

So the current safe bet for enabling lots of notification channels or enabling realtime queries would still be websockets.

Post reply on HN