Live data from Hacker News

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

twitter.com

141–150 of 177 posts

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

#141
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…

>No attempt at dialogue

To be fair, there has never been any effective dialogue on Twitter. 140 characters and out-of-context replies make it impossible.

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

#142

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…

We could extrapolate this trajectory and take a page out of lisp history. Why don't we just let a "web page" be an s-expression delivered by http and run within a sandbox?

If you look at what the racket team has done for their documentation system "scribble", it is pretty clear that we can engineer whatever modularity we require for the purpose at hand given that generality.

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

#144
post #108

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…

This "most effective tool" looks like a fancy way of concatenating HTML strings in JS. :) Hardly something that can be described as quality software engineering.

That's just silly. Ultimately every tool outputs a 'string' that gets sent to the browser.

What matters is how this happens, and there's a huge difference between React's approach and ''

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

#145

Reading the comments I'm wondering if I'm the only one who noticed that this example does NOT intermingle CSS. This is a view component that keeps track of it's own state. It is 100% encapsulated and by building in events and data bindings it can be composed into more complicated applications. It is in fact separation of concerns. This is only one concern. The UI of a single component. In a full React app the busines…

Tbh how is the one concern not the Fact they use 'let'. Gross. Fun fact: types, line numbers, and BS keywords like 'let' 'var' and * *&uint32, are only constructs of the language authors mind... a visualization of how he thinks. And are completely optional to a language (given a slightly more flexible parsercompiler)

You are saying that in JavaScript var is made up and not to use it..?

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

#146

Reading the comments I'm wondering if I'm the only one who noticed that this example does NOT intermingle CSS. This is a view component that keeps track of it's own state. It is 100% encapsulated and by building in events and data bindings it can be composed into more complicated applications. It is in fact separation of concerns. This is only one concern. The UI of a single component. In a full React app the busines…

As an aside, is anyone else a a bit worried about is the massive use of destructuring assignment and rest operators and whatnot? I see it a more in React/Redux code than anywhere else.

I really like how it can reduce a number of tasks to less code, but it's the most common thing that trips me up when I read React or 'ESNext' codebases. It feels like ternary operators on steroids, with all advantages and disadvantages magnified.

Perhaps I just need to get used to it.

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

#147

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…

> that we had the separation of concerns wrong.

Well, yeah. Forgive me, because I never know, here, if I am talking to my grand-son or my grand-pa, but "Separation of concerns", as an idea, came up when we thought that HTML/JS/CSS was about describing web-sites, for, for example, the NYT vs the WSJ, not for an applet or Swing replacement.

Separating content (including, maybe, semantics too) from presentation (branding, look&feel) makes sense when you are talking about web-pages. I don't even know how the idea transmogrified into a point-of-contention on SPAs.

It's quite funny when you think about it: "Look, Ma! I can build a fully functioning GUI out of type-setting elements and sticks!"

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

#148
post #120

Earlier quoted context omitted.

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 h…

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

I've started to get so pissed off every time I read about 'separation of concerns' whenever React is discussed. I had the same misgivings at first, but all it took was a short explanation of how 'concerns' is not necessarily about splitting html/js/css.

I've never read a single convincing argument to counter it except perhaps YAGNI, for some small projects (which even Redux-creator wrote about). It's almost always a throwaway comment about how silly front-end is these days, or an argument based on a lack of understanding of how React works.

Separating html/js/css is one of the first things many of us learned. The fact that a massive number of us are okay with React probably means something.

Mostly I'm just wondering why people bother. If you've got some serious concerns, express them. If they make sense, I'll happily change my ways and discard React. But what do you gain from essentially implying that a huge section of developers are idiots without arguing why.

Don't get me wrong, there's plenty of questionable stuff going on in front-end-land, but React has a level of mindshare so big that disagreeing demands a proper justification other than 'we always did it this way and this new thing looks a bit like the old thing we were told to avoid'.

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

#149
post #67

I've been using preact with tsx and inline styles. Every component Is a es6 module that declares it's imports and exports. I have a theme.ts containing my theme variables. There are watchable models. Only views contain tsx and css as js. Views import a controller and mediate events to them. Controllers know nothing about the view and they are the only ones that can modify the model. My application contains a single i…

I tried getting Preact to work with webpack and TypeScript, but I ran into issues with aliasing (which AFAIK isn't possible in TypeScript). How did you solve this issue?

(I use webpack because it now supports tree-shaking)

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

#150
post #119

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…

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

You very well know that "Over the years" doesn't mean "in the last year or 2".

I'm merely observing that neophiliac programmers tend to massively over-exaggerate how long things have been around. And how much experience they have in that tech.

Post reply on HN