Meteor Raises $20M to Build the One JavaScript Stack to Rule Them All
techcrunch.com
techcrunch.com
This way, you're not locked into one JavaScript-based application development framework.
(Full disclosure: I work at MarkLogic)
That being said, I think you're right: Whatever DB, server, or client tech you use, the real-time synchronization stuff seems like a minor add on.
Meteor seems predicated on the idea that you can't do synchronization with whatever random stack you want, but need to use Mongo as the DB, Meteor as the server, and Meteor as the client. This is kinda nuts; you can trivially do it with any tech stack. Postges, Express, and Knockout.JS? Sure, will work great. Firebase and React? Super. MySQL, PHP, and some jQuery soup? Yep. (Hint: Don't do that. But it'll work.) And with all due respect to the Meteor team, I think React or Mithril are much better frameworks than what they're developing.
Honestly, I feel like the Meteor guys have such a bad case of NIH syndrome that I'm always slightly surprisd they're using Mongo, and didn't write their own DB too.
1) You need to know / be comfortable with one language less
2) During development, you can easily move functions back and forth between the client code and the server code, progressively deciding what will be computed on the server and what will be computed on the client
3) You can generate, exchange, and execute code in real time between the client and the server
but
1) I don't know any programmer who's both competent and monolinguistic.
3) is of course insane for security reasons
2) I used to think this would be a thing, but once you take the approach of making the client a GUI to an API, this doesn't tend to happen. It's generally very clear what's going to be server side and what's going to be client side.
As for 2, I think it makes sense. You can pre-render your GUI on the server side, so that clients get served proper html rather than an empty pile of js, and then have the same codebase take over on the client side, single-page-app style, just talking to the backend to fetch data.
Also - does Meteor do anything remotely like this? I doubt it.
Other than that, your data access and APIs could be written in any language, if you separate your view logic out. React on the client and server makes it easy to have the same view logic without making a similar commitment about the rest of your business logic.
The symbol it's about being explicit about who owns the copyright. The owner of the copyright can then decide which license to use. Or not use any. But choosing not to license doesn't make you lose the copyright nor makes the creation free(libre).
But don't take my word for it, listen to the federal government:
"Copyright protection subsists from the time the work is created in fixed form. The copyright in the work of authorship immediately becomes the property of the author who created the work. ... The way in which copyright protection is secured is frequently misunderstood. No publication or registration or other action in the Copyright Office is required to secure copyright. See the following note. There are, however, certain definite advantages to registration. See Copyright Registration on page 7"
"Registered works may be eligible for statutory damages and attorney's fees in successful litigation. Finally, if registration occurs within five years of publication, it is considered prima facie evidence in a court of law"
I think you may be misreading that clause. What they are saying is that if the works are registered, you may be able to sue for statutory damages in addition or instead of compensatory damages. This does not mean if the works are not registered, you cannot pursue legal claims, merely that you're limited to compensatory damages. Likewise, they are not saying you cannot prove that you own the copyright unless they are registered, merely that copyright registration effectively shifts the burden of proof.
https://en.wikipedia.org/wiki/Damages#Compensatory_or_expect...
https://en.wikipedia.org/wiki/Statutory_damages_for_copyrigh...
In application code you would put all server-only code in the server directory and that code is excluded from the client code, same for client only code. In plugins, you specify which files are included in the client and server explicitly.
While I find that meteor was fun to work with, we ultimately opted for plain-old express + backbone. I think it's abstraction is more of a disservice. It adds a lot of magic and unknowns to the picture.
After a few months, the initial value of having the unified codebase is exhausted, and you're left with the technical debt of having already adopted their libraries and conventions.
It's not really accurate to say that meteor allows you to use any library, you are adopting their conventions. In the end - using a single unified codebase in JS involves going against the grain in many aspects (I can elaborate if you like)
We are currently evaluating what to use to build a data analytics application (Work with data, ETL, connect to various DBs and APIs, etc.)
Browser: global is window/document
Server: global is global
Browser: interacting against DOM objects and events (clicks, etc)
Server: you are wedged into the function(options,callback) pattern and many promise libraries. you are often using functions as "middleware" or wrapping them in promises.
Browser: bower
Server: npm
Browser: better debug tooling / inspector
Server: sometimes you won't be getting a good traceback unless you know how exceptions work. the way libraries are glued together make errors and error handling hell (practically another job) practice. If you want me to elaborate, please ask.
I could go on to say that most node projects I see in startups are misguided. I could elaborate.
> Server: you are wedged into the function(options,callback) pattern and many promise libraries. you are often using functions as "middleware" or wrapping them in promises.
How much time did you actually spend evaluating Meteor? Meteor is using fibers on the server and thus the code is written in the synchronous style.
> How much time did you actually spend evaluating Meteor?
A week? I saw the fibers dependency.
> Meteor is using fibers on the server and thus the code is written in the synchronous style.
There is no library (promises, fibers) that alleviates the simplicity of being able to do:
users = User.objects.all()
I should add, we went from Meteor -> Express -> Django. It was such a relief to invest time in our features, and not having to have the downsides of every minute DB / API being asynchronous. I could elaborate.
As an counter-example, Sequelize offers both callbacks/promises so you don't have to wrap the query function manually. In fact many libraries provide promise interface or can be promisified with bluebird.
Using ES7 async/await and babel you just write:
let users = await Users.findAll()
Async/await syntax was the feature that made JS development pleasant for me. Brackets and parentheses soup that tends to be produced by callbacks/promises made my pattern recognition sick.