#bookbrainz-devel

How would you guys feel about switching from Express to Sails? It's built on Express but with modeling as well. I need to look into it more, but just putting it out there.

[bookbrainz-site] LordSputnik pushed 2 new commits to master: http://git.io/p6LK

bookbrainz-site/master e156e0e Ben Ockmore: Fixed errors in relationship editor caused by missing ko field, and copy/pasted code from another form.

Hmm. We could just pull in Waterline from Sails.

I think we should just go with Oars.

Leftmost: yes let's switch to sails

It looks like it does lots of things right, and we'll be better in the long run

We'll want to swap in gulp for grunt though - let's talk more about switching at the meeting

>_>

http://bookbrainz.org/creator/5cd80a97-e425-4e3... :)

Great man, great legacy

I should get my "use-less" stuff done some time

it includes a few CSS changes

LordSputnik, oh dear. I am sad to hear that he has died.

I wouldn't be against him as the first row in the database, as a tribute.

(Well, I'm just assuming it's Pratchett.)

Freso, we'll be holding a vote for that, but such tributes are perfectly valid reasons for nomination. :)

LordSputnik, do you know enough about sails to know what it brings above express + waterline?

I know you will.

I don't really have that much node experience, but I'm kinda feeling like this dependency stuff is getting kinda overboard, we recently switched to gulp and now going back to grunt is being talked about. Now throwing express overboard and going with something else is being discussed again...

Leo_Verto: no, the point I was making earlier is we'll need to tweak Sails to use gulp

But Sails is pretty good, it can handle all of the front end compilation when we launch it

It also uses express, so all of our code will require very little modification

From the test I did earlier, it seems to be fairly easy to set up, even with gulp

The main thing is, I feel like we'll end up implementing a lot of the stuff in Sails ourselves if we don't use it, which would be a waste of time

Oh, and it has built in support for multiple languages, apparently

LordSputnik has changed the topic to: http://bookbrainz.org | https://github.com/BookBrainz | Want to help? Grab a task from http://tickets.musicbrainz.org/browse/BB | Agenda: Milestone requirements, guiding principles, data license (Leftmost), HTTPS (Sput), Switching to Sails

Leo_Verto, always throw away the prototype.

The whole point of taking some time right now to stabilize the base is to figure out what we need to throw away and what we should keep so that we're not trying to do this once we've started collecting data.

It's better that we structure the app in the best way now, so that we don't end up with 20 different root directories, each with 20 subdirectories containing mixtures of filetypes for various purposes like MusicBrainz has

One of the reasons I suggested sails is because we wouldn't have to throw the baby out with the bathwater.

It can also do nice things like precompile our Jade templates

hmm, jade caching does sound like a good idea

It also gets us data models, which prevents me from having to write them.

One thing I noticed was that it talks about being a "backend" framework rather than a "frontend" framework. I don't know what the hell that means, but okay.

o_O

Hmm?

that's kinda weird, maybe just people using a different definition of "backend"

The docs suggest that it's best used for REST APIs and whatnot instead of requests.

It means "server-side" rather than "client-side"

It can be used for REST APIs, or serving HTML, just like express can

LordSputnik, no, they don't mean server-side versus client-side, they mean HTML UI versus REST. Which is why I am confused about it.

Okay, some notes on sails looking through their "concepts" page: there seems to be a certain amount of migration baggage that we would have to undertake, whether we choose to do things our way or the sails way, since it prefers to expose its own controller objects rather than the express router.

Leftmost: "A "back-end web" framework helps you do things like build APIs, serve HTML files, and handle hundreds of thousands of simultaneous users. Sails is "that kind" of web framework."

"Sometimes, when we refer to the "web", we mean the "front-end web." We think of concepts like web standards, or HTML 5, or CSS 3; and frameworks like Backbone, or Angular, or jQuery."

LordSputnik, perhaps I misread that, then.

It also has some additional baggage that I don't think we really need, like their middleware stack thing, which appears to be sugar for app.use(), and kind of annoying sugar at that. The two things I see us needing from it would be models and i18n, both of which it handles with external libraries.

(waterline and i18n-node, respectively.)

I kinda liked its middleware configuration thing

I think it'll be easier to use it all together than take parts of it and bolt it on to what we have

I don't think we'd be bolting, really. We'd use it in much the same way we'd have to use it with sails without really any additional work, as far as I can see.

Their i18n module also appears to use custom JSON files instead of a standard format like PO.

JSON for translations isn't that bad, it's what I did for waveplot

It's bad in that I can't use any of my standard translation tools to do the translation work.

I'd much rather we use a gettext-based lib.

Ok, I'm sure there are others

Perhaps let's just user waterline for now then

A quick google came up with node-gettext, which looks workable.

LordSputnik, I think that makes the most sense. Worse comes to worst, I think that we'll be able to switch to sails without too much difficulty since we'd still just be using its ORM.

I think I'm just wary of using solutions that try to do too much for us, since my experience with such solutions has been that I typically want to do things differently.

One of the guiding principles I want to propose also is to, as much as we can, avoid relying on any one technology. A better one always comes along, and I think MB has struggled a fair bit from that sort of reliance.

Leftmost: Ok, let's talk more about that tomorrow, I have to go now

Alright, works for me.

See you tomorrow.

[bookbrainz-site] leftmostcat pushed 1 new commit to master: http://git.io/pD7O

bookbrainz-site/master 0f1a860 Seán de Búrca: Set configuration based on environment

Hey, just came back to say, I'm not convinced waterline will be as suited to defining models as backbone - waterline doesn't seem to be aimed at using a web service, while backbone is

LordSputnik, I don't think there would be any issue at all with using a REST adapter for it, whereas backbone would pull in a whole lot of other stuff we don't need or want.