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.
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 need to remain as open as possible.
Personally, I think Meteor has done some amazing stuff and some not so amazing things. I respect a lot of what they have achieved but we are making a different attempt at similar problems. Nothing more to it than that really. We've tried to put up objective comparisons between Feathers and many of the real-time solutions out there http://docs.feathersjs.com/why/vs/readme.html. There is no silver bullet for all situations and all people.
Meteor offers a slew of real time features, propagating real time observation of the database up the stack through your webservers to your views, all functioning seamlessly with feature-packed APIs to query your data and make sure everything is kept up to date.
But I think you know this. Capitalizing on your juxtaposition next to Meteor only makes you look bad to someone that actually uses Meteor. You're trying to convince people who haven't used Meteor--and perhaps don't have much experience when it comes to real time--that Feathers is remotely close of an option if you have real time needs. It's not. And most likely a few months from now you will be using the open source--and decoupled from Meteor--Reactive GraphQL (Apollo) project they are developing as the basis for your real time functionality. Only at that point will you be able to claim your real time--but that's beside the point.
You've been around for years, and now your framework is just "a few hundred lines of code"?? That's because you're likely taking the marketing value of having been in the game for a few years (though minimal value compared to claiming you come remotely close to competing with Meteor), and using the name "Feathers" to back your latest reincarnation where your mix-n-match a hodgepodge of NPM libraries that anyone can easily do. Sorry you had to throw away a bunch of code--I know how that goes--but call it what it is instead of all this dishonesty: your latest NPM boilerplate. The newer and humbler Meatier boilerplate offers more realtime than you do!: https://github.com/mattkrick/meatier . And its author doesn't attempt to presume it's anything more than a highly useful boilerplate.
THESE GUYS (FEATHERS) HAVE NO REAL-TIME OFFERING, EVERYONE. DON'T BE FOOLED. If Real Time is what you want, these guys are not it. I find The dishonesty of their marketing unappealing and I hope anyone reading this does too. They are capitalizing on the "Meteor" name and its deep association with "real time" functionality, when in fact they are nothing like it.
> Feathers has adapters for 15+ data sources and 4 different ORMs out of the box. More than any other real-time framework!
Huh?
All my code is bloated and messy, tbh.
If that bothers you then regain your composure by remembering that 'computer' once referred the operators of calculating machines - not the machines themselves:
https://en.wikipedia.org/wiki/Computer#Etymology
Language changes.
In this case, the existing meaning of "real time" is not obsolete, so the analogy does not work.
---
Next, just because language inexorably changes over decades, generations, and centuries, does not mean that a subculture deciding to use an existing word in a different way is "The language changing."
It's just a subculture deciding to use a word in a different way. When they go forth and use that word outside of their niche, and there is confusion because they mean one thing and the rest of the world means another, the subculture does not get to shrug and say, "language changes."
When you use words, it is your responsibility to know your audience and use the words your audience understands, in the way that they understand it.
And so it is with technical terms that have established meanings in the computer science and programming community. By all means redefine what "class" or "type" or "realtime" means. Use your definitions within your subculture with abandon. But be aware that when straying outside of your community, it is your responsibility to use terms that your audience understands, not your audience's responsibility to presume that all bets are off, and any word might mean anything.
---
Finally, I question the tone of "sorry." Perhaps you didn't mean it that way, but it has an air of the arrogance of a pop culture programmer. "We're inventing new stuff here, no time for your old ideas, daddy."
It would be helpful if instead of snark, you responded with an actual explanation.
Especially since a quick search of "real time javascript framework" doesn't return one. The most relevant result suggests that a chat application or dashboard is "real time". When it's really just two-way communication (sockets et all).
In this context, it doesn't appear to mean anything at all AFAICT (aside from marketing) as any framework with some minimal helpers supporting sockets could use the label. Or not... since despite your response, it's possible I've misunderstood since it's not actually a "web development community" bit of language AFAICT. Having been a member over a decade.
This is a very good question. We're definitely planning on adding a section about performance and scaling to the documentation very soon.
Also, mentioning Meteor, totally not needed.
Why not both at once with HTML5 SSE?
- 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.
I just wish the authentication was a little more robust. I like that they realize stateless auth is the way to go but how about we get rid of those passwords too!
As far as passwords go, I assume you are referring to passwordless auth? We are working on that right now :). https://github.com/feathersjs/feathers-authentication/issues...
Is there any reason why this wouldn't work with Cordova?
