Hacker News Reader

Comment by gpmcadam | Hacker News Reader

One of the strangest things to infect the web development community was that separation of concerns somehow meant separation of HTML/JS/CSS, which to me always felt like the opposite since very often the HTML, the JS and the CSS were all very much concerned with one another e.g. a React component where the rendered HTML, the logic behind it and how it's styled make sense to live next to one another.

I think it's for this reason you often see those languages split out in code playgrounds. And I also think it's a big part of the initial pushback against css-in-JS libraries such as styled-components or Emotion.

View on HN

> …very often the HTML, the JS and the CSS were all very much concerned with one another e.g. a React component where the rendered HTML, the logic behind it and how it's styled make sense to live next to one another.

This is why I absolutely love Vue single-file components. AFAIK, there’s no elegant substitute for these in React.

https://vuejs.org/guide/scaling-up/sfc.html

Not trying to start a flame war but what can you do with these that can't be accomplished with React and e.g. https://styled-components.com ?

I think the real problem is that CSS mixes in two many different concerns.

If I want to create a reusable component I need to control the layout tightly, and use media queries for display size.

The user of the component needs to control the colour and cosmetic stuff, while also using media queries, but for dark/light mode.

All four use cases use the same bloody input - CSS! Which means all of the different parties are stepping on each others toes because they may accidentally set a property that needs to be set by a different party.

It's not designed for separation of concerns.

> All four use cases use the same bloody input - CSS!

All of the four mentioned use cases are stylistic. So it is desirable to accomplish them in a domain-specific styling language.

Used correctly, conflicting regressions are greatly minified.

It's just the problem with CSS that the vast number of developers don't know about its fundamentals, such as "CSS Specifity"

https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

This collective lack of knowledge leads to the kind of "monkey patching until it works for me (and breaks for you)" many lament about.

Feel free to give an concrete minimum viable example (including code) where you are struggling with CSS, and I will try to give suggestions.

> All of the four mentioned use cases are stylistic.

I respectfully disagree.

CSS controls layout of child components within a container, which is not a stylistic use case.

I've used Qt, WxWidgets, Tk, Delphi, VB and more, and none of them treat layout as a characteristic identical in nature to (for example) background-color.

Finagling the layout manager in any UI toolkit uses a very different mechanism from specifying the colors to use.

> Used correctly, conflicting regressions are greatly minified.

Maybe. I dunno if it is reasonable that the human reader can know all the CSS styles and files, and still not be able to tell which style will eventually be applied, because all of them have a '!' somewhere. > Feel free to give an concrete minimum viable example (including code) where you are struggling with CSS, and I will try to give suggestions.

I'm not really struggling; I find it weird, that is all - I think it is a mixing of concerns when the mechanism used to specify the location of (for example) the major page elements (menubar, leftnav, maincontent, rightnav)is the same as the mechanism to specify the background-color.

It makes more sense if you think that an HTML is a static document, which then gets decorated by CSS, and lightly animated by JS.

That is what the web was built as. We were supposed to browse documents like we browsed magazines. Your React monstrosities were hacked on top of that model, turning the browser into an application runtime - which it wasn't meant to be.

That’s a misreading of history. Here’s the announcement for JavaScript, which was posted here just yesterday[0]:

It says,

> MOUNTAIN VIEW, Calif. (December 4, 1995) -- Netscape Communications Corporation (NASDAQ: NSCP) and Sun Microsystems, Inc. (NASDAQ:SUNW), today announced JavaScript, an open, cross-platform object scripting language for the creation and customization of applications on enterprise networks and the Internet.

(Emphasis mine)

JavaScript was always meant for building applications.

[0] https://news.ycombinator.com/item?id=36782761

Even assuming JS that was originally meant for hover effects (or "rollover") and other "light animation", complex web applications predate React by a lot.

Think Outlook Web, Google Maps, and all the smaller apps built with frameworks of their time such as Dojo, YUI etc

There also are monstrosities with the server at the center...

applications with hundreds of hidden form fields per page, required server sessions for anonymous users, DSLs in half-baked server-side templating languages, server code generating and injecting opaque JS to sync state with the client, the list goes on.

And these things all have ups and downs themselves I guess, just like React has.

In fact animation is one of my least favorite uses of JS, the more I can do in CSS, the better.

As a user sometimes I enjoy complex animations but only when it serves a purpose.

Those applications were meant to run on the server, more precisely on the Netscape proprietary appserver. On the browser they were meant to do popups and basic form validation at best. There was not even a network communication mechanism!

This is not what was intended. Just read the 1995 announcement - straight from the horse’s mouth. It was clear that Netscape had big plans for this. JS had its limitations, sure, but it could talk to Java on the client - which certainly did have network access. And famously, Microsoft felt so threatened by this new “platform” that they feared it would make Windows redundant. The late 90s was a wild ride.

> JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers. While Java is used by programmers to create new objects and applets, JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server. JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications.

You just have to read that to see how JS was just meant as a bit of glue between JDK and html pages. Java would do the heavy lifting everywhere.

Yes but you understand that the JDK was running in the browser, right?

The browser has been an app platform since Netscape developed plugins. That is my whole point.

But Netscape didn't create Java. The browser was not created to be an application runtime; commercial interests shoehorned the role onto it.

> But Netscape didn't create Java

So what? They didn't invent HTML either.

> The browser was not created to be an application runtime

It's been 35 years since HTML was invented, and 30 years since Netscape was released. There have been dozens - or maybe even hundreds - of browsers written in that time. So when you say, "the browser was not created to be an application runtime", really, I don't even know what that means. Which browser? Amaya? Arena? Lynx? Mosaic? Netscape? IE? IE6? Webkit? Blink?

"The browser" was created to be whatever their creators wanted it to be. Netscape, for better or worse, wanted it to be an application platform. And, to their credit, they were right.

> So what? They didn't invent HTML either.

Exactly. They fucked up something that someone else had thought up.

> when you say, "the browser was not created to be an application runtime", really, I don't even know what that means. Which browser?

Pretty much none of them, except maybe IE (WebKit and Blink are not browsers, they are rendering engines, btw). Some were thought for read-write capabilities in pages (Amaya and to a degree the original Netscape suite with their built-in editor), but that's basically it. Netscape pivoted this and that way, as scrappy startups are wont to do, following random partnerships or shipping their own suite, until they were acquired by AOL. Whatever they say, they really had no big design; they just threw the kitchen sink at something they thought would be cool. It just so happened that eventually Apple and Google figured that the JS/HTML coupling made for their best bet to break Microsoft's dominance in the application space, and started throwing engineers at it. Without that move, JS would still be the rollover trick-pony that it was in the early '00s, with the wonky inconsistent syntax and horrendous performance.

The one browser that was really thought of as a runtime was basically IE, with ActiveX and its deep embedding into Windows. That was a bad idea and it rightly ended like it did.

Frankly it doesn't matter what it was meant to be, and it doesn't help at all thinking about it as a way completely separate from reality.

Web/JS did what Java tried to do, a runtime that works on all platforms. The problem is that its too heavy weight. But platform lockdown will prevent any competition.

There is no one rule that fits all projects, this is what being an "engineer" is all about. If there were hard and fast rules for building applications, all of us here would either be out of a job, or doing the software equivalent of working on an assembly line.

However, my own personal guidelines are::

* A small project lives all in one file.

* A medium project is organized by what the files are (markup, images, etc).

* A large project is organized by its major components, and how those components are themselves organized depends on _their_ size and what they do.

* Never be afraid to reorganize a project if (and only if) it makes sense.

Reply on news.ycombinator.com