It seems like a lot of these real-time capabilties should be part of the database layer, à la RethinkDB and its model of continuously pushing query results as they're updated.
This way, you're not locked into one JavaScript-based application development framework.
CouchDB is possibly a better example, as you actually can have single-page applications connecting directly to the DB for streaming updates.
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.
But you can't have clients directly connecting to the database, their sockets still need to flow through an application layer where you have your business / application logic. Unless you start putting application logic into the db?
Your right about this. Couchbase solves it by putting a sync gateway in front of a couchdb connection. But this makes things hard to manage for the reason you mention: business logic inside your DB. All your rules about access control and users are actually derived from values in your couchdb documents. Its not pleasant to design or maintain.
This is a bit tangential, but I really don't get the value of using the same language on the client and the server. The advantages I see would be:
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.
I think the biggest benefit of having the same view layer logic on the front-end and back-end is to send pre-rendered views to the client without having to to generate the markup using two different sets of code.
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.
I sort of agree, I can see virtues, but I've never seen good examples. From all my full-stack work, it's hard for me to imagine really pure isomorphic examples. Definitely we'll have similar patterns and such, and small snippets that work in both contexts, but large functionality line for line code that works in the context of a server and a client, well I've yet to see good examples (anyone feel free to point me to some!). Perhaps that's not the goal of isomorphic code, but if it's just re-using small lines here and there, I can translate from one language to another pretty well.
What about server-side render on page fetch and client side rendering afterwards? Or running business logic client side so the UI appears snappy and then enforcing that logic server-side? This would benefit from the same code running in both contexts. But I agree with your other points, its not a huge deal. Even the points I mention don't seem like core issues.
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.
That sounds good, but it only means that you have to be able to execute the client code on the server. You locally (i.e. on the server) simulate a client connecting and doing some rendering, then send a continuation to the real (remote) client.
Also - does Meteor do anything remotely like this? I doubt it.
Correct me if I'm wrong but things are copyrighted by default, being the creator the owner of the copyright. Unlicensed == copyrighted and therefore not free(libre).
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).
The US govt thinks otherwise. They insist that only by registering a copyright can you protect your work in court. Any 'poor mans copyright' techniques are never useful in court.
That's not true. Registering the copyright allows you to sue over it (but you don't have to register immediately, just before you sue!). Also, registration prior to infringement allows recovery of statutory damages (e.g. big $$$).
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.
Hm. The fictitious 'actual status' might be less interesting than the actual legal standing, right? I'd follow my lawyer's advice on this one (register early).
Ok, I'm from EU.
Then unlicensed == copyrighted is not true everywhere,
but we can agree that unlicensed != free(libre), right ?
I might be simplifying here. :)
No one would actually use this in production code. It is a useful convention for examples so that you can tell you are in server or client code. Occasionally it might be useful in a function that only has a slight deviation in behavior on the server, although usually you would wrap that difference in a function that is implemented separately in client or server only libraries.
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.
This is just one (basic) way to do this. In a real app you put all of your server code in a /server directory, removing the need for the if statements.
The reality of javascript is different in browser and server (node/io).
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)
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.
> 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.
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.
The above comparison was about the difference between JS in browser and server-side.
> 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()
And not having to wrap it in a promise.
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.
> There is no library (promises, fibers) that alleviates the simplicity of being able to do: users = User.objects.all()
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.
I'm currently working on a Express/Angular contract. I'd say the debug tooling in WebStorm for the Express server is more sophisticated than the browser debug tooling for the front end, if only for shortcuts like "run to cursor". And that's even before we get into SpyJS (which to be honest can work on either the front or back end).
