Nebulous front end dev issue
CSS/Framework/Preprocessor
So CSS preprocessor + CSS framework
Suggestions presently: Bootstrap, SASS, stylus, LESS, Bourbon, NEAT, Bitters
Discussion about the above:
From a CSS preprocessor standpoint, I'm indifferent, and it'll likely be dictated by our choice of CSS framework.
For CSS frameworks, my only remark is that Bootstrap tends to be overkill for freaking everything ever.
Agree RE bootstrap being overkill, it takes me all of 20 minutes to stick grids on things from scratch. Not really much gain there.
And CSS preprocessors are basically a requirement before you can convince me to work on anything but a single page site
@skipchris (sorry, don't know who you are on gitlab):
Just my 2p's worth – Bootstrap is big, but is that a problem? I guess if target users are likely to have poor internet connections, then yes. It is fairly configurable though, so you could only pull in the modules you need.
I think there’s benefit to a project like this using a framework (not necessarily Bootstrap (but Bootstrap is nice!)), rather than rolling its own because they allow collaborators to more quickly dive in and work on things, rather than getting up to speed.
my problem isn't that Bootstrap is large, it's that it's large and ime doesn't offer much benefit over using a framework which offers a grid + a few niceties + some CSS preprocessor -- every project I've been involved in that uses Bootstrap winds up putting most of their frontend effort into overriding Bootstrap's defaults. So, while I'm not strongly opposed to it, my general thoughts are: Using some framework = yes; Bootstrap specifically = nope.
As far as CSS, i am a huge advocate of SASS + Compass + Bourbon/Neat/Bitters . Gives you the benefits of bootstrap without the stupid unsemantic .pushme/.pullyou classnames and shit.
And then, a series of +1s to the above suggestion.
JS/Framework
Discussion about the above:
For JavaScript frameworks, I know Angular already, but I'm fairly indifferent as to which one we use.
@noahke (sorry, don't know your gitlab username):
As far as JS frameworks I'm happy with whatever and learning new things is cool. I think it'd be worth having a clearer idea of our needs though before deciding on how to meet them? As in, what kind of specific site interactions do we see being JS heavy and what would they gain from the framework? A very dynamic interaction like the donation could be a good candidate, whereas the home page might not need it.
As to JS, there's a lot of different tools that can be useful. I'm actually a big fan of knockout.js + Sammy or similar for routing, rather than either Ember or Angular. (Both Ember and Angular fail my "does this code look like Java?" heuristic.) But since i'm not likely to be writing most of it, i'll defer.
Angular's a bit tedious, but very powerful if it's a good fit. I'm not sure whether or not it's a good fit. imo we should build the site without JavaScript, THEN use it exclusively for progressive enhancement, and choose the appropriate library based on what is the best fit for which portions we want to make nicer. Deciding before we have any idea how the site will behave seems very bizarre, to me.
Echoed by a series of +1s.
and then finally in #8 on github
Okay, so! Things that will need lots of JavaScript is mainly profiles and widgets. Widgets should be entirely separate, using APIs to talk to the main site (Gittip did this brilliantly!), so what they use is irrelevant.
I think the main thing we'll need JS for is optionally offering AJAX niceness for editing your profile, editing settings, and changing your donation on other people's profiles.
Really, we want to do progressive enhancement anyway, so as far as I'm concerned we can do the whole site with no JavaScript and revisit this later. It pretty much is just to avoid a few unnecessary page loads.