11 ms·

People have a hard time with MVC because frameworks that use the phrase MVC are always more complex than necessary. There's a simple set of separations that yo

• jdubray 11y ago
  Sorry, but you just don't get the fact that SAM is reactive/functional and what benefits you can drive from it.
  • samstave 11y ago
    I am certainly reactive, but also functional - so thanks for that.
    • Gratsby 11y ago
      It took me 2 hours to realize how funny this comment was.
  • deleted 11y ago
    [deleted]
  • Gratsby 11y ago
    I didn't address SAM at all, other than pointing out that the author's figure did not have a separation of code and display.
    • jdubray 11y ago
      Can you please re-read the paper, the whole point of the pattern like Cycle.js is to separate logic from effects. Logic != Code
      • Gratsby 11y ago
        Oh boy... I take it that you are the author and I've completely derailed your thread by going off on my own tangent. Apologies. I will give it a second read and see if I can't come up with some more relevant feedback for you.
  • piva00 11y ago
    Can you expand on the benefits you can drive from it? Just getting a snark reminder about how someone doesn't "get" something is not helpful.
• gcommer 11y ago
  I agree with your big picture, but I think point 1 is giving too much importance to HTML. You can have proper separation of M, V and C whether your HTML output is defined in a dedicated template file or in a .js file. At a high enough level of abstraction, they're both just different ways of defining a function from an app state to UI, so in terms of overall app architecture, there is no difference. The only material difference I've ever seen is that when people define their HTML output in template files, they have to invent a whole separate language for doing basic control structures like conditionals and looping. Why re-invent the wheel when you can use the same language that the rest of your app is programmed in?
  • fpoling 11y ago
    The point above is that the designer does not know how to code that I agree 100% with. So any JS implies that either the programmers are doing the design or they extract the GUI from the design wasting time. In fact even templates can be too high barrier to ask a designer to use them, but at least with templates the design->working site conversion is simpler and any competent programmer should be able to learn the templates. I also find that asking the designers to put keywords in the site mockup and use that as ad-hock templates could work rather well.
    • jhoffner 11y ago
      This argument doesn't make sense to me. Regardless of how the design is implemented (JS, HTML) - the designer shouldn't care because they are handing off the design to the developer as a pdf, sketch, etc. file. If he/she is both a designer and a front-end developer than great - he/she knows how to code. What's the problem?
• jacobr 11y ago
  Regarding 1. You need to build your architecture with your (current and future) organization in mind. If you don't have people in your project/company who only know one particular technology ("web designers" writing HTML/CSS) there is no need to separate that particular technology from the rest of your "code". If that fits your framework better, of course you could separate those technologies, but I don't see why you should build it like that just because.
  • Gratsby 11y ago
    It's not just because. It is a foreseeable problem that you will have to support multiple display layouts with the same set of data. It is a foreseeable problem that you will need to train and delegate. You can be the full stack guy today and learn everything you can about all aspects that you are interested in. It's a great way to learn. But if there is no logical separation in place, you are stuck where you are until you either refactor the entire thing or you find somebody who went down the same path and has the exact same skill set as you. Not segmenting your code is stupid. Plain and simple. If you want to see code that doesn't separate things logically, have a look at old vbulletin or phpbb code. Look at what happened historically in both of those projects. Think about what it's like to add a new feature when you have 40 php pages that you have to touch, each written by a different developer, and each with html mixed in with the php. You have to know the whole set of code in order to do anything productive. The end result for both was security problem after security problem and a design that has not transformed significantly in 10+ years. You can buy yourself job security by building a project that requires the developer to know a specific language, an MVC library, a specific version of HTML, a particular javascript library, and how to interact with web apis from two vendors from both server side and client side code. You can earn yourself a promotion and new interesting things to work on by building projects that you can walk away from.
    • arnorhs 11y ago
      > Not segmenting your code is stupid. Plain and simple. And overly broad, generalizing statements are not? Remember to be respectful towards your peers.
• RyanZAG 11y ago
  > 1. Separate your code from your data. You shouldn't be kicking out HTML with your code, like this guy does in figure 1. When you combine HTML or any display information with code that means your designer is your coder and your coder is your designer. Designers suck at code. Coders suck at design. Keep that shit separate. How do you feel about the common case where there is one person for both coder and designer roles? This is extremely common. Your comment makes it sound like the coder and designer are always separate people when in reality, for most websites, the front end coder is the designer.
  • ryanSrich 11y ago
    Designers coding is fine. Designers programming is not.
    • timlyo 11y ago
      I feel like a designer would have the opposite sentiment.
    • rawTruthHurts 11y ago
      *Take with a pinch of salt
    • baweaver 11y ago
      Careful on that line as some of us become programmers and are quite apt at playing both roles when needed. In reality separation of concerns is a luxury only afforded to larger teams and orgs. If you have the people, do it. If you don't, you're in for a bad time concerning yourself with it. Granted the html in Java is just straight idiocy, and my point refers to far less insidious mixings.
      • bryanrasmussen 11y ago
        separation of concerns in your organization is a luxury. separation of concerns in your codebase is a necessity.
• yAnonymous 11y ago
  >Designers suck at code. Coders suck at design. Keep that shit separate. As a developer, it's pretty easy to pick up design basics when you've been coding frontends for a few years. On the other hand, I regularly see professional designers come up with... very impractical ideas, to put it nicely. Anyway, your statement is not necessarily always true.
