Hacker News Reader

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?

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.

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?

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.

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?

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)

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.

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.

So refactor the code when you find yourself needing that separation. You'll find yourself with a much more understandable code base.

You can still have the separation of duties that you describe because, in the case of web app dev, HTML and CSS are already separate languages

> 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!

> 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.

Designers coding is fine. Designers programming is not.

I feel like a designer would have the opposite sentiment.

*Take with a pinch of salt

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.

separation of concerns in your organization is a luxury.

separation of concerns in your codebase is a necessity.

I was about to write the same thing, so true. Even if you are working alone at the moment, doesn't mean that you should glue everything together and end up with spaghetti code.

I was more of referring to the level of separation.

I think I was pretty plain. Designers suck at code. Coders suck at design.

That use case is the "we should only have to pay one guy and he should know everything" use case. Or the "I have an idea for an app. I'm a company now." use case.

Know why so many bootstrap sites look pretty much exactly the same?

--- If someone wants to change the color of the header on a website, should it require a code change?

If there's a table that someone wants to change the border on, should that require a person who knows three languages? Or should that require a guy who read an html book last week?

Conversely, what if there's a bug report about an element that is not displaying on a Nook Color? Should that require a developer to look at? Or wouldn't his time be better used working on an actual programming problem?

--- I interviewed a developer recently and asked him about a particularly difficult challenge that he worked his way through. Usually people respond with a problem that manifested itself in multiple ways or tracking down an important bug in a widely used library. This particular answer was about an errant price change on a major retail web site that took 6 days to implement. A price change should be a zero down time absolutely no-brainer data change. But some idiot along the way decided that he should embed html AND javascript in his java class and it took a team of people several days to track down where exactly the error was that produced the errant price. There's stupid code like that all over the place.

With experience, you learn that you can avoid those kinds of problems completely with very little overhead early on.

But some idiot along the way decided that he should embed html AND javascript in his java class and it took a team of people several days to track down where exactly the error was that produced the errant price.

A team of people, several days, and no one thought to just grep the codebase to find the relevant pieces? If that "idiot" didn't conveniently put the pieces all in one place, maybe it would've taken even longer to find? I wouldn't blame that on being "stupid code"...

I had a little trouble with this one myself. Apparently there was a lot of '<' + elementType + '>' + value + doClosingTag(); kind of junk all over the place. Add to the mix javascript that called a web service and got pricing and another piece of javascript that called a different web service that adjusted pricing based on sales.

I'm not going to defend this practice or design. I would never have let something like that get anywhere near production myself.

You see a lot of people in this thread who don't feel that separation of code and display information is important. Imagine how that looks in an agile environment where nobody steps back to look at the big picture and developer turnover is high - like maybe a model that included churning offshore resources in and out as requirements demanded it. It's bad.

I've seen this kind of thing in action. One particular case that sticks out in my memory involved function calls that didn't actually exist but were caught by magic methods and created on the fly. That one took me and another dev a few days to track down. If you find it hard to believe, you're either lucky or are severely underestimating the power of stupid.

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.

You say HTML is data? That's funny, I always thought it was code.

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.

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.

> Not segmenting your code is stupid. Plain and simple.

And overly broad, generalizing statements are not?

Remember to be respectful towards your peers.

That was not a comment directed at jacobr. It was a statement about code.

There's stupid code all over the place. Twenty years ago, you had to know networking, hardware, relational databases, and programming to get anything done. Nobody did QA testing, AB testing, or even had a development environment seperate from production.

We're slowly growing up and realizing our mistakes. If we can't call our own code stupid, then we've achieved a level in our political correctness culture that ... well, that's just plain impressive.

If anyone felt personally attacked, I certainly did not mean for it to come across that way. I am in a bit of a mood tonight...

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.

Sorry, but you just don't get the fact that SAM is reactive/functional and what benefits you can drive from it.

I am certainly reactive, but also functional - so thanks for that.

It took me 2 hours to realize how funny this comment was.

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.

Can you please re-read the paper, the whole point of the pattern like Cycle.js is to separate logic from effects. Logic != Code

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.

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.

>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.