Thoughts on Meteor
Recently, people have been taling about Meteor, a new Javascript framework for Node.js that makes server and client code seamless. It's a really neat concept, but I'm not very conviced about how it would work in a real-world situation.
The main problem is the licensing. It's under a GPL/commercial dual-license, so either you need to license your app under the GPL, or pay money. ExtJs does this, and it drives me insane.
There are a few things that bother me technically about it.
The first is that it's very immature, and is missing a lot of things, like auth. Having full database access on the client is hardly practical. I haven't looked too far into it, but I'm sure there are other kinks.
The fact that you have to "package" template libraries shows that it's not as flexible as writing your own code. It involves adding code to the existing templating library so it can work with meteor (as far as I can tell). And every time that the templating library updates, it has to be re-packaged (which creates lag for security updates).
The mixing of client-side and server-side JS in one file bothers me. Things like this should be very explicit (eg different directories), so that code or other sensitive information (configs?) don't get leaked to the outside world. What if there's a bug where the if(is_server){} block gets sent to the client accidentally?
I'm also wondering if/how it determines which client-side events get sent to the server, and how this affects application scalability.
Synchronous db operations combined with using tons of threads defeats the whole point of using node; you're just wasting memory for each thread. Having one instance of node per cpu is fine, but anything more is just stupid. On top of that, using a one-thread-per-request model is horrible if you're doing any sort of comet stuff, like long-polling. The thread pool would get filled up really quickly under high load (unless they handle all comet stuff in one thread, not completely sure).
Hot code pushes bother me. It may be good for development, but the way session state is saved is iffy. I get the impression that session variables are used way more in meteor apps than in a traditional web app. Given that fact, what if a session variable is repurposed? Will the old values stay? What if the old values are of a different type, and generate type errors? On top of that, usability wise, it's terrible to have an application change while using it. The better way (in the context of UX) would be to have some sort of notification asking the user to refresh the page.
Also, there's no way to paginate objects shown on a page (as far as I can tell). Loading a list of 3000 objects from the server would be pretty slow.
The last thing that bothers me is that there's so much "magic" going on that it's hard to know what exactly is happening. Doing anything outside the typical use case (eg pagination) is very unclear.
There are probably some other issues that I'm just forgetting about right now, but that's what I've got.
Posted by Will Riley
1 comments
NodeJS and Writing Frameworks
I haven't updated this in god knows how long, but right now I'm working on some NodeJS stuff. It's pretty neat. Webdev stuff has always focused around just handling requests, but working in an environment that's always running is cool. Instead of cron jobs, I can just use setInterval.
It took me a month to really get comfortable with, but that's partially because I've mostly been writing a framework for Node, so I needed to learn all the little nuances (like how streams/child processes in it work). Lucid 2.0 is being written in it, so I've pretty much had to see what other frameworks are doing (to figure out what programming conventions are node-ish), and figure out how my crazy gigantic project is going to work. I have a nice thick stack of diagrams I drew up for the project, and it took a lot of iterations and time before things clicked.
Working with node is pretty hard right now. There aren't standard/agreed upon libraries to use, so basically I have to check out every existing library and figure out which one's best. And sometimes, you don't find one that's good enough, so you write your own. Right now I'm working on a sandbox library that fits my needs, because I can't find anything that does. So it's annoying.
One of these days I need to learn how to stop sounding so bored when writing blog posts.
Posted by Will Riley
0 comments
New Website
If you've been talking to me over the past few days, I've probably mentioned the fact that I was going to redesign my site. Well, it finally happened. I'll end up writing more about it when I find the time.
Posted by Will
0 comments