• tom-lord 11y ago
  > Designers suck at code. Coders suck at design. Keep that shit separate. I currently work in a small-ish company, where I am the ONLY person designing/developing multiple systems. (I do get some input now and then, but it's mostly all down to me.) I like this idea in principle, but you don't always have the resources to achieve this!
  • deleted 11y ago
    [deleted]
• mattlutze 11y ago
  A big benefit of an existing MVC framework, if you following 1 and 2 above, is that when you need to bring new people onto a project (or move between parts of a large project) the quirks, usage paradigms and whatnot are all known quantities with expert advice written by a community, all free at your disposal. Home-baked MVC implementations can be simpler and more direct, but often suffer from a much taller learning curve.
  • marrs 11y ago
    I guess this works well for body shops (though I'm not sure that body shops work well for anyone), but I've never seen this theory play out well in practice. Often I find it the other way round. You hire an Angular expert and, if he's junior, you spend the next 3 months unteaching him all the bad habits he's learnt, or, if he's a senior, spend the next 3 months arguing with him about who knows Angular better, all the while kissing goodbye to any maintainability your code base once had. If you have simple, well factored code, a good coder can learn it quickly. In fact, juniors often get it faster because they don't have to map their limited understanding of "patterns" to the documentation on the website or the behaviour they see on the ground. What gets me about all this is that web app development is just about the simplest programming you can do. It always staggers me the lengths otherwise intelligent developers (sorry, "software engineers") go to make their architectures as complicated as possible. I sometimes think it's because they're intelligent that they do this, perhaps out of fear of not being challenged?
    • koide 11y ago
      As an aside, if you're spending three months arguing about who knows something better instead of putting the ideas under discussion on practice to see which one works better, you're either doing your hiring wrong or your team dynamics suck (or both)
• userbinator 11y ago
  You're right about the complexity, but I never did get the whole "separation of concerns" thing with respect to web applications. Perhaps it makes sense for large applications, but in my experience with smaller, simpler ones, it just means making more little pieces that have to work together correctly for everything to work, and one small change means having to go through several files and make tiny edits in a bunch of places instead of having it all together. IMHO you're separating something that just isn't very suitable to separation. Generating HTML directly in the code makes it very easy to figure out how everything works, and thus modify it, since you see the whole process in one place. Speaking as someone who recently turned a ~5kLoC, ostensibly MVC and consisting of over a dozen files (mostly empty or nearly so), but quite trivial application into a single file of less than 100 lines, it's amazing how much complexity some people can introduce.
  • sreyaNotfilc 11y ago
    The problem lies when your application grows. Remember that one of the "rules" in computer science is modularity. Here's a couple of examples --------------------------------- For example, lets say you have a data set that returned user information. Combining it directly with the html may be easier. The issue happens when you want to use that same data (or portions of a that data) elsewhere. From there you would have to rewrite the query. Having the data-set separated (either in a class or a function that returns raw data, then having that data parsed and placed within html works much better. There you don't have to rewrite anything (and have the satisfaction that the data "works"). On the other side, separating the html will be helpful as well. Say that the interface has now changed. You are not going to remove a column in a table and reorganize other components. Instead of having to look through the code where you may have placed the html with the data, all you need to do is to make your changes accordingly in your presentation layer. All in all, it may seem like a lot more work to get things started (I don't use MVC in the traditional sense, and instead have my own programming rig). The reward lies when you can separate duties among team members. Someone can work on the presentation (and the browser compatibility issues that it includes) while another one can work on the business logic. So on and so forth.
    • 11y ago
• merb 11y ago
  you thinking too easy, as a project grows you actually need to run seperate and now you have a problem, either you group per component (something like addresshandler) so that you have component/Controller component/Model component/View Or you group by enity, something like customer_management, where you put all your customer related controllers: customer_management/View1 customer_management/View2 customer_management/View3 customer_management/Controller1 customer_management/Controller2 customer_management/Controller3 now you introduce subfolders: customer_management/Controller/Controller1 customer_management/Controller/Controller2 customer_management/Controller/Controller3 customer_management/Model/Model1 customer_management/Model/Model2 customer_management/Model/Model3 Both have their ups and downs and still are related to MVC. However you've still outgrown MVC a little bit since now your so big that actually some things doesn't make sense, so you add a datalayer on top of your models or a service layer, etc. things get really messy now, when you don't change. That's why programming is hard. Correctly or logical separation of code changes as your application evolves but people don't change it so they blame the separation concept.
• collyw 11y ago
  Often it makes sense to have the code and the data together. I am thinking about OOP, where your classes define the data and the methods that act upon. Having inherited a new project recently I was disappointed to see the documentation talking about following the philosophy of thin models and fat controllers (the opposite of what is considered best practices for Django, which the project is using). It means that there isn't one obvious place to look for the expected functionality,there is unnecessary repetition of code and its way less efficient than it could be if it was done the other way - models with data definitions and related methods in the same place. I am all for separation of concerns, but I don't think splitting along the lines of "data" and "code" is the best way to achieve that.
• memracom 11y ago
  You say HTML is data? That's funny, I always thought it was code.