Will you write HTML with us tomorrow? | Hacker News Reader

Will you write HTML with us tomorrow?

html.energy

153 pointscookingoils62 comments

Hi HN,

Looking forward to writing HTML together tomorrow at 2PM EST. You can join our discord to share your writing/websites [1] during the freewrite.

Also we just wanted to share a little more about HTML Energy. It’s still coming together but here are some of our big dreams…

- Create a #web0 movement: We would love to see a new movement around web0 (coding HTML by hand, personal websites, webrings, etc). Basically anything that brings websites instead of platforms into the spotlight again. We are actually pretty inspired by all the energy that is going into web3 right now. What if that same energy and capital was going into web0? What could we create together?

- Rebrand HTML [2]: Some people think that HTML is outdated or hard to use. We think it’s actually pretty straightforward and really powerful stuff. Stripping away all the paint (CSS/JS) really makes the content the focus and there's a raw sincerity to an unstyled page. Our goal is just to get people excited about learning & writing HTML and this is our attempt at making it "cool."

- Getting HTML into schools: What if more people knew how to self host/publish? Would we depend on big platforms less? Would people begin making more small community websites to chat with their friends?

- Create another season of our podcast [3]. Last season we talked with so many incredible people that are trying to make the web a better place. Let us know if you listened and would want another season.

Hope to see you tomorrow and have a great night!

<p>'s on earth!

[1] https://discord.gg/SsPKzA8N?event=931711702578384947

[2] https://twitter.com/htmlenergy

[3] https://html.energy/podcast.html

Is just a lil bit of JS allowed?

Sure! We understand that JavaScript and frameworks are nice to have but it feels like everyone depends on them too much these days.

It would be pretty cool if someone that has never made a website before, learned a little HTML, wrote an index.html, and published it on the www. Maybe that person never learns CSS, JS, or any framework and that's totally fine. We think that the simplicity and directness of HTML is what makes it powerful.

Hello, very interested in this, thanks for making this event. Maybe I’ll join tomorrow.

This is one of the few websites that don’t force you to use https even though it does have it! Impressive.

In the spirit of keeping things open and without a user account, I’d recommend setting up some jitsi [0] conference rooms that don’t require an account.

[0] https://jitsi.org/

Thanks for that suggestion. We haven't used Jitsi but will look into it.

Hope to see you at the freewrite.

> This is one of the few websites that don’t force you to use https even though it does have it!

That’s bad, not good. Cleartext HTTP is a nice idea for an ideal world, but that’s not the world we are in: it’s demonstrably a vector for abuse, both passive and active. Save for a very few specific use cases (captive portal detector being the main one), it is irresponsible to support cleartext HTTP for any purpose but redirecting to HTTPS, preferably with a Strict-Transport-Security header so that that particular user agent skips straight to HTTPS forever after.

We're speaking about static websites, there is no password to steal and MITM attacks again such content is very highly unlikely.

It is true that this website has no password to steal, but a MITM attack could still be impactful. For example, a MITM attack could inject a <script> tag to run arbitrary client-side code. Any content that is served over HTTP has a risk of being swapped out by a MITM, which is why most browsers are nudging users to only visit HTTPS websites.

With that said, implementing security is a trade-off between your time and risk tolerance.

A variety of ISPs in different countries, including some of the biggest ones in the USA and India, have been performing MITM attacks on HTTP traffic for many years, injecting their own stuff, sometimes to notify you of service-related matters (which is a terrible way of delivering such notifications, especially when it breaks various pages for various reasons), but I’m pretty sure I’ve heard of at least one case of them injecting ads and other potentially malicious stuff too. ISPs as a class have proven themselves untrustworthy, time and time again. Doing anything in cleartext is just asking for them to mangle it.

And that’s just the active. The passive is pervasive too, and is an attack (RFC 7258). And so I use the term “irresponsible” of anyone running any web service except for a very few specific purposes over cleartext HTTP.

There are reasons why we’ve shifted from cleartext to TLS for everything, not just for things conveying sensitive data.

Not to argue against HTTPS, but it is not foolproof in case of a MITM on ISP level. I’m willing to be corrected here, but even if you (as a developer) use HTTPS, unless you are big enough that major browsers pin your certificates, initial connections still use HTTP—so a MITM can replace everything anyway, including presumably any HSTS headers you set; and if you (as a user) are conscious of that and use a private VPN that you trust, then serving a static website like the OP over HTTP shouldn’t be as much of an issue.

I wonder if more malicious code is served from questionable ads on HTTPS sites than from ISP MITM injections into HTTP sites.

