Sinatra, Haml, Blueprint, Sass, jQ. I have a template that does login, tabs, and layout. I sketch in terms of "ghetto REST"; GET /foo, GET/POST /foo/new, GET /foo/1, GET/POST /foo/1/edit, POST /foo/1/delete. I write handlers before I write markup. I write the same %ul#foos // - @foos.each do |foo| markup for every feature I start. Ditto the edit form. Prune down, customize, work out page flows (which is easy once I h…
> But then, I came to web dev from 10+ years of Unix commandline dev. Same here, and I'm beginning to think that that is slowly becoming a handicap rather than an advantage.
If I was 22 years old and trying to impress YC with a demo, or launching in front of the mass market with only my own design skills and no cash for designers, I'd be worried that my front-end skills were hurting me. But after a couple years of contact with customers and prospects: front-end is definitely not what's hurting us.
There are 3 other devs on my team, and while I've been convicted for a while of the idea that we need to hire someone crazy excellent with jQ, we're all former backend people. I think we get things done just fine.
I don't have a "methodology" so much as I have a semiconscious bias towards a process that keeps me typing and doesn't give me a lot of opportunities to stop and noodle --- at least not until I have so much traction that dropping things would be painful.
I know (especially from reading the threads here) that most front-end people have a definite preferencing for designing and wireframing up front. They're probably right. But I don't find refactoring and redesigning to be so painful that it outweighs the inertia I'm fighting when I first start a project. I need to fight past the inertia before I can profitably spend energy on design.