Live data from Hacker News

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

twitter.com

51–60 of 177 posts

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

#51
post #28

Earlier quoted context omitted.

Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.

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 actually write a larger app’s UI that renders using React.

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

#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 React - the old tools and techniques handle that use case well. But if you're building a webapp, something with complex, dynamic client-side behaviour, it doesn't make sense to pretend that CSS, HTML and JS aren't already heavily coupled by the nature of what you're building. React just embraces that idea, rather than pretending it doesn't exist.

The reality of modern apps is that JS is going to transform your HTML and CSS at runtime, and most of the bugs you'll end up tracking down will be related to it being transformed in ways you weren't expecting. React's component model and declarative rendering are far more effective at addressing this problem than any other tool I've tried.

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

#54
post #45

Earlier quoted context omitted.

It was fine when the UI was basically simple enough to be one or two components. Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation.

> Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation. Maybe on the web, but we've been creating desktop (and console) applications just as complicated as any web app for a long time, that's where the importance of separation of concerns was first learned.

Yes, but where do you separate these concerns... Do you put view rendering and raising events in separate files? From my own experience in reviewing other people's code, it depends, but usually no. I mean, you can use MVC as separation pattern, but there's also MVVM and many other patterns that place the walls in different places.

I'm pretty happy with how React/Redux works compared to what came before... separating file structure by directories of features, and components/actions/reducers that represent them is much easier than looking in one spot for all my view templates with a goofy DSL abstraction, and another directory for the actual event binding.

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

#56
post #10

Separation of concern or technology? A well structured React application is much easier to understand than something where you need to keep 3 files in your mind at once.

Or worse when those three files are in three different, mirrored directories.

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

#57

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…

That's lovely. Beautiful, readable, elegant bit of code.

(35 years experience)

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

#59

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…

Completely agreed... I've been building web based apps for over two decades now. React is the first framework that feels "right"... there are some things that could be better, It's so much better than what came before. Angular brought me so many WTF moments, I can't even begin to mention them all, even ng2+. With React there's been a handful, usually with a useful error that made sense.

So much effort has been done with React to work with the broader JS community and its' direction as opposed to against it. ES6 class syntax, simple render function components, modules. React doesn't need much to get started, and it's unprescripted enough that just a few tools can round it out, with heavier and lighter options.

I don't want to go back, and frankly, I'd rather have JSX in my JS than go back to weird template DSLs ever again.

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

#60

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…

> shittiness of Tim Berners-Lee's overly-verbose and unmaintainable HyperText Markup Language A bit too strong. Imagine Markdown becomes wildly popular and the majority of the Internet's content is now available in Markdown. As more content becomes available, we expand Markdown to include forms to get bidirectional communication. There are some layouts and styles that can't be done in markdown, so we add stylesheets.…

We're all geniuses when we have 30 years of retrospect.
Post reply on HN