Live data from Hacker News

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

twitter.com

111–120 of 177 posts

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

#111
post #99

Earlier quoted context omitted.

how thoroughly it's been trashed over the years So often a phrase like this is repeated on HN. React only got released 3 years ago . How could it be "trashed over the years"? Over what years? It barely qualifies for the plural. I seriously wonder sometimes if javascript programmers live in dog years. React apps haven't been in production long, we're only just entering the maintenance phase, now is exactly when we wil…

How many years do you need to come up with a counter-argument, or adress the issues claimed for the alternatives (by the React authors and community)? Three years might not be old for a technology, but it seems like a lot of time to actually respond and flesh out this argument. If that really was the author's interest.

Not really, it took almost a decade for people to believe that splitting up PHP or ASP pages into modules and UI was easier to maintain.

HTML + CSS started in the 90s but it wasn't until the late 00s until strict CSS/HTML separation was regularly practiced.

It takes proper experience and years of work to understand why these splits are useful. And React was literally released 3 years, 2 months ago. We're not even taking into account adoption time or anything.

How quickly we forget the past I guess.

Unless we're talking in javascript years again...

EDIT: I actually forget my perspective at times. I have 10+ years experience, I saw all this for real, I worked with HTML with inline style="" tags + style tags in pages + with old-school ASP of pages with loads of inline code (yes, not ASP.Net, ASP) + PHP + VBScript + IE6 + on-element javascript + all the craziness.

It was a nightmare to find out what did what. Everything turned confusing very quickly. You never knew quite what did what.

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

#112
haha, I read this too.

And I thought so too.

I'm using React for 1 1/2 years now and I have to admit it has its pitfalls but co-locating templates and code really made things easier.

The only problems I had was when I tried to push props too far down (== not co-locating) because then my components relied on each other too much.

But most of the time the top of the file is controller code and the bottom (render method) is view code.

Often I just use props for IDs or push "full data" into tightly coupled components (list items in a list etc.)

If a component is responsible for all its data, it can be moved around freely, which often saved me many hours.

I think React has its problems, but THIS is none of them.

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

#113
post #4
post #2

It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.

This was exactly my thought, and it's not like I'm even that old. We should know better by now. I went from writing PHP in high school that looked exactly like this, to using Python CGI and then finally Flask to write (I think) very modular, maintainable web applications. Now several years later I'm inheriting Nodejs and [flavor of the month] Javascript framework projects from coworkers that look like the PHP video s…

> I feel like I have (or everyone else has) contracted some sort of amnesia. Didn't we already hash this out guys?

Maybe we're backtracking on the idiocy we started on around PHP times? The whole "separation of concerns" thing that went to such extremes as to become a cargo cult? I offer two observations:

