Jan Vladimir Mostert

Idea Incubator

Jan 14, 2016

Just as inline styling and inline JS is bad practice, so is is inlining HTML in your JS. Same goes for mixing HTML inside you PHP or for mixing Java code inside your JSP tags via scriptlets.

If you look at why MVC was created in the first place, it was created to seperate view logic from business logic from data logic, same goes for MVP or MVVP or whatever they're called these days.

The general design principal is called Seperation of Concerns

The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

HTML, CSS and JavaScript specific:

HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript (JS) are complementary languages used in the development of webpages and websites. HTML is mainly used for organization of webpage content, CSS is used for definition of content presentation style, and JS defines how the content interacts and behaves with the user. Historically, this was not the case: prior to the introduction of CSS, HTML performed both duties of defining semantics and style.

Michael Brown

Jan 18, 2016

Except MVC, as you've described it, doesn't actually separate concerns. It's actually just a separation of technologies. Google for Pete Hunt's talk on this subject.

Eg. try updating your view template to display a new data attribute in your UI. If you're lucky, nothing will display. If you're not lucky, your application will crash. Why? Because that attribute doesn't exist in your model yet! A lot of the time, when you update one, then you must make a corresponding change in the other if you want anything meaningful to happen.

Separation of concerns? More like joined at the hip!

Let's define MVC as Model (the abstraction over your database layer), Controller (the abstraction over you business logic) and the View (View includes your HTML, CSS and JS and if you're using server-side rendering, that also includes your JSP/ASP files if you're using JSP/ASP)

Using your argument that these things are "joined by the hip", you can also say that each layer in MVC is joined by the hip, change the model layer and you potentially break the controller layer, change the controller layer and you potentially break the view layer, but the argument still holds, it's much easier to maintain than having it all smooshed into one layer.

Regarding Pete Hunt, he refers to components inside the View layer where the HTML, CSS and JS are very tightly coupled (outside of components, the above still holds very strong). If you look at Polymer, WebComponents, Angular - even though these are very tightly coupled bits of code, they are either in separate files or when they are all included in one file, CSS, JavaScript and HTML are clearly separated into their own blocks.

The concerns remain JavaScript for View Logic / Behavior, CSS for View Layout / Design and HTML for View Content / Structure

By separating the concerns, which just happens to be different technologies as well, you make it much easier to maintain your project. If I want to change the design of a component, I go to the CSS and change it there, want to change the layout, go to the html, want to change the behaviour, go to JS. Want to port a component to Dart or TypeScript, simply replace the JS with TypeScript / Dart and leave the other two layers as is, if I want my designer to restyle my app, all he has to do is work on the HTML and CSS and forget about the JS (obviously reminding him that he needs to put the bindings back if he's removing any of them).

I've seen enough projects became unmaintainable messes when smart engineers decided to merge certain layers for performance reasons or whatever reasons they had - so not in my code-base or any projects I manage, but to each its own.

CSS within React components is not something that I'm doing in my projects. React certainly lets you go that way, but it doesn't mandate it. If you're happy to load your CSS with good old link tag, like me, then you'll be fine.

Explain why having to look in two files (JS file and template file) it's easier to follow the logic of your app than if you only have to look in one. Even if you have two monitors it's a pain. (I have two monitors, incidentally: one has my editor, Sublime Text, and the other has my browser. Maybe I need three monitors to do things your way!)

I can move React components from project to project easily. As long as I have documented what the props are, and what the event callbacks are, if any. I don't have to pick up a bit of JavaScript and a bit of templating language and sort out where then need to go in my destination project, and how they work together.

And did I mention that templating languages just suck? They bring their own language elements that are non-standard and a pain to work with. If a designer can work with Angular's multitude of ngWhatevers, I think they ought to be able to work with JSX, which looks just like HTML.

Search Hashnode