A list is a monad, but not because it wraps another type. What you're describing is higher kinded types.

A monad is a specific variant of a higher kinded type whose primary property lies in the fact that its value can be "evolved" via a specific function application (usually known as the "bind" operation). This sounds confusing but it's really a simple concept: if you take a higher kinded type, you can think about the values within it as the data and the type itself as metadata or a context of some sort. For example, an int is a piece of data, but a `Maybe int` is the same data with the added context of it being possibly absent.

A monad is not the only higher kinded type. Probably the most familiar HKT to working programmers (even if they don't know it) is the functor, which is a type that can be mapped over (in the sense of map-filter-reduce). If you have a `Foo<A>`, you can apply a function to turn it into a `Foo<B>`. However, a limitation of the functor is that you can only affect the data at the individual item level, not the context as a whole, so if you put a list of five values in, you'll get a list of five values back.

If we want to affect the context as well, we instead need a type like the monad, where we can "bind" a function that takes the inner value and returns a whole new wrapper based on it.

Why is this useful? Well, it can express a lot of different things very neatly - for example, fallible computation. Let's say you have two functions that both return a Maybe monad. In a language with nulls, you'd likely have to do something like `a = foo(); if (a is null) return; b = bar(); if (b is null) return`, which is tedious and error prone. Monads lend themselves to composing such chains extremely well, so you can simply do `foo().and_then(_ => bar())` and in the end have a value that combines the result (success or failure) of both of those functions.

Null values = chains of null checks = monads! Futures = chains of callbacks = monads! Mutable state = chains of writes = monads! Sequential execution = chains of statements = monads! And so on and so forth. You can get pretty crazy with it, not that I would recommend it.

Monads seem complicated and scary because most mainstream programming languages don't have the necessary abstractions to talk about higher kinded types as its own thing, but in reality most programmers are using monads daily without even realizing.

It reads as a little ambiguous to me in your comment, so just to be clear:

A polymorphic type - "a type wrapping another type" - isn't the same thing as a higher-kinded types.

Higher-kinded types are what let you express, in the language, the very notion of "a type wrapping another type". A "List Int" is a type wrapping another type; a "Maybe Int" is another type wrapping another type; but we can also say that "List Int" and "Maybe Int" (and etc.) can be abstracted over as "Monad Int"s. Monad is a higher-kinded type because it's a type wrapping types wrapping another type.

You missed the point though with that. It's explicitly not a monad if it doesn't have an equivalent of bind. If I need to write an imperative function to process the monad into another it's not a monad.

If however I have a List<byte> and would like it to become Maybe<UInt128>. A loop is always a jmp of some sort, a bind though could become a SIMD operation or be passed off to a coprocessor and I as the programmer would be none the wiser since all I cared about was the end result.

Simple != idiomatic. It's perfectly idiomatic to `Arc<Mutex<Box>>` in Rust, and it is more complex because it deals with more concerns than a simple reference, namely being thread-safe. Sometimes you need that, sometimes not, but you have to be explicit about it.

There’s no reason to have a Box<T> there, because Arc already boxes.

I have a feeling that most of the clarity you find in your example comes from better use of whitespace. Consider:

    pub fn read<P>(path: P) -> io::Result<Vec<u8>>
    where
        P: AsRef<Path>,
    {
        fn inner(path: &Path) -> io::Result<Vec<u8>> {
            let mut bytes = Vec::new();
    
            let mut file = File::open(path)?;
            file.read_to_end(&mut bytes)?;
    
            Ok(bytes)
        }
    
        inner(path.as_ref())
    }

Plus, your example does not have the same semantics as the Rust code. You omitted generics entirely, so it would be ambiguous if you want monomorphization or dynamic dispatch. Your `bytes` and `file` variables aren't declared mutable. The `try` operator is suddenly a statement, which precludes things like `foo()?.bar()?.baz()?` (somewhat normal with `Option`/`Error`). And you weirdly turned a perfectly clear `&mut` into a cryptic `&!`.

Please don't assume that the syntax of Rust has been given no thought.

The lossy vs lossless distinction loses its meaning in the absence of provenance. You can compress a bitmap into a .jpg q=1, and then save it as a .png. The .png is technically lossless, but that clearly doesn't tell much about the image quality. Conversely, many cameras shoot JPEG as the source format. The .jpg is, in effect, the master copy from which the loss is measured (obviously there are losses from the sensor data, but still).

I thought most cameras shot RAW and then chose a format to save to (some letting you save RAW itself, at least with Android).

And a CDN could want to do it, because you can degrade a png in lossy ways from the original that make it compress much better, even though the compression is lossless.

Speaking from the experience of building small web apps for personal use, trying to follow semantic HTML in good faith has been nothing but a source of frustration. The rules are clearly molded around static, primarily text-based documents defined upfront, and anything that doesn't fit this format feels like a second citizen at best. Take headings, for example: in component-based development, I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless. As much as I want to be a good citizen, if I have to fight the platform for it, you're getting divs and h2's everywhere.

It is perfectly reasonable and accepted html to use custom element names. Any element with a `-` is styled like a span by default.

  <article-content>
    <author-byline><author-byline>
    <content-text></content-text>
  </article-content>

This has the benefit that you can describe your markup however you'd like if it doesn't fit into the standard elements, and if you find yourself in "div soup", often times this is mitigated through class names, but using custom elements, the closing tags are much more readable than

      </div>
    </div>
  </div>

Custom elements are incredibly powerful. Not only do they have their own tag name for easy selecting from css without having to use a class, but by adding custom attributes (eg size=“large”) you can basically eliminate the need for css classes entirely. Combine that with attr() to put the attribute value anywhere in or around the element with pure css and plenty of interactive components can be built purely with css, no scripting required. You can even use the @media scripting block to add noscript behavior to custom elements from css.

And then you can register a javascript class with customElements.define to add more dynamic behavior, and the sky becomes the limit. Custom elements are like a hidden framework built right into the browser.

While I believe you are entirely right from a developer perspective. I do wonder if the same is true from a UX and more specifically accessibility perspective as the author in the article describes.

If you are unsure what I mean, from the article

> I show them that a span with an onclick-event might seem to be behaving like a link, but that there are many layers of UX missing when you look a bit closer: right-click on this span, and a generic context menu opens up. When on the other hand you right-click on a proper link like this one a specialised context menu opens, with all kinds of options that are specific to a link. And I show them that proper links show up when you ask your screen reader to list all the links on a page, yet spans with an onclick-event don’t. Moreover, a span doesn’t receive focus when you tab to it. And so on. My students see this and they get it. And they love the fact that by being lazy they get much more result.

Accessibility will rely on correct use of landmarks [1] and aria attributes, as well as real links (like the article mentions). Custom elements can do that just fine, by either decorating them with aria attributes manually and placing them in or around landmark elements, or by having the JS side of the custom element take care of that automatically. The JS class can generate any necessary markup inside of the element to help make it accessible, just like a component built with a JS framework would, and by using shadow dom and slots this markup can wrap around the child elements (though I think it's best to try to avoid shadow dom, as it is quite a cumbersome API to deal with). UX is a bit of a similar story, any kind of UX can be achieved once you register a JS class for the custom element.

[1] https://developer.mozilla.org/en-US/blog/aria-accessibility-...

I didn't know this was possible. I thought you were forced to use Javascript to define a custom element - this severely reduced its attractiveness. Why use JS for static UI ?

I don't know why custom elements never became common knowledge. I've had PR's blocked by people convinced I was doing arcane black magic by using them.

But they've been worked this way for decades. Now they weren't officially added to the spec until browser support for v1 of custom components, but that was still back in 2016.

I didn’t know any of this.

I feel like a huge door just opened on an idle Saturday morning. I need to experiment to form some opinions.

Thank you & parent poster too.

If you're interested in learning about this stuff, I recently made a website about it: https://plainvanillaweb.com/

This was recently posted to HN and I started to read it. I think your explanation for web components is the best I encountered so far.

That site is good - i might have missed it in your site but one thing I’ve run into with custom elements today is accessibility - testing with a screen reader has shown up lots of issues. Maybe custom elements aren’t perfect but they are handy.

I'll add it to the todo list :)

how every accessibility effort ends

this is a good article on styling with custom elements too: https://www.keithcirkel.co.uk/css-classes-considered-harmful...

Wait... I can just declare one of these in HTML without doing all the CustomElement JS jiggery-pokery?

No need to declare anything, just use the tag.

Sounds like you did not jump into the pool of flexibility and reusability.

> Sounds like you did not jump into the pool of flexibility and reusability.

Quite a good analogy: a pool is responsible for more drownings than you'd think.

Most people in the pool of flexibility and reusability are drowning in it.

This would be way more helpful if browsers all supported extending built-in elements and inheriting accessibility features.

For example, if `class DropdownMenu extends HTMLSelectElement` worked, you could have full control of styling and functionality without having to recreate all the a11y support baked into `<select>`. As it stands today, this will be treated as a div and its all on you to make it accessible.

Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_el...

The reasoning for choosing not to support it is here: https://github.com/WebKit/standards-positions/issues/97#issu...

Thanks! I was pretty sure Safari was the only major holdout but didn't have a link handy and didn't want to speak out of turn there.

That kind of support is a really tough one to work around with a major browser lacking support. For certain features its not a big deal, but when it comes to extending to get full accessibility support the only substitute is avoiding the feature and rolling it all custom. It really is a shame in my opinion, extending built-ins is extremely powerful.

Blame Safari. The standard includes the `is` attribute, it's supported by all browsers except Safari, but Safari not only hasn't worked on supporting it, they've stated they won't do so.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

Interesting, I did not know this was a thing. I just gave it a try and it seems to work as advertised. I'm definitely going to use that more. Div soup is super hard to untangle when you are debugging layout issues and I love having more readable html

It is the same div soup for a screen reader, because there is no behavior attached to those new tags. They can not be a landmark, there are not marked as headings, they have no roles. Just a container with a text. And to attach the behavior you need to use javascript. So without js it wont work.

Why bother and try yo create half-baked non working solution if you can just use html?

Well, it easier to style, maybe. But hey, there is a class attribute.

Custom elements are for when semantic elements run out, don't apply or are unnecessary.

Semantic elements are always preferred.

I had the advantage of having a mentor early in my career hold my code to the highest standards with regards to using the semantics of HTML. We were working on a big redesign of a large website for BigCorp, but we were still a small team on a deadline. She would not accept any excuses, and she guided me to think through HTML element selection until we found what we considered the best choice. I was taking the bus to work most days and used the time to read on the bus and at home the thick book "CSS: The Definitive Guide" by Eric Meyer cover to cover.

As you mention, working with HTML, and even more so CSS, can be a source of frustration. The UX of actually working with them is tedious work. However I can write today that all these years later, the high standards that my mentor held me to (and the project required) helped me to master HTML and CSS in a way that made doing that work less tedious, and easier over time. I was being paid to be educated by an expert - I considered it a great opportunity, and believe I have been proven correct.

In the post Vasilis writes that they told their students the assignment "doesn’t have to be semantic and shit". I consider this a missed opportunity to hold them to higher standards and help the students build a strength that can help them for years to come. More broadly, I believe this to be an example of current generations being limited by their mentors and educators lowering standards, and potentially robbing them of opportunities. Impedimentum Via Est.

I'd argue that the semantics of <bigcorp-career> vs <into-webdev-class> are different enough that it's a bit of an antipattern to apply the same style to each.

Even for text documents... for the love of documents, why wouldn't you have an official table of contents element?

Someone in a nearby thread mentioned custom elements. If we don't agree on meaning then it's not very semantic! Part of the power of agreement on semantics is that the more we have of it, the more we have things like Firefox or Safari's reader mode, which remolds the website to the user's desire.

What would a specific table of contents element bring over a <nav> inside your <main>/<article>?

(As demonstrated in the first example of https://html.spec.whatwg.org/multipage/sections.html#the-nav...)

The heading hierarchy is the table of contents. Rather than some magic that creates a set of anchor links that link to the page's headings, I want browsers to provide what screen readers do, list the headings and let people keyboard navigate to them without site authors having to do anything.

"SkipTo Landmarks & Headings" is a browser extension that somewhat does what I'm describing. It's harder for an extension to handle this smoothly compared to a browser. https://skipto-landmarks-headings.github.io

> Take headings, for example: in component-based development, I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless.

We could have used <h1>s everywhere with Document Outline:

  <body>
    <h1>top level heading (parent sectioning element is body)</h1>
    <section>
      <h1>2nd level heading (nested within one sectioning element)</h1> 
      ...
    </section>
  </body>

Unfortunately, this was never implemented in browsers and was removed in HTML 5.1.

https://html5doctor.com/computer-says-no-to-html5-document-o...

As I mentioned in another comment, I think developers would have fucked up way too often and the hierarchy still wouldn't be right. Having the right heading levels is not something that can be solved by an algorithm, it depends on a human understanding of the content.

I agree that when developing a component, or even a discrete piece of content, you shouldn't have to care about its place in the heading hierarchy of whichever pages it appears on. But someone needs to care.

There's an HTML spec idea kicking around that's currently called `headinglevelstart`. I think the idea is you put it on an element like <section> and give it a value and the heading level of any heading element within is incremented by that amount; use `headinglevelstart="2"` and an <h1> within is treated as an h3, an <h2> as an h4, and so on (I think extending the valid heading levels from 6 to each least what ARIA supports, 9, is along for the ride). It can even be a negative value so an <h2> heading that's typically lots of other pages could be "elevated" when it's by itself on its own page by adding `headinglevelstart="-1"` to a parent.

I don't know if `headinglevelstart` is a particularly good idea or if it will happen but it's definitely an aspect of the web in need of improvement.

I usually just use <header> for section headers. Technically you’re supposed to put an h[1-6] tag inside a header tag, but I just drop the header text in there raw and style it with scoped CSS.

<header> and headings are very different. A heading is how you semantically signpost the beginning of a different section of content. A <header> other than one at the beginning of a page, is basically a DX convenience.

Headings are the major way people using assistive technologies can skim a page and navigate around. I think a <header> will still be treated as a landmark, even if it's inside other landmark elements, but it will be nameless so not nearly as useful.

It can be a struggle for some people in some situations to create pages with a heading level hierarchy that accurately reflects the content. Sometimes I think when there's any difficulty, authors should basically give up and follow a simple guideline: have one <h1> that says what the page is about and use <h2> for all the other headings.

The words put inside the headings are far more important than the accuracy of the heading level.

It looks like <header> is treated specially when it’s directly under the <body> tag, but generic everywhere else. This is actually what I want for some widgets which may be arbitrarily nested and aren’t really contributing to a hierarchy, but not others where I would want to be able to navigate between the sections using the headings. I like the idea of just using <h2> for all depths below the very top, I think I’ll start doing that for headers that should be navigation targets.

Edit: looks like that’s basically the WAI approach too, in that role=heading will default to aria-depth=2.

Yes, my recollection was wrong. There are some landmarks that can be nested inside other landmarks and still be conveyed but <header> (ARIA role "banner") isn't one of them.

Using <header> elsewhere for developer convenience is fine but that's all it is.

Headings are especially helpful for screen reader users are especially helpful but their value for sighted users are often underestimated. Developers think that by putting something in a box and by its styling that people will understand what it is, what it's for, when using a heading to put a name on it would be very clarifying.

horrific ux. makes html harder to read for people that dont have the time to learn all this obscure bs.

and for screenreaders this will work maybe sometimes inconsistently. I hope visual llms solve it for our brothers and sisters with special needs. ( and for webscrapers)

BECAUSE THIS NONSENSE IS NOT SOLVING ANYTHING FOR ANYBODY

I think in part, it's also a case of there being some agreement on standard textual mark-up but not universally. And for good reason: books aren't journal articles, journal articles aren't poems, and heading and paragraph boundaries differ between languages.

Even practically, are sections part of articles? Or aticles part of sections in the context of a collection? Why do we need six heading levels, not four or seven? The semantic hierarchy does equally apply across publication contexts.

> The rules are clearly molded around static, primarily text-based documents defined upfront

I mean yeah, that‘s what the web was created for after all. There was no need to invent yet another operating system and desktop environment to replace the ones already existing. The advertising industry capturing the web and brainwashing one generation after another of „web developers“ locking in with said web developers seeing the web primarily as an economical niche to carve out and a means for job safety, is what happened. The end result is that the majority of actually interesting information you want to read is on archive.org nowadays, and on „platforms“ when easy self-publishing was the entire point of it.

Yes HTML is stuck being a markup language for casual academic publishing. Starting in 1997, people wanted to add entire new vocabularies, but W3C botched it by focussing too much on „meta“ stuff, subsetting XML from SGML but then not using it for actual emergent text formats apart from SVG and MathML such as blogs, drama, novels, wikis, etc. Instead they diverted into unproven XForms and SemWeb, leaving HTML in an organizational lock for ten years during the forming years such that everything else (CSS, JS) had to bend around HTML inflexibility, finally having the gall to call that failure a virtue (the structure-vs-presentation dichotomy, „semantic“ HTML, tunneling JSON through HTML, etc.).

> There was no need to invent yet another operating system and desktop environment to replace the ones already existing.

Actually there was. My web apps can be used in Windows, Linux, Mac, Android, iOS, Meta Horizon OS, etc. thanks to it being a standard that is more or less not controlled or gatekept by a single entity (browser monoculture aside). Java applets died because of it.

You could argue that it wasn't wise to shoehorn interactive functionality in what was essentially a document presentation format, but that's another story. Having documents and applications intertwined is often cited as a drawback, but I disagree with that since we often want to have app-like behavior for parts of documents, or document-like behavior for parts of apps. Think e.g. interactive programming tutorials with executable REPLs and code examples... we have the ability to create books that are alive, and that's simply amazing.

Thing is, the Web platform is what won, and for good reasons. GTK, Java Swing, and other supposedly multiplatform toolkits did not lose just because -- they lost because the Web is objectively better.

HTTP is awesome. HTML is awesome. CSS is awesome. JS is awesome. JSON is awesome. WAI-ARIA is awesome. The whole web stack is awesome.

I feel that all the negative sentiment around it is just because we cannot fathom how much worse it could have been had the HTML5 effort never happened.

> Actually there was. My web apps can be used in Windows, Linux, Mac, Android, iOS, Meta Horizon OS, etc. thanks to it being a standard that is more or less not controlled or gatekept by a single entity (browser monoculture aside). Java applets died because of it. > > Thing is, the Web platform is what won, and for good reasons. GTK, Java Swing, and other supposedly multiplatform toolkits did not lose just because -- they lost because the Web is objectively better.

To be honest I consider Java Swing better than current "fancy web UI". At least it's more consistent and at least try to match the OS... I loath the "creative bunch" that tries to re-invent the wheel and be all flashy and whatnot.

Every app should try to match to the best possible way native OS. Yes, it's not possible 100% of the way but it would go a long way.

Currently we live in a world led by brainded bunch of "let's care about brand" and try to have same UI on all platforms as if users were switching constantly between windows/mac/linux or between iphone/android... no, they don't. At least in the mobile space they do try to be more native-looking and follow the theme but it's not all that great either.

Also. Java/Swing loose (especially on the desktop) because it was slow at the time and wasn't open like "web". Besides learning curve for the web was easier (hey, you can open web console, write `alert('bam!')` and it DOES stuff, wild!... and then it went downhill from there...

> I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless.

The sectioning algorithm proposed by early iterations of HTML5 mostly solved this and it’s a great shame browsers didn’t implement support for it.

I'm fine with it failing. I think in practice developers would have fucked up regularly so the hierarchy still wouldn't match the content.

I have used Linear on a couple of my hobby projects and it's a great tool to quickly capture features and bugs.

My one gripe about the new website (and it's something I notice many projects stumble at) is that the written copy fails to explain what the product actually is. "A better way to build products", "the new standard for software development", "a tool to remove barriers" -- this tells me nothing, unlike a simple "it's an issue tracker bro" would.

I thought the fact that it was an issue tracker was self evident from the first picture on the page.

Show don't tell!

I'm sure the visually impaired users appreciate that a lot.

"Show, don't tell" is good advice for creative writing, which this website isn't. As a potential customer, it shouldn't be my job to cut through the marketing fluff to figure out if a product is something that is relevant to me.

This buzzword-driven style of writing, which has infected many a software project in recent years, is a pure triumph of form over function. Maybe it is necessary to appeal to the CTO types of the industry, but as a simple developer I do find it confusing and frankly repulsive.

I immediately scroll down to a picture/video. If you don't show me something I am gone. The Linear home page is incredible in my eyes. Just as a visually impaired user might not like pictures, a dyslexic person might not like text. Just another perspective for ya.

Possibly the marketing gang writing copy about ‘benefits’ instead of features? It’s supposed to help drive conversion.