3 ms·

"There's no overarching design or scheme of things, it's just a bucket of tools with some glue poured in." This premise is wrong, so I almost TLDR'd the post i

by pius 19y ago

"There's no overarching design or scheme of things, it's just a bucket of tools with some glue poured in." This premise is wrong, so I almost TLDR'd the post immediately. I decided to skim further, though: "And to stress the first point again, Rails never concerns itself with the big-picture problem of 'writing webapps.' It only thinks as big as 'outputting HTML strings' and 'querying the DB for a list of things.'" This is provably false. The average reader of the intro chapter of most Rails books could tell you that, for example, Rails enforces high-level application design patterns like Model-View-Controller, thus exposing his statement as factually untrue. The guy seems to have languages like PHP (or, charitably, Ruby) confused with the Rails framework. Nice try by the OP, but ultimately an unconvincing troll.

LogicHoleFlaw 19y ago
MVC, while a valuable application design principle, is not really tied to 'writing webapps.' The article mentions things like the stateless nature of HTTP requests, which are very much bound up in the idea of writing software accessible over the web. Something like Seaside (a Smalltalk framework for developing web apps) is much more aligned with the request-response cycle that is the web. It uses the continuations feature of Smalltalk to map that cycle into a natural language idiom. Neat. Rails is certainly not the be-all and end-all of web design. Lately it seems to be the 'cool' thing to bash Rails, but I'm not sure that that's warranted either. It seems to be a backlash against all the hype that Rails has generated along the way. Time will tell whether or not Rails will become a piece of timeless software or if it will simply fall to the wayside. Until then, go forth and write great software!
- DocSavage 19y ago
  The Rails team has thought a lot about the stateless nature of HTTP requests, and they've pushed for a RESTful style of handling things (e.g., the REST architecture described in O'Reilly "RESTful Web Services" book). Seaside (and Weblocks) seem to focus on continuations, but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.
  - omouse 19y ago
    but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Could you shed a little light on why you feel that way?
    - DocSavage 19y ago
      If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server side. If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations. Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.
  - LogicHoleFlaw 19y ago
    Oh definitely. I didn't mean to imply that the Rails team hasn't thought about things like REST. They are huge proponents of that design philosophy. One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP. Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end. Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back. Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.
    - 19y ago

by pius 19y ago

LogicHoleFlaw 19y ago

MVC, while a valuable application design principle, is not really tied to 'writing webapps.' The article mentions things like the stateless nature of HTTP requests, which are very much bound up in the idea of writing software accessible over the web. Something like Seaside (a Smalltalk framework for developing web apps) is much more aligned with the request-response cycle that is the web. It uses the continuations feature of Smalltalk to map that cycle into a natural language idiom. Neat. Rails is certainly not the be-all and end-all of web design. Lately it seems to be the 'cool' thing to bash Rails, but I'm not sure that that's warranted either. It seems to be a backlash against all the hype that Rails has generated along the way. Time will tell whether or not Rails will become a piece of timeless software or if it will simply fall to the wayside. Until then, go forth and write great software!

DocSavage 19y ago
The Rails team has thought a lot about the stateless nature of HTTP requests, and they've pushed for a RESTful style of handling things (e.g., the REST architecture described in O'Reilly "RESTful Web Services" book). Seaside (and Weblocks) seem to focus on continuations, but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.
- omouse 19y ago
  but I'm not convinced this is the way to go, particularly with richer Ajax and Flex clients. Could you shed a little light on why you feel that way?
  - DocSavage 19y ago
    If you have a very simple app that maps well to CRUD, a REST approach might be all you need. In that case, things are quite simple and scalable on the server side. If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations. Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.
- LogicHoleFlaw 19y ago
  Oh definitely. I didn't mean to imply that the Rails team hasn't thought about things like REST. They are huge proponents of that design philosophy. One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP. Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end. Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back. Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.
  - 19y ago