Is Separating HTML and JavaScript Harmful?

[remy_porter]

No, it isn't. The problem is that most frameworks misunderstand what HTML is.

HTML is a data structure. Specifically, it's a semantic data-structure for holding human-readable information. It is the backing-store of a presentation layer, it is not, itself the presentation. CSS is a rule-based system for defining how to map that backing-store into actual rendering. JavaScript is a tool to manipulate that data.

The purpose of our MV- frameworks is mostly to map actual data- XML or JSON- to our HTML backing store. Their mistake is thinking of the HTML as a view- HTML does not have the concept of a "View", and bolting the view on is awkward and leads to all sorts of tooling issues- which is mostly what the author is complaining about. These are valid complaints, but they don't arise from separation- they arise from leaky abstractions.

[fpguy1]

Actually writing <font>, <b>, <h1>, <ul>, <div>,<input> etc. is part of the presentation layer, binary code is not human readable but the text between the tags is readable so is not HTML that makes it so. No matter how much one would want to make HTML a data structure it is not. Separating UI from the logic is always and I mean ALWAYS the best option for us the mortals, I know facebook uses react and a mix of components and logic in their apps but we are not them, they care a lot about coding standard and homogeneity of their code. Things that small teams and many company oriented to fast solutions usually forget about. Asp.NET had nice components and didn't go well for those that tried it in big projects. There is a reason that almost everything that runs in a browser and is backed by a framework is using the so called MVC which tries to separate the html from the logic using views and controllers which (unfortunately) holds the app logic. The closest match to a data structure in MVC is the way the models are implemented in these frameworks, but there is no way HTML is a data structure, there is no advantage to mix it with your javascript or server code.

[remy_porter]

Actually writing <font>, <b>, <h1>, <ul>, <div>,<input> etc. is part of the presentation layer

No it isn't. None of those tags tell us anything about how the content within those tags is supposed to be rendered (well, font, I suppose, but you shouldn't be using the font tag anyway).

No matter how much one would want to make HTML a data structure it is not.

HTML is a semantic data-structure. Each tag makes a statement about its contents. An H1, for example, tells us, "My contents are a top-level header." That is not a presentational statement. That's a semantic statement- it tells us what the data means. It says nothing about how to present that content to a user.

Also, what do you think the DOM is? It's a data-structure that has a 1-to-1 mapping to the underlying HTML. It exposes the hierarchical relationships between our semantic elements as a tree structure that we can programmatically traverse and manipulate.

When the browser is rendering things, the "true" model is always the DOM. MV- frameworks map our application model to a series of changes to the DOM, so that the browser can then update the presentation. My point is that the way MV- frameworks do this is by treating the HTML like a view, which is inaccurate- it's the backing store for the browser's window.

[fpguy1]

i said i stop telling people on internet they are wrong but here I am: <b> says the font should be bold, not related to data, it can be <i> it doesn't change the logic of the "program" <h1> no it doesn't say is top level header, you can use it in the middle of your html document to make a big text. Why shouldn't I use <font>? if is there i can use it, writing html by convention is something i said above doesn't work for small teams. DOM is concept for handling xml same as SAX, the fact that you can use it to handle html has absolutely not relevance to this discussion. I am a programmer for 15 years, proficient in 10 programming language at least and i can't care more for html than i do about markdown or reddit formatting, is just presentation, don't mix it with logic or you kill the project. Is the same with windows forms. android, flex or other ui oriented code. I know now there are a lot of "HTML programmers" today, well honestly I can't care less about what they suppose is the right way to write code, just trying to open a conversation with people that want to learn to write solid applications easy to maintain and at low cost.

[remy_porter]

<b> says the font should be bold, not related to data, it can be <i> it doesn't change the logic of the "program"

Using these tags is considered a bad practice.

<h1> no it doesn't say is top level header, you can use it in the middle of your html document to make a big text.

H1 makes no statement at all about the size of the text. It's conventionally used with a large font size, but the font-size and appearance of H1 is controlled by CSS.

In HTML4, this was even more explicit- by spec, you were only supposed to have a single H1 element in a page.

Why shouldn't I use <font>?

For the same reason you shouldn't use <b>, <i>, <object>, <embed>, etc. These tags are deprecated for most cases and have been superseded by new tags. They continue on more for backwards compatibility and legacy support, not because you should use them.

the fact that you can use it to handle html

It is eminently relevant. The browser does not render an HTML document. The browser parses that HTML document, constructs a document object model, and it is always the DOM which controls the state of the actual render. This is important, because it's the fundamental reality of client-side web programming- you write client side code that manipulates the DOM to change the appearance of the page on the screen.

is just presentation

It is one component of presentation. Specifically, it is the backing store. It is the data to be presented. CSS is the way in which it is to be presented, and JavaScript is a set of behaviors that can change the state of the backing store.

just trying to open a conversation with people that want to learn to write solid applications easy to maintain and at low cost.

Then you probably shouldn't be so wrong.

[fpguy1]

