Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years trying to make everyone separate HTML, JavaScript, CSS – and then

twitter.com

Post reply on HN
Print view View original

121–130 of 177 posts

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#121

Post by Nullabillity »

TeMPOraL wrote: post #115
pasta wrote: post #114

Earlier quoted context omitted.

And after you replicated PHP you come to the conclusion the templating language is as slow as hell. So you think: maybe we would need a compiler so we can cache the templates. The question ofcourse is: why would people rather use: {for item in list} {item.name} {end for} instead of: ' . $item['name'] . ' '; } ?> And I think this goes deep. People are looking for more human ways to express themselves. And PHP is not a…

Note than in PHP you can also rewrite it as: Or with shortened PHP tags and alternative control structure syntax: Which at this point just differs in delimiters ( instead of { and }) from the template language. I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.

And then, to avoid XSS, you'd need to replace that by:
Which is, IMO, the main problem with using PHP (or any other from of plain string concatenation) as a templating language. Escaping everything (and security in general) should be the default, not something that you have to opt into at every turn.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#123

Post by TeMPOraL »

Nullabillity wrote: post #121
TeMPOraL wrote: post #115

Earlier quoted context omitted.

Note than in PHP you can also rewrite it as: Or with shortened PHP tags and alternative control structure syntax: Which at this point just differs in delimiters ( instead of { and }) from the template language. I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.

And then, to avoid XSS, you'd need to replace that by: Which is, IMO, the main problem with using PHP (or any other from of plain string concatenation) as a templating language. Escaping everything (and security in general) should be the default, not something that you have to opt into at every turn.

True, though as you note, this is essentially true of any form of plain string concatenation. Dedicated templating languages tend to fail at this too.

Escaping-as-default helps, but people sometimes forget escaping is a function of output context. For example,

  
    frobnicate("{bar}");
is a potential vulnerability if the default escaping mechanism for {bar} is one meant for HTML.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#124

Post by sametmax »

We are still separating HTML/JS/CSS.

React widget logic is on their own methods, PUB/SUB logic is in flux. Template logic is in one isolated method in JSX. CSS is not in there.

Yes, the widget logic and template are in the same files, but the code is strongly separated.

React encourage to group related CSS/JS/HTML together, to make a stand alone component. Yet CSS/JS/HTML are distinct in the component. I think it's a nice solution.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#125

Post by tannhaeuser »

tracker1 wrote: post #65
kul_ wrote: post #11

Earlier quoted context omitted.

Agreed. Take the example of people hating XML and trying to reinvent everything good XML already had with JSON and JSON Schema. http://json-schema.org/

My biggest peeve with XML is there's no concrete way to represent a piece of XML in code, it's in my opinion TOO flexible. You can express something as an attribute, a child, multiple children of the same element, a value of a child, etc. It doesn't translate cleanly to any kind of object structure in terms of code. And it goes in reverse too. Now, there are standards like SOAP, etc... In the end, JSON and some clear…

That's because originally SGML/HTML/XML attributes were for (mostly) presentational details, but this role was shifted to CSS. The resulting combination does indeed look arbitrary, especially with CSS's total lack of mental discipline (but let's not be too harsh here).

In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata. In a context where this distinction doesn't make sense, markup (SGML, XML, HTML) probably doesn't make sense either.

Markup isn't and never was intended for representing arbitrary data - it is for representing text with optional markup, and is designed for end-users and content authors, not necessarily web developers.

As for representing XML in code, there was E4X which allowed you to represent XML literals in Javascript (Firefox and rhino had it a couple years ago, but it kindof wasn't convincing). Keep in mind that Javascript was invented as a language to manipulate a DOM in the first place, so there you have your canonical representation of markup in Javascript.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#126

Post by douche »

TeMPOraL wrote: post #103
waffleau wrote: post #52

This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong . Separation of concerns refers to responsibilities, not languages. If you're building a static website, sure, you probably don't need R…

> Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong. Well, we had - the whole "separate content from presentation" thing was a cargo cult. Before the recent wave of JS frameworks, the standard website was littered with tons of div elements, almost all of which had zero semantic meaning, and existed only as CSS hooks and/or a hipster replacement for tables. And it w…

I always thought it was a little silly to religiously persecute script-tags at the bottom of an html page for single-use event hooks and listeners and initialization logic. Instead I was told best practices were to split that one-off code out into another file, bundle it up with a bunch of other unrelated garbage, minify it, and link the whole kit and kaboodle in.

Meanwhile, when you need to go edit the logic operating on some element later, you end up grepping through your code base for ids, classnames, element types, whatever, trying to figure out where that bit of code that operates on that element got to, often several directories in the file structure away from the markup.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#127

Post by Sacho »

pas wrote: post #98
jcoffland wrote: post #96

React is popular because of Facebook just like Angular was popular because of Google. Both are bad ideas. Why programmers insist on running off a cliff every few years like a bunch of lemmings, I don't know.

Why do you think they are bad ideas?

I've articulated some of the "bad ideas" that Angular 1 had before - https://news.ycombinator.com/item?id=11846843 but I'm curious to hear which ideas are similarly bad in React.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#128

Post by Robin_Message »

Chris_Newton wrote: post #51
Robin_Message wrote: post #50

Earlier quoted context omitted.

Look again; it doesn't mix presentation and (business) logic. It's all view, with the added bonus of not needing to code state transitions in the view.

Look again; it doesn't mix presentation and (business) logic. Unfortunately, the example from the tweet really does: the storage and manipulation of the to-do list itself is right there, mixed in with the rendering component. I think it’s a bad example of how to write UI code using React, because while it’s concise and it works, the techniques it shows lack flexibility and don’t scale well, and they’re not how you’d…

True; I was only looking at the render method, which I think is pretty pure, and should indeed be more separated from the business logic.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#129

Post by tannhaeuser »

dclowd9901 wrote: post #6

What this image doesn't show: Refactor safety. When I can include my CSS as modules into my components (which, by the way, is still separated, only now it's completely isolated from demonic CSS side-effects), and when I can TEST my HTML (read that again: TEST my HTML, again, easily separatable meaningfully by utilizing a pure-function mechanism), and when I can use something like Flowtype to identify structures in my…

You're accusing TBL for "demonic" CSS (seriously?) which he didn't invent? You should ask yourself why you're attempting to use a document delivery platform into an app delivery platform for shitty apps that nobody wants anyway.

Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then

#130

Post by mcbits »

Already__Taken wrote: post #82
ClayFerguson wrote: post #17

In my 15 years I've come to realize that HTML code-generation via JavaScript (or now TypeScript actually) is vastly superior to any type of templating (like JSP, JSF, Velocity, Mustache). Both ways (templating v.s. straight generation) have exactly one sort of 'level of indirection' so they are on the same order of complexity, but generating HTML rather than templating it is a billion times more powerful, so it is ju…

What is 'build = (): string => {' ? Or specifically ():, I know arrow functions.

It's similar to writing

    build(): string { ...
but they generate different JavaScript. The way it's written will give each instance its own reference to the function. The "build(): string" above will add the function to the prototype, which is shared by all instances.

I'm not sure whether the code takes advantage of this difference in some way or not. If not, it's just a slightly more awkward and less efficient way of defining a method.

Post reply on HN