[sametmax]

Using the filesystem as the API has been done before, and there is a reason we stopped doing it.

[rdrey]

Your comment would be more useful if you gave us that reason.

"Filesystem as the API" in this case looks more like "convention over configuration" (which has worked fine for other frameworks like Rails), it doesn't actually seem to be using the filesystem as the only storage backend.

[nilliams]

Don't really agree - what they're doing is very different compared to what, for example Ember does (which they call 'convention over configuration').

Next's routing is much more similar to Jekyll's which quite literally is based on your filesystem file-organisation.

[rdrey]

Ah, I see what you're saying. I didn't consider deeper/complex routes with parameters.

This scheme seems to force route parameters into query parameters. Disadvantage: It's not RESTful. Advantage: Your route parameters are now named query parameters. You only handle one dict of parameters...

I'm not sure how I feel about this.

[sametmax]

It's really not:

- You can't have beautiful URLs

- you can't regroup small related routes in one file

- you can't remap you urls without changing your project structure

- changing your project structure means changing your urls

- now you have part of your url definition in the file structure and part of it in your code logic

- of course it's harder to do anything using virtual routes: load balancing, aliasas and redirections, generating urls on the fly, etc

[namuol]

When was that, and why did we stop?

[sametmax]

PHP + Apache. And we stopped because it's hard to make it evolve and maintain.