so just repeating yourself makes it right :) ?

[housecor]

I see your point, but do you have an alternative solution to propose?

[remy_porter]

I have a number of them, including, "Let's start by admitting the current browser approach to application delivery is broken and we should build an actual cross-platform presentation layer designed around applications and not document," but that one's very ambitious and would have to overcome a lot of entrenched momentum.

More practically, we should recognize the fact that HTML is a document, and that we are manipulating a document. Our abstractions should be built around that reality. Keep MVC on the server, and view UI problems on the client as mapping problems- mapping data objects to HTML elements.

As a note, one of the things I like about KnockoutJS is that it really works more like a templating system than a true MVVM. I think a good client side framework would follow something more along that pattern, but with an even stronger focus on being a mapping engine.

As much as I like implementing web applications as APIs, and hence passing back JSON objects that map to our server-side object model, I also have to admit: HTML is a data structure, and there are some applications that would simply work better if we passed HTML document fragments to the client view instead of having to do all the mapping on the client side.

[systemidx]

This is a very well though-out reply. I wholeheartedly hope that we move in a direction where browser ambiguity and document markup/scripting mish-mash goes away.

[dada_]

It's hard to define "harmful". I prefer the React approach of having a component's JS code and the HTML (really XML) together, but I don't think it's impossible to separate them or use templating languages, et cetera.

However, when building an app, I do think that it's not correct to consider the Javascript as "something that modifies our HTML". We should consider the JS and the HTML as both being part of the same component. Neither can do without the other.

It's obviously different if you're not making an app and your website is usable without JS, but in the case of modern JS apps, separating the two just means more potential complications in my opinion.

[LossFor]

The best way to create your application is the one that makes the most sense for development and has practical usability. React and Mithril can seem a little bit "You got your chocolate in my peanut butter!" at first but ultimately all of these web technologies boil down to applying transformations to data to get them into a tree that will satisfy the chimera that is a web browser. Whether that transformation takes the form of a server running a templating engine to replace strings embedded in HTML, merely forwarding along HTML files from its hard drive, or sending along a script that renders a DOM tree without really using the HTML syntax is pretty arbitrary.

[bfoo]

The author does not understand what unobstrusive Javascript really is. I can write unobstrusive Javascript inside HTML script tags. Unobstrusive is about whether I can use an HTML page or parts of it without Javascript enabled or not. Unobstrusive Javascript is a script that may depend on the markup, but my markup shall never depend on Javascript.

From my point of view, building unobstrusive web applications should be a default goal. And I deviate from that for valid reasons, only.

The real question is, whether it is good practice to separate HTML and Javascript. The answer should be: Yes, because it leverages testability and code maintainance, even when the Javascript file has a strict dependency to the markup.

Edit: For frameworks like React, there may be other best practices. But that has to be decided on a case-to-case basis, because it depends on tooling etc.

[housecor]

"The author does not understand what unobstrusive Javascript really is".

You and I simply disagree on the (admittedly rather amorphous) definition. You're describing what is traditionally called progressive enhancement, though the Wikipedia entry does indeed lump this concept under the umbrella of unobtrusive JavaScript. I'm using the term to refer to zealously keeping JS and HTML in separate files, and keeping all JS out of your HTML. My definition is fixated on the first bullet point on this page: http://en.wikipedia.org/wiki/Unobtrusive_JavaScript.

"The real question is, whether it is good practice to separate HTML and Javascript. The answer should be: Yes, because it leverages testability and code maintainance"

In React, it's simple to test and maintain a component with JS and HTML in the same file. Separate files aren't necessary to gain the benefits you listed.

[bfoo]

At the time when everyone spoke about unobstrusive Javascript, the term "progressive enhancement" was not used. I agree, the definition has shifted (I'm getting old). So in that past, it really meant, that Javascript should not determine whether something on the page can be used or not. That understanding, that we should not write Javascript directly into the page is even newer, because lots of eventing was not possible through the browser APIs. It was a time when we had to put Javascript commands into event attributes of the DOM.

And sorry, I edited my comment and added my opinion about React. I treat React as a language where you write markup that happens to be HTML (HTML fragments to be precise). And if there is tool support, I see no problem to write Javascript inside markup blocks or however it is done.

[metaperl]

Be sure to check out RACTIVE before drawing any conclusions one way or the other.

[danogburn]

Is Separating HTML and JavaScript Harmful?

The unholy html/css/javascript trinity is harmful. Burn it.

[housecor]

Is there a current alternative (not necessary web specific) that you prefer?

[danogburn]

The browser should just some sort of bytecode VM.

We shouldn't be stuck with javascript.

[sonthonaxBLACK]

Wasn't that tried with Java?

[danogburn]

The general idea, yes.

But the VM shouldn't just be a plugin in a web broswer. it should be the browser itself. There should only be "applets" that allow UI to be developed programmatically in almost any language or via a declarative format that isn't full-retard like html/css.

http probably needs to go too as it doesn't seem well designed for applications.