3 ms·
None. For me it's static site generation where it makes sense (cron jobs scale beautifully), sometimes Sinatra, and otherwise, Rails. They all work fabulously
by ahoyhere 17y ago
None. For me it's static site generation where it makes sense (cron jobs scale beautifully), sometimes Sinatra, and otherwise, Rails.
They all work fabulously and I can't imagine why I'd spend time trying to change tools, when I can get better at designing software and business processes.
- sant0sk1 17y agoTo me Cappuccino presents an option that I've never had before: build rich web applications without having to deal with HTML and CSS. That's incredibly attractive and reason enough to change tools. Also, since its a completely client-side framework, it can still work together with server-side frameworks like Sinatra and Rails. That means I haven't lost the time I spent learning Ruby.
- gcv 17y agoYou could have also used GWT. The few Cappuccino apps I have seen are more attractive, but that might just be because GWT apps tend to be written by Java people and Cappuccino apps by Mac people. Hate to make a gross generalization like that, but Java apps with UIs rarely look good.
- ahoyhere 17y agoIf you don't deal with HTML/CSS, someone else will. Which means your app will look like what someone else decided was good. That's not good enough for me.
- gcv 17y agoThat's a fair point, but let me ask you: if you learned to write webapps Struts running on WebLogic back in 2000, would you still be using it today? By some measures, they also "work fabulously."
- ahoyhere 17y ago"Works" is not the same as "works fabulously." Import statements and public main void() are not, in my opinion, "fabulous" in any way -- except possibly "fabulously bad." I started with BASIC. I learned PERL and did some CGI stuff with it. Then I learned PHP. I used PHP for a long time, and would rate myself as expert level, especially based on writing good solid OOP code and using good OOP principles. Now, I was happy with what I could do with it... until I wasn't. It worked, but not fabulously. Then I saw some Rails controller code, my jaw dropped, and I knew I had to learn it. My growth as a PHP dev had been, in retrospect, largely about mitigating the crappiness of PHP. Ruby is a different ballgame altogether. I haven't had that experience with anything else since. Probably some day it will happen. But til then, the only complaint I've possibly got against Ruby/Rails/Sinatra is that deployment is not the easiest thing... and that's an ancillary problem I rarely have to deal with. Most of the other things are new for the sake of being new. I looked into Seaside over 2 years ago. I find it cumbersome, and I asked a question at a Seaside talk, similar to one of the other commentors here, about the templating -- which has to be done that way for the object/state serializations -- and Avi Bryant was a dick to me, to boot. I'm sure it works great for what he's doing, but it doesn't appeal to me. I don't need or want to write revolutionary data transformation software. I want to write the best damn webapps for "boring, simple" problems that everyone else thinks are solved -- that have yet, in my mind, to ever be given a thoughtful, amazing UI. So Ruby and Rails are practically custom-made for me -- and, as I said, they work fabulously.