Such an MITM-powered phishing attack is certainly possible, but in practice it’s not quite such a problem as it seems at first:

ⓐ With a suitable HSTS and max-age header, it’s roughly only the first time you access the site at all that you’ll go via HTTP;

ⓑ Anyone can submit their site to the HSTS Preload list <https://hstspreload.org>, which solves the problem completely for a particular site (including subdomains);

This final point is really the key to it all, and the place where I wish browsers would hurry up: they should be shifting to interpreting URLs typed into the address bar with no scheme as https:, not http:. There will certainly be some rough edges that need to be caught with it, and you might want to set IP addresses and a small number of names to default to HTTP, but even without that, Firefox’s HTTPS-Only Mode has all the required ingredients: if I type “neverssl.com” into my address bar, it pops up the about:httpsonlyerror page, “HTTPS-Only Mode Alert / Secure Site Not Available” with explanatory text and buttons “Continue to HTTP Site” and “Go Back”. They could do something like that specifically for typed URLs. (You might think “just downgrade automatically”, but that’s an attack vector—they can just block port 443—where requiring manual user intervention with a mildly scary warning mitigates it somewhat.)

The default really should be HTTPS by now. A little while after browsers all finally flip that specific thing over, I think we could collectively shut down port 80 for good, because no clients will ever try it any more.

Any inclusion outside of discord? It’s a non-starter.

Sure! You don't really need to join the discord (it's just extra like JavaScript).

We will be writing at 2-3PM EST so you can just join us telepathically and if you feel like sharing what you created leave it in a comment here or email us a link [1]. We would love to see!

[1] htmlenergy@gmail.com

I can't make it tomorrow, but I absolutely love the concept of a day for engineers to pair with those wanting and willing to learn. That's an awesome idea!

Thanks for this, and I really hope it's a success that you can build on. This is good stuff.

I’ll try to at least be around to help people on Discord - I may use that time to set up Emmet and build my muscle memory, too, as I have a front end project coming up and haven’t written any substantial HTML in years.

My oldest daughter is 13 and I was planning on helping her set up a side project of her own; a simple static site for her to collect and document her knowledge of horses. I sent her the link. She was just asking about how Markdown got converted to HTML, and a solid foundation in HTML itself would be super helpful.

  <!doctype html>
  <html lang=en>
  
  <meta charset=utf-8>
  <title>Thank You</title>
  <style>html { text-align: center }</style>
  
  <p>
    Thank you.<br>
    Love the idea.<br>
    <strong><code>&lt;p&gt;</code>’s on earth!</strong>
  </p>

> 2 PM EST

