I am ecstatic to see that some node.js frameworks are trying to move toward being aggregations of standalone modules rather than growing into monolithic coupled frameworks.
Monolithic frameworks are plentiful in the PHP community, but recently some of the larger frameworks have started moving toward this aggregate component model. Unfortunately, the PHP frameworks are much older than node.js, so many of the corresponding micro-communities are entrenched in the idea that their framework is "best". This means that while it is awesome that frameworks are allowing you to consume individual components, you still do not see it happening very frequently. You almost never see the frameworks themselves sharing components, for example.
Obviously the module system baked into node.js helps steer the community toward the concept of consuming modules, but I'm optimistic that the community is also young enough to completely embrace the idea of frameworks being little more than aggregates of the most common modules for building apps and also that "sharing" between frameworks is not something to frown upon.
One big difference is that Node.js had an easy way to share small libraries between projects almost right from the beginning. Something like NPM is only now starting to appear in PHP, and seems to be slowly breaking projects out of the reinventing-the-wheel mindset. A great example is Drupal using the Symfony2 HTTP foundation (request and response objects, etc)
I really like the fact the the code is shrinking. It's refreshing to be able to read and understand all of the source code that your apps are using.
There are a few changes that worry me:
* req.get() instead of req.header() - 'get' is an ambiguous word here, might be confused with req.params(). I'd keep the overloaded req.header() just dropping the `defaultValue` parameter
* res.render(404, 'not here') doesn't work anymore. res.statusCode goes against the rest of the 'minimal' api like res.xhr and res.type
* removal of layout/partials (but curious to see what will come out of it)
What would you suggest in lieu of the layouts/partials for visual elements?
The Django community has issues with this from time to time, where packages sometimes don't include any templating, leaving people to guess at what needs to be there.
I don't know of an obvious solution though, except maybe a kitchen sink example of some sort. Thoughts?
Up to the engines now, Jade implements django-like inheritance and includes, same with swig and a few of the others. There are a few that do not have any notion of IO so I plan on having a third-party implementation of the old partial() function, removing it greatly simplified the view system for people who were not using it previously anyway, and some of the rules partial() employed were needlessly confusing (collections etc).
I expect at least the most used template engines to re-implement both partials and layout as they were. They will benefit from custom cache strategies, but I don't see reason for radical changes. I wish one like jqtpl was made default :)
req.get / res.set are obvious in use so it's not bad (res.set('Content-Type', 'application/json')). I'll likely keep the old .header() methods for BC. "res.render(404, 'not here')" never worked, maybe you mean res.send(404, 'sorry')?
oh I see maybe you meant res.render(view, {status: n }), the problem with that is that people were passing non-numeric values there, causing bugs because they were not aware of "status" being special-cased
I came to node from C so the syntax was pretty straightforward. I wanted a fast framework and was considering cppcms but, the amount of libraries already present in node made me tried it.
The framework is very powerful and we can push code very fast using it so no regrets!
I have experience in Python (wsgi, paste, pylons, GAE) and ASP.NET (MVC). I like programming using node/express - node packaging system is very simple, express code is understandable and very readable. There are some things that you do not get out of the box but overall that's minor problems.
The only problem for me as automated testing and in result I have written my tests in Python.
The only problem for me as automated testing and in result I have written my tests in Python.
To a Ruby developer like myself, this seems like a pretty significant gap.
Have you looked at Jasmine or some of the other testing frameworks for Node? Or is there something inherent about writing async apps that makes them difficult to test?
There are some good testing libraries for node (eg. https://github.com/visionmedia/mocha, by the same author as Express), that make async testing fairly painless. However, there are things like DB setup/teardown that aren't integrated and you might be used to getting "for free" with other frameworks (eg. Django). I'm curious to hear what the parent commenter has found to be a roadblock.
Here is a little bit of background. I'm writing RESTful service using node and I really like how easy is to write async code. There are tools in node that allows me testing it - one example here https://github.com/flatiron/api-easy but there are more that I have considered. The problem I have with all those options: I need to write too much code to produce simple test. Python unittest and python-requests modules allow me writing much simpler code that actually does the same. There is simply no sense writing async code for unit-test like testing. Node is good for writing async code and I'm really happy this that.
Client side async code has its own place as well. I really enjoyed writing complex load tests with node. That was simpler than investigating python options and node is faster in such scenario.
It's always going to be a little annoying with node's callbacks, but they dont have to be large. In connect all I do for an http test is (with mocha) https://gist.github.com/a5f796fff5fc72748e1b
A lot of it definitely comes down to API, but when it comes to callbacks I would agree
Monolithic frameworks are plentiful in the PHP community, but recently some of the larger frameworks have started moving toward this aggregate component model. Unfortunately, the PHP frameworks are much older than node.js, so many of the corresponding micro-communities are entrenched in the idea that their framework is "best". This means that while it is awesome that frameworks are allowing you to consume individual components, you still do not see it happening very frequently. You almost never see the frameworks themselves sharing components, for example.
Obviously the module system baked into node.js helps steer the community toward the concept of consuming modules, but I'm optimistic that the community is also young enough to completely embrace the idea of frameworks being little more than aggregates of the most common modules for building apps and also that "sharing" between frameworks is not something to frown upon.