- presentation is often very much content at the same time (that's why websites end up cluttered with divs that have no semantic meaning and serve no other purpose than being CSS hooks)

- separation of concerns was about not putting business code in views, not about having views without any code; you need code to drive views (and yes, template languages are Turing-complete, so they count as code too)

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

#114
post #70

Earlier quoted context omitted.

> 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. We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with…

This. I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" t…

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 very beautiful language. So maybe my first example looks more 'human' than the PHP example.

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

#115
post #114

Earlier quoted context omitted.

This. I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" t…

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.

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

#116
post #70

Earlier quoted context omitted.

> 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. We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with…

I've worked some with both WinForms and WPF, and so far I kinda like XAML. And is you're not only working in the windows world, I hear there's a similar-in-spirit JavaScript/HTML framework being used for "new hotness" style applications. Called "electron" or something like that I think?

In short, Electron is a tool for running Node scripts in a real DOM in Chromium (so unlike PhantomJS, it can run things like WebGL).

You can also bundle it to generate distributable desktop applications (e.g. Visual Studio Code, Atom, or the desktop Slack client).

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

#117

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…

Or just use Polymer and forget about React.

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

#118

I kind of want to show him this code to upset him more. I think React is great, especially when using it through ClojureScript. (defn todo-list [] (let [todos (atom []) text (atom "") add-todo #(do (swap! todos conj @text) (reset! text ""))] (fn [] [:form {:on-submit add-todo :action "javascript:"} [:input {:type "text" :value @text :on-change #(reset! text (.-target.value %))}] [:button {:type "submit"} "Add"] [:ul…

It's great that you don't need Clojurescript or even JSX to do that. You can write plain ES5 and get the same result. And it would stay readable for most.

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

#119
post #76

The thing about Fuchs is that he's a very smart guy, who is deeply embedded in the modern JS world, and is absolutely aware of what that code is doing, why it looks the way it does, why the trend in frameworks has moved the way it has, just how many times the argument he's using has been advanced already, and how thoroughly it's been trashed over the years. He knows that what he's said has been said a thousand times…

how thoroughly it's been trashed over the years So often a phrase like this is repeated on HN. React only got released 3 years ago . How could it be "trashed over the years"? Over what years? It barely qualifies for the plural. I seriously wonder sometimes if javascript programmers live in dog years. React apps haven't been in production long, we're only just entering the maintenance phase, now is exactly when we wil…

> React only got released 3 years ago. How could it be "trashed over the years"? Over what years? It barely qualifies for the plural.

Yes. Three years. Plural. This has been debated for three years; that's why I said "years". Are you suggesting I should have said some other time period?

> we're only just entering the maintenance phase

Yes, I am maintaining some React code; some of it has been in maintenance mode for almost two years now. I also maintain some Backbone code, some jQuery spaghetti, a couple of Knockout projects, and an enormous MVC-ish PHP app; I've got a pretty good grip on the various ways people have written web apps over the last few years and what maintaining them is like.

> now is exactly when we will start seeing the problems with mingling code + UI

No, because there are no problems with mingling "code" and "UI" so long as all of it is presentational. What's critical is ensuring separation of concerns, which you fail to do when you mix business logic with the presentational logic.

Saying "it's all javascript so it must be related!" is how you end up with unmaintainable Backbone code. (And to be fair, you can do that with React too, but that's got nothing to do with what the screenshot was decrying. And it's actually harder to screw it up with React than Backbone, in my experience, and I have experienced both.)

Keep in mind: Many of the people who disagree with you have many, many years of experience and a deep understanding of software engineering principles and what does and does not lead to maintainable code. That doesn't mean React/JSX is perfect, but it does mean that you aren't going to get very far with snide comments. The obvious criticism of JSX is that separation of concerns is important, and the obvious defense is that JSX enables very effective separation of concerns. And that criticism and defense were first made, yes, years ago. Any further progress needs new arguments.

Ninja edit: And yes, I too have written original ASP code, and worked on "DHTML" sites, and wrote hideous inline JS to try and make rollovers work in IE6, and tried to reverse engineer the broken JS that MS Frontpage automatically injected into the pages it creates, and a bunch more besides. I too know the urge to yell at people to get off my lawn. Just because it's new doesn't mean it's always wrong though...

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

#120
post #99

Earlier quoted context omitted.

How many years do you need to come up with a counter-argument, or adress the issues claimed for the alternatives (by the React authors and community)? Three years might not be old for a technology, but it seems like a lot of time to actually respond and flesh out this argument. If that really was the author's interest.

Not really, it took almost a decade for people to believe that splitting up PHP or ASP pages into modules and UI was easier to maintain. HTML + CSS started in the 90s but it wasn't until the late 00s until strict CSS/HTML separation was regularly practiced. It takes proper experience and years of work to understand why these splits are useful. And React was literally released 3 years, 2 months ago. We're not even tak…

I don't disagree with the statement about the importance of experience.

But I don't see that that point is relevant here. Here is someone who claims to have gained that experience and learned from it, and now at least gives the impression of aiming to share that knowledge. But that's not what he's doing. He's completely ignoring the fact that there have been many, many responses to the issue he's raising, and maybe he has some good refutation of those responses based on his experience and wisdom, but in that case he does not share it. It just comes off as arrogant and polemic in my opinion.

So, yes, experience takes time and is perhaps sometimes the best possible way to learn. But given that you claim to have that experience and therefore some wisdom that is relevant, then it shouldn't take three years to state that. If that is your goal.

And if it is literally impossible to formulate the experience and wisdom that you do have into something that can be communicated and taught, yes, then of course every future generation is bound to repeat the same mistakes. How could they not?

Post reply on HN