That seems to be 7 PM UTC. (PSA: if your event isn't geographically limited, please include the time in UTC too - a lot more people know the conversion from that than whatever your local time zone is.)

There's something magical about writing raw HTML/CSS. Nostalgia must be part of it -- I'm guessing many self-taught programmers growing up in the late 90s/2000s started out by learning HTML/CSS before dabbling with JavaScript, Flash, PHP.

It's also extremely satisfying to make a webpage with zero dependencies. No JS frameworks, no build processes; just a direct conversation between you and the Browser. That tight feedback loop is plain _fun_, especially for those of us who feel bogged down by modern software development.

Finally, writing raw HTML/CSS aligns with the founding vision of the world wide web, in which individuals could independently create and host content without any technical barrier to entry or dependency on corporations. The age of the personal webpage is over and I think that vision of the web is mostly dead, but I'm happy to see people keeping the energy alive.

Yes! That "direct conversation between you and the browser" is what we are calling HTML energy.

> The age of the personal webpage is over and I think that vision of the web is mostly dead, but I'm happy to see people keeping the energy alive.

Our hope is that a movement (web0 or whatever you want to call it) could bring this back.

HTML was originally envisioned as something extremely user-friendly to let people and companies customize their online presence. Nowadays multiple professional roles and software stacks are between the content and its HTML representation.

It tells us something, but also regularly what's easy looks hard. I have organized some hackathons and coding events for students. Some start with create-react-app for showing an image. They are very hesitant to do things the "manual" way when I suggest it. I think it's awesome that vanilla gets to have a community like this.

Then they invented the DOM.

I love the DOM but most developers would rather jump off a bridge than write some logic to walk a DOM. I have never understood why there is so much fear about the DOM, why that fear is so astonishingly prevalent, or the extremes people will go to in order to sidestep this phobia. So curious because this is a subject that takes about 2 hours to learn after which your career takes a different trajectory.

The DOM has double impedance mismatch written into its most basic foundations. It's an object oriented API to something that functional programming is much better for (functional programming loves manipulating trees recursively). And then, you're using Javascript to program it, a dynamic scripting language, but the DOM spec is heavily biased towards static C++ or Java, thus it simultaneously fails to take good advantage of the opportunities a dynamic language offers while also importing the verbosity and hoop jumping of 1990s statically-typed programming... and statically-typed programming has come a long way since then!

You can see this most clearly in DOM 1.0: https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-on... Look particularly at the "IDL specifications". That's Java, not Javascript!

Later versions have improved various elements of this, but the fundamental architecture is still there and still not looking much like what I would write down if I wanted to write out a similar system natively for Javascript, assuming this was still the 1990s and that meant I could also modify JS itself a bit.

When you learn how to work around these impedance mismatches you can do some good work, but the resulting code may not make much sense to your coworker. Fortunately, even in native JS nowadays, .querySelector and similar APIs make it unnecessary to have to "walk" the DOM much anymore.

I'd even argue you could cite the existence of a triple mismatch, in that the original DOM level 0, supported in Netscape 2.0, entirely precedes the idea of a writable DOM. (It wasn't until Netscape 4 that we got "layers", which were useless, and it was IE 4 that finally gave us manipulable DOMs as we know them today. [1]) So the standard that was originally written with the concept of introspection and largely read-only access (you could only write things that the browser could guarantee wouldn't require a reflow, and not necessarily all of those) got a lot of write access bodge onto it later.

Historically, it's a huge mess.

[1]: They didn't necessarily work the way we expect today for much longer than that, I crashed IE 4 a lot with stuff we'd consider trivial today, but it was the first browser to at least try presenting everything in the DOM as editable.

It sounds like you are looking at anything you can find, grasping at straws, to rationalize insanity. So much of what you described is absent in the Level 2 and Level 3 specifications. This is clear when your reasoning only makes sense using a 23 year old expired snapshot for an evolving technology that remains the backbone of frontend technology today.

* https://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/

* https://www.w3.org/TR/DOM-Level-3-Core/

The DOM is a language agnostic API written without any particular programming languages in mind and written to simultaneously and universally support both HTML and XML Schema.

These are stylistic and organizational concerns still not enough to qualify the irrational behaviors favoring jumping off a bridge. This is concerning considering learning to use the concepts takes substantially less time than learning the APIs of modern JavaScript frameworks developers favor. There remains far more to this that is psychologically focused regardless of any technology.

Technologies maintaining reverse compatibility always contain echos of their beginnings. History matters. We still live with those wrong foundations chosen at the beginning.

But if you just want to blame almost all developers everywhere across several decades for mysteriously being unwilling to engage with a simple and wonderful technology that has no flaws, feel free. It's easy, but it leads to no further understanding or wisdom.

Blaming the technology is not sufficient to explain the behavior. Ignoring that and putting your head in the sand isn’t an indicator of wisdom.

http://www.fallacyfiles.org/bandwagn.html

No stress

  document.createTreeWalker()

is your steadfast friend

Walking the DOM is a problem because if (or when) its structure changes, everything breaks.

Also, "astonishingly prevalent"? Come on!

Then your code is too tightly coupled to an instance without you writing error handling or any kind of fallback. That kind of fragility is not limited to the DOM and can occur in any programming.

This is not a problem that can be fixed by error handling. It's just best avoided if an application developer is altering the DOM at will. The DOM is not a good, stable API.

Yes, it’s tight coupling and it can be fixed by writing better code. The DOM API has maintained full backwards compatibility for its 25 year history of massive evolution so it’s extremely stable. That stability is completely orthogonal to the incompetence of the developer using it though.

My daughter doesn’t like driving my manual transmission car and cannot figure it out. That doesn’t mean my car has an unstable API. She does mention the same sort of bullshit about blaming the technology for her own incompetence though.

I'm not talking about the DOM API. I'm talking about writing code that relies on a certain DOM structure - i.e. misusing that structure as an API format when it wasn't intended for that, and any changes made to it would not bear that in mind.

Other than the historic messiness the other comment raised, the DOM API is just... not good. I don't think it's surprising developers don't want to bother with fun stuff such as

- The only way to remove a node is node.parentNode.removeChild(node), until you get past IE11 then you can use Element.remove() https://developer.mozilla.org/en-US/docs/Web/API/Element/rem...

- Text node normalization - because there are separate representation of the exact same HTML https://developer.mozilla.org/en-US/docs/Web/API/Node/normal...

- NodeLists are almost but not quite arrays. They could also be live or static but you can't inspect it directly to tell which is which https://developer.mozilla.org/en-US/docs/Web/API/NodeList. Similar almost-array nonsense with HTMLCollection.

- Historically IE and Netscape/Firefox supported two completely different set of API and it was a horrible mess. You can still see remnants of that API war in functions that does almost but not quite the same things such as textContent vs. innerText https://developer.mozilla.org/en-US/docs/Web/API/Node/textCo...,

Maybe arguments of IE insanity were once vaguely qualified because it took an extra step of testing and learning, a straw that breaks a camels back. IE is dead now, years past sunset and about to be eliminated in June 2022, so these arguments no longer apply. The fear and insanity remain nonetheless.

Years past sunset? At work we have customers that use IE every day. These arguments certainly still apply, especially since IE isn't even EOL yet.

MS sunset IE in November of 2018. Security maintenance ends in June at which point IE will become a security threat and remains a core OS component (according to MS). At any point after MS can forcefully remove IE with a patch.

So IE is still here and we have no idea when it will stop being here (since companies also have to update).

Then they invented CSS ;)

