4 ms·

I think part of the problem is that MVC is pretty heavyweight. Most UI doesn't need that kind of flexibility, but when you want it, you want it. So you need a

by prewett 11y ago

I think part of the problem is that MVC is pretty heavyweight. Most UI doesn't need that kind of flexibility, but when you want it, you want it. So you need a way to make it simple most of the time and still have access to the details. In web development it is probably complicated by that fact that, in my opinion, declarative positioning and sizing of elements is a pipe dream. It looks simple until you try to actually implement it, and HTML/CSS has only a rudimentary implementation. (As far as I know, Motif and Apple's constraints are the only UI toolkits that have a solid implementation) Given what we want to do with the web these days, I think we would be better off with programming the web page declaratively. Something like what Qt does. I've never found an easier way to write a UI than Qt.

brightball 11y ago
You nailed it. MVC was popularized because after enough people went and just threw together random things for enough projects, turnover, learning curve, switching between projects, etc just became a huge burden. The big sales pitch for MVC on the web (largely influenced via Rails) was a good enough common structure for web apps that developers could learn and apply across projects. It worked in that regard, but as usage became more popular we ended up adding on more and more and more and more to try to make the "common" solve everything. Constant changes screw the entire point of the "we all learned and know this" benefit. Flexibility of your approach is probably more important in the world today than following a rigid structure in an attempt to let the structure solve everything. I like the approach outlined here...but I'd have a hard time using a framework based on it. I'd rather write my own code using a simplified process and minimizing dependencies if I'm going outside of something that's clearly a major player that can be counted on to stick around.
- coliveira 11y ago
  You just mentioned something very important: minimizing dependencies. Open source frameworks are sold as a way to minimize development complexity, but they add the big pain of depending on external packages that frequently change without notice. If you develop you own code, at least you know what and how things changed.
  - superuser2 11y ago
    >frequently change without notice Unless you are doing something so spectacularly, mind-blowingly irresponsible in your dependency management that changes just come in of their own accord (i.e. Go's defaults), no they don't. They change when you choose to vendor the new version or change the pinned version number. It's true that your dependencies won't get security updates until you decide to upgrade, but other people are certainly not writing security updates for your in-house code. You should care about the code quality of the 3rd party libraries you use, with the understanding that you might one day take over maintenance of them, at least for internal purposes. That's still not a reason to duplicate effort.
- mtberatwork 11y ago
  Not trying to be argumentative, but MVC was popular in web development well before RoR came on the scene (Struts for example). When RoR came on the scene, it was during a time when there was an explosion of MVC frameworks in languages other than Java (Django, CodeIgniter, Zend Framework, etc). I would argue that RoR's popularity stems more its use of Active Record and all the buzz surrounding that at the time.
  - brightball 11y ago
    I remember. I started out with Struts too but Rails was the first framework that got things to a mode of operation that people started trying to copy in every other language. That's the main thing that I meant. Rails was the first that did things in a way that everyone else tried to emulate.
    - Cthulhu_ 11y ago
      That's what I was thinking; the boom in web frameworks started right after RoR was released. I still consider RoR to be the framework that popularised the MVC paradigm in web applications (but I might be wrong / have an incorrect point of view)
deleted 11y ago
[deleted]

by prewett 11y ago

brightball 11y ago

You nailed it. MVC was popularized because after enough people went and just threw together random things for enough projects, turnover, learning curve, switching between projects, etc just became a huge burden. The big sales pitch for MVC on the web (largely influenced via Rails) was a good enough common structure for web apps that developers could learn and apply across projects. It worked in that regard, but as usage became more popular we ended up adding on more and more and more and more to try to make the "common" solve everything. Constant changes screw the entire point of the "we all learned and know this" benefit. Flexibility of your approach is probably more important in the world today than following a rigid structure in an attempt to let the structure solve everything. I like the approach outlined here...but I'd have a hard time using a framework based on it. I'd rather write my own code using a simplified process and minimizing dependencies if I'm going outside of something that's clearly a major player that can be counted on to stick around.

coliveira 11y ago
You just mentioned something very important: minimizing dependencies. Open source frameworks are sold as a way to minimize development complexity, but they add the big pain of depending on external packages that frequently change without notice. If you develop you own code, at least you know what and how things changed.
- superuser2 11y ago
  >frequently change without notice Unless you are doing something so spectacularly, mind-blowingly irresponsible in your dependency management that changes just come in of their own accord (i.e. Go's defaults), no they don't. They change when you choose to vendor the new version or change the pinned version number. It's true that your dependencies won't get security updates until you decide to upgrade, but other people are certainly not writing security updates for your in-house code. You should care about the code quality of the 3rd party libraries you use, with the understanding that you might one day take over maintenance of them, at least for internal purposes. That's still not a reason to duplicate effort.
mtberatwork 11y ago
Not trying to be argumentative, but MVC was popular in web development well before RoR came on the scene (Struts for example). When RoR came on the scene, it was during a time when there was an explosion of MVC frameworks in languages other than Java (Django, CodeIgniter, Zend Framework, etc). I would argue that RoR's popularity stems more its use of Active Record and all the buzz surrounding that at the time.
- brightball 11y ago
  I remember. I started out with Struts too but Rails was the first framework that got things to a mode of operation that people started trying to copy in every other language. That's the main thing that I meant. Rails was the first that did things in a way that everyone else tried to emulate.
  - Cthulhu_ 11y ago
    That's what I was thinking; the boom in web frameworks started right after RoR was released. I still consider RoR to be the framework that popularised the MVC paradigm in web applications (but I might be wrong / have an incorrect point of view)

deleted 11y ago

[deleted]