Can we please stop with the framework approach? Node.js has what is probably the best package management system out there. Frameworks are really only necessary when you have crappy package management or specific problems. NPM makes is so easy to use libraries liberally and that's what people should be doing.
With frameworks, the framework calls your code.
With libraries, your code calls the libraries.
If you've never taken the libraries approach and are working with a framework, then you are essentially holding a hammer and looking at all problems as nails.
What I'd prefer to hear about is a discussion of Racer, the synchronization library used in Derby.
Actually, we are big fans of modular libraries. We know that a lot of the code in Derby and Racer is too monolithic, and we intend to restructure as the projects mature. For example, we already refactored out Derby's simple HTML parser (https://github.com/codeparty/html) and our wrapper around Express for routing on the client and server (https://github.com/codeparty/tracks). These are now indendent npm modules that were originally part of the Derby codebase. Also, as you mentioned, the Racer data-syncing and model library can be used separately from Derby.
Derby is an npm module, and developers are in control of their own standard Node.js/Express server files. We use Browserify (https://github.com/substack/node-browserify) to bundle up scripts, so you can use any standard npm module on both the server and the client without modification.
We have a long way to go in terms of customizing Derby; however, it is already very flexible in some ways. For example, Derby apps can be rendered and sent to the client from Express routes or via Derby app routes. There's also a method to simply get a blob of rendered HTML or render a static page using the same templates. Derby includes model-view bindings, but it's simple to bind some things and not others or nothing at all.
Much of Derby and Racer is very different from how web apps are written today, and we are focused on iterating quickly to start. As it matures, Derby will become more of a collection of independent modules. That way, most developers could use Derby out of the box, but others could fork the project and customize or use features of the framework independently. It's a ways off, but that's the long term goal.
This is a false dichotomy. Code calls code calls code; frameworks are libraries are frameworks. The only difference is when a library gets big and complicated enough, we call it a framework.
By your silly standard, passing a function to _.each() makes Underscore.js a "framework", which is probably not the point you were trying to make.
It isn't a false dichotomy. Inside of vs on-top-of. Or, you can say that framework code is lower in the stack frames. Or, you can say that you must make your code comply with the framework's execution model. Or, you could say that the framework supplies the organization and you provide the customization.
From this perspective, underscore.js presents an Enumeration framework. However, it is usually a couple stack frames deep and still way at the leafs of your code paths. Backbone.js is clearly a framework -- it describes your data model plumbing and interactions and provides the bindings and pipelines -- this structure dominates the organization of your code and program flow. Nothing about underscore's utility functions have this "infectious" or "dominating" characteristic.
I don't have a strict definition for library and framework, but I think the distinction comes down to more than just size.
A framework is indeed "just a library," but when one is using a framework one is building on that framework, using that structure to construct some new thing. A library I see as something that is called into for some routine, it's a body of functionalities one can tap into. Your code is-a instance of your chosen framework, and it has-a series of calls out to libraries.
"No one agrees on frameworks. It's difficult to get consensus on how much or how little a framework should do. Flatiron's approach is to package simple to use yet full featured components and let developers subtract or add what they want"http://flatironjs.org/ , Philosophy
I agree that the best thing about Node.js is how small, what tiny surface most modules have. Node, hopefully, can stay on this path so far away from the rest of the development world, can be a programming environment where people understand full stack how their application functions. I think not making frameworks or making them out of small modular systems is what it takes to make that win.
The problem was that the HTML-plus-JavaScript paradigm was never meant for building applications. Sure, you don't need a framework if you're just sprucing up some web pages, but if you want to build a desktop-like app in the browser [1], it's nice to get a leg up from something that understands that sometimes we need the humble web page to be something more.
Don't get me wrong--there's plenty of ways for frameworks to get this wrong, but the overall idea is not inherently useless.
[1]: And why would you want to do that? Because desktop apps never evolved some killer features of the web app: lightweight, cross-platform, zero-install, a passable remoting API, and sandboxing.
A few months back I decided to give some time to both Derby and Meteor. Derby appealed because of the packaging, but Meteor obviously had the media traction. I gave 10 days to each to see what I would learn and build.
After the 20 days my biggest problem was with Derby and trying to make progress as the community and support just wasn't there. Of course you might think that one shouldn't complain about this, but its important for the uptake to have clear documentation (it starts well), guides and people involved etc. I think it was Nate that would answer my stupid questions on IRC when he had time, but other than that I was on my own and the feeling I got from others was the same...
Normally I would just read the source, but it was in coffeescript ( glad that Derby has now moved to plain Javascript), and it just wasn't enjoyable when I wanted to integrate with my own datasource from a custom JSON backend - not just another NoSQL database, but an API I know well. I got it working and so forth but it did make me wonder why the hell I bothered and rm'd the git repo.
Doing the same exercise using Meteor the first thing that struck me at the time was their community. The second thing was I was having fun again, and thirdly it was less effort as long as I didn't leave the path too much. But the fact that it didn't have auth and that my datasource was completely exposed and that I couldn't use existing packages was a downside. So I put both to bed.
I hope Derby is getting greater traction and a community is starting to form around it. I also hope that the move to Javascript will make some of the design decisions clearer.
In a few months I will probably give one or other a proper project to work on.
As far as I can tell derby has zero story for datastores outside their json racer implementation. There's too much focus on realtime sync in all these frameworks. Even a realtime app like twitter needs complicated relational data. I want a framework that could build github. Derby does get major points for solving the seo and page load issue though.
In the future we would like to make it easier to do relational queries, but we plan to continue to use document stores instead of RDBMS's. Document stores are more easy to map to the way that data is represented in JavaScript, and they make it easier to reason about versioned data. Currently we support MongoDB, and we intend to support other similar stores like Redis, Riak, Postgres HSTORE, etc.
We just added a lot of functionality to our query system, but it is very much a work in progress. Making it easier to create queries that represent relationships is definitely on our task list.
I strongly disagree with this view of document stores as 'easier' to work with.
For some tasks, this is undeniably true, but for most business problems I think this is just not the case. The profound irony behind this is that schema-less document stores wind-up being so much less flexible due to them being inherently very denormalized.
The good case for document stores is:
1. You have data that really is a blob independent of having relations
2. You need high-performance or map-reduce (Riak, Dynamo, etc.)
Those two use cases are really rare in the real world. For most people there's a huge amount of code that leans on RDBMS strengths such as:
1. Integrity constraints
2. Very flexible ad-hoc queries.
3. Decades worth of work on tooling to mitigate rough edges, and solve tough problems that have come up before.
To clarify, I agree that RDBMS's are fantastic, and you pointed out many of the benefits. We are not religious about SQL vs NoSQL.
For our particular use cases, we think that document stores are a better fit, but I am not arguing that document stores are universally easier or better.
I like Derby over Meteor, without question. But Derby is still sorely lacking in server-side logic, particularly auth, which is what drove my Derby project to a halt. What non-trivial apps can one build without any private or authenticated data whatsoever?
Supposedly these features are coming, and I sincerely hope that derby matures into a real-world tool. The RacerJS tech is amazing, and the library is fun to work with.
We understand that authentication and authorization are critical, and we have been ironing our issues with them using the app that we are developing as a first test. Pretty much all of the required code is already in master, and an example is forthcoming.
Details? My understanding is that derby functions are able to run both on the client and the server, and have access to all data. When I last looked at it (it's been almost a year, if not more), there was no way to use Derby's features without being highly promiscuous with data.
I met with Nate and Brian a while back, both these guys are extremely intelligent hackers with great business sense.
They're currently building a core product that actually has a business model with the derby framework which will help it progress along very well.
While they may not have raised 11.2M these guys aren't going anywhere.
In spending just an hour or two with them their talents really shined through. As a supporter of rails I will certainly be staying on top of changes to both Derby and Meteor and looking forward to what comes next for both.
The reality is the creation of frameworks like these is nothing but a good thing for the hacker community at large.
Congrats on the press guys, Keep up the good work!
I can second this for sure -- they have a combination of intelligence, business ability, and product sense that is incredibly rare. I've twice missed the opportunity to work with Nate, and I hope I'll get a third shot someday. They are also some of the most determined people I've ever met.
I think Derby is really cool, especially the synchronization and conflict resolution model. Though we've made some different choices with Meteor, I think there are many people that will like Derby's direction. Everyone benefits when there are multiple choices.
This is a pretty pedestrian non-technical article about javascript frameworks that have essentially zero market share. Don't get me wrong, they're both totally awesome and anyone interested should check them out. But the article itself is pretty worthless.
My biggest gripe with Meteor is their effort in creating a new package manager. We already have NPM and it works well. I feel that for Meteor to truly be embraced by the Node.js community they'll need to embrace NPM.
Yes. I have played with many js frameworks, including derby, meteor, tower, and several more while attempting to build my toy app http://retr.us . While it is built in meteor, I have concluded that I liked socketstream the best because of the level of control, especially on the server side. It also was the easiest to write unit tests for.
He's not making the argument that money is worthless. He's making the argument that funding doesn't imply technical excellence. Perhaps as a corollary: technical excellence doesn't even imply funding or any other form of financial success (but it sure helps).
Hey, if you're stupid enough to use Derby over Meteor, I have absolutely no right and more importantly, no obligation to help you make the better choice.
Well, develop a program for Linux, and then for Windows. The Windows one will net you more. I'm a Linux dev as well, but I know how things are, I'm not a narrow minded dipshit.
You've taken my argument (money!=quality), and decided to counter it with 'you can make more money developing a windows app than a linux app'. Perhaps you should go into politics... Or go back and re-read the thread... perhaps you'll see how badly and incoherently you come across.
That money is used to make their business more proficient, not necessarily to make the best framework. It is possible that creating the best framework is one stepping stone to making the business proficient, but it is not a given that they will take that approach.
With frameworks, the framework calls your code. With libraries, your code calls the libraries.
If you've never taken the libraries approach and are working with a framework, then you are essentially holding a hammer and looking at all problems as nails.
What I'd prefer to hear about is a discussion of Racer, the synchronization library used in Derby.