Hacker News Reader

Comment by mg | Hacker News Reader

For some reason, I never liked that all the code playgrounds have separate windows for HTML, CSS and Javascript. It makes it hard to grok what is going on. Does the CSS and JS get injected into the HTML? Is it loaded via injected <script> and <link> tags?

I'm also never sure what magic gets wrapped around the html I type. Does this thing add a DOCTYPE? A header? Or can I define my own header? Etc.

So I made this one, where you edit just a raw html page and see the output right away:

https://no-gravity.github.io/html_editor/

The code is here:

https://github.com/no-gravity/html_editor

One way I often use it is that I copy the whole source (via view source) of a page, paste it into the html_editor, add a <base href="url_of_the_page"> to it and then I can try realtime changes with all the external CSS and JS being loaded just as it is on the original page.

View on HN

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.

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.

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.

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.

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

https://RTCode.io is our single-pane, reload-free, HTML/CSS/JS playground!

Video: https://rt.ht/yt (multi-device, live sync without reloads)

Home: https://elefunc.com/#rtcode_io

Playground: https://rtcode.io

Network: https://rtedge.net

---

To import from CodePen:

• https://codepen.io/jkantner/pen/NWEgzoK (original)

• https://rt.ht/codepen.io/jkantner/pen/NWEgzoK (import)

• https://rtcode.io/jkantner/pen/NWEgzoK (import)

Does not work at all for me.

Is this a commercial product?

What is it that does not work? You can also email us at support@rtcode.io

• https://new.rt.ht (try starting fresh here)

If you cannot save your code, just save the URL which encodes the complete state down to the selected text ranges.

Saving/deployed to 275+ Cloudflare locations may not be available globally yet.

It is will be a free playground with commercial features, such as edge-deployed workers which can be developed in-editor:

• https://sw.rt.ht/? (in-editor)

• https://sw.rt.ht (edge-deployed)

This is very nice, and I can see myself using this in the future. However, I have one slight piece of feedback; is there any chance you can make the delay on the menus flying out and tooltips just appearing all over the place when I move my cursor just a little bit longer? I felt like I was getting bombarded with information by just wanting to move my cursor to the other pane.

Besides that, I like it. Thanks for the links.

We will increase the delay. Thank you for the feedback! You can reach us anytime at support@rtcode.io

> Does the CSS and JS get injected into the HTML? Is it loaded via injected <script> and <link> tags?

Does it matter? (Serious question) Not for a full website where it matters for duplication / caching / performance, but in this context - for the playground.

Yes, the placement of the script tag very much matters, but it's most likely after your html or deferred to run after your html, in which case... Not really.

There is one little quirky js thing you can do to get the script element from inside the script but I doubt many people are doing that.

I do stuff like this regularly:

  <div>…</div><script>document.currentScript.previousSibling.…</script>

Provided you care even vaguely about code size (and are ending up with handfuls of kilobytes at most, not multiple megabytes), inlining everything is excellent for performance (seriously, unreasonably effective, way more than most expect), and if it’s stuff that must be done before the document is fully interactive, then doing it immediately like this rather than messing around with DOMContentLoaded event handlers and querying and such is likewise excellent for performance.

Yeah I think I was doing something similar. The scripts can safely be executed as soon as the HTML/DOM is in there, no need to defer to the end.

> There is one little quirky js thing you can do to get the script element from inside the script.

Now you *have* to elaborate. And what's the problem it solves?

I think it's just document.currentScript

I used it years ago because we had an XML based templating engine and some "components" needed to inject little scripts to add functionality. I could have given everything unique IDs but this was more fun. Forget what I did with it but I need to know where it was in the DOM or something.

Sometimes yes, sometimes no.

> or some reason, I never liked that all the code playgrounds have separate windows for HTML, CSS and Javascript. It makes it hard to grok what is going on. Does the CSS and JS get injected into the HTML? Is it loaded via injected <script> and <link> tags?

Tbh I also never liked it, for all those reasons you listed.

Ideally it would be a left panel with a treeview list of files with the selected file displayed on the right panel in an editable element.

Output should be a different window which updates on every change.

Agreed. Great job.

Yes cubed! Thank you.

Reply on news.ycombinator.com