When SGML, on which HTML is based, has all the customizing, organization, vocabulary extension, and authoring comfort features you could ever want, even stylesheets.

Think about it - you have a content model grammar with type-checked item-value pairs (attributes); then CSS comes along with a completely separate, not type-checked item-value syntax and value space that make even seasoned graphic professionals run away.

I understand the reasoning for using Discord/Twitter, but wouldn't it also be beneficial to have Mastodon/Matrix channels alongside, given the "minimal/small tech" style feeling of the page?

That's a great suggestion. Maybe we will create a Mastodon for the next one.

Maybe even an IRC chat with SSL support. There are discord bots that can sink the conversation between IRC/discord afaik.

But how many systems do we really need here, though? Where do you draw the line? Can I have an RSS feed that's updated automatically when someone says something in IRC? I'll just sub to the RSS feed, but only if it also converts the text into Markdown so I can...

Why isn't Discord just enough? Or just IRC? Honestly I think this fragmentation that gets suggested is why a lot of projects fail; never stand the test of time: they try to be everything to everyone.

Time to start chat.energy.

> they try to be everything to everyone.

They can without fragmenting.

Just combine a Matrix-Discord and a Matrix-IRC Bridge

I agree but I honestly just don’t like discord. Most of the times I use it on my mobile and my computer it chugs resources like if there was no tomorrow. But this is just my opinion and yeah, it was just a suggestion, I wouldn’t have refused to join if it were only on Discord. Although for the event in question I was not able to attend because I overslept.

As much as everyone liked to rag on MySpace, there were valualble skills being taught. How much about web development has Facebook taught its average user?

very true!

This feels a little like IndieWeb, but focused on HTML, which is nice.

https://indieweb.org/

I must say that I really enjoyed creating web sites back in the 90s. I was using UNIX terminals that didn0't have graphic capabilities. I was browsing web using lynx, I've create pages in vi, nano or joe. It was all about the content and quality of the content. There were no dark patterns, scams, no spam... Just the desire to get the information out there and to find other who felt the same.

I don't really understand the goal.

IMHO it's to help support their podcast: http://html.energy/podcast.html

Seems niche and fun to me. Not that I'll participate. I made a website once, never again.

That bad?

Thinking about it makes my RSI flare up.

I'm probably just too much of a control freak to deal with the uncertainty of browser-craft. (All respect to those who do web stuff) I'm from a painterly background and do cgi. If I want a pixel somewhere I'll put it there.

Ironically if you stick to a certain set of the HTML, CSS and JS specs - and keep things simple - you'll never have to deal with browser-craft at all. Your code will just do the job of getting content rendered in a browser and it'll work on everything.

I think the entire point of this project is show people that they can make a website without having to be afraid of having the type of experience you just described.

If you just use HTML, then the words that you choose to write will be the words that everyone will read.

Any "pixel placement" is optional and shouldn't be a detering factor.

I did use plain html. This was back on '02.

I meant 'pixel' as a synecdoche, to stand in for all the elements of computer art and visual craft.

It looks like getting together to write HTML. Socially

The right kind of energy.

Cool! I miss writing plain htmls - no setup, no installs. Just open a text editor (Notepad!) and you can get started.

What about websites that can be sent via email? Nested tables, inlined styles, code could be copied to HTML email and the single page website would display in an email client. Animations with marquee.

I'm not sure if you've ever dabbled in HTML email development but I would definitely not recommend it as a starting point for learning basic HTML.

I like this web page. It is very readable. I wish more pages had this splendor. Perhaps it can be web3.

Where can I get good tutorials on HTML and CSS?

Reply on news.ycombinator.com