Use the Platform

Use the Platform

We discuss what it means to use the web platform, and how that helps improve the user and developer experience in Elm apps.

PublishedApril 25, 2022

Episode#55

Alex Russell's post Platform Adjacency Theory
VoiceOver rotor utility
Use semantic HTML to improve screen reader experiences
Forms - use onsubmit with a form to get nice keyboard handling and screen reader accessibility
datetime-local <input> tags
MDN docs for sending form data
HTMHell (examples of non-standard HTML from the wild and why it matters)
Dillon's Use the Platform blog post

Transcript

And what are we talking about today?

Today we're talking about using the platform.

Ah, I love this one.

Use the platform.

So, yeah, what do we mean by use the platform?

Yeah, it's a sense that I've been hearing a lot

in the web development ring.

Sounds very old school.

It's not like the hedgehog, to be honest, rings.

But yeah, using the platform,

it's something we often hear about,

but I think it's a bit undefined,

at least it is still to me.

So hopefully I will learn more today.

So, yeah, what do we mean when we say use the platform?

Like, first of all, what is considered to be the platform?

Right, right, good question.

And I think that answer might be surprisingly deep

So the deep web?

Because the web is, in a way,

something that we move away from more and more

as we've been replacing some of the functionality

in the web with JavaScript.

And I think there's more of a move back to

rather than replacing web functionality

and reinventing the wheel,

but leverage the existing functionality where possible.

And it turns out there's some...

There are a lot of benefits to that approach.

And I've got to say,

my development career started out doing Rails development.

And I think I thought of myself a lot more in those days

as somebody who...

I thought of myself more as a backend developer in those days

because you work with data modeling

with building APIs and business logic

and things like that.

That's how I tended to think of myself

because I'm like, that's this nice, clean stuff,

the sort of front end part.

Making things look good.

Yeah, like I never...

That was never my forte,

and it was never the part that felt exciting to me.

The part that felt exciting was,

let's do test driven development

with tested business logic

and iterate on it quickly and things like that.

And the web part almost felt like an afterthought

in my early career.

Then when I was doing more front end development

and Elm development,

I thought of myself more maybe like a front end developer.

And actually Elm Pages has really made me think of myself

a lot more as a web developer.

And that's been a cool shift.

I think to a certain extent,

I've learned a lot about these kind of web primitives

that we're given

and how to use them as much as possible

and think more deeply about what they mean.

And even when I'm not building with Elm Pages,

it makes me think more about

how to leverage those primitives.

So there's one thing that I want to clear up first.

So you mentioned that the platform is the web.

The way that I think I understood it was,

it was more meant like the platform is the browser

because the web is a thing, sure,

that I would actually have a hard time defining.

If you want to do that, go ahead.

But it's the browsers that give you a lot of things for free

or that do a lot of things for you,

which I think is the point of the sentence slogan.

This is very good distinction.

So let's break that down.

So the browser versus the web.

What is the browser doing when it displays a page?

It's making an HTTP request, and that's part of the web.

And what if it gets a 404, or if it does a redirect,

or if it chooses to cache a certain resource,

or if it preloads a resource,

or if it's doing that with a CDN or a web server,

it's taking these headers

that the web server is sending back.

There's the server side and the front end side.

That's one piece.

And those are both part of web standards

because the server is communicating with the browser

through these web standards.

So that's one piece.

Another piece is that, I mean,

you can interact with APIs through different services.

You could have a voice assistant, for example,

consuming your site.

I guess that's why I look at it as a little bit broader

than just the browser.

But the browser is a huge part of that

and is very emblematic of the whole

use the platform and these web standards.

So is the platform more the web standards?

Use the web standards should be the episode's title?

Yes, I think you put your finger on it.

It is exactly web standards, yes.

So I've been thinking about this more broadly

and I think it matters.

And to me, I think the bottom line is

that it matters because conventions matter.

So web standards, conventions, they're sort of related.

Web standards matter because we build tools

on these conventions and standards.

Do you actually know the difference

between a convention and standards?

It's very pleasant to me.

I mean, web standards are a thing.

And it says exactly what the handshake should be

for opening up a socket connection.

And it says what is valid HTML and what's invalid HTML,

which HTML elements need a closing tag

and which ones should not have a closing tag

and strange things like this.

And sometimes conventions can even break those standards

and then the standards have to formalize those conventions.

So the conventions are the nonwritten ones.

Standards are the written ones

and conventions are what people do in practice, I guess.

Yes, I would say.

Hopefully they're the same.

Right, exactly.

And the web is all about those conventions.

And I mean, it's this strange thing

where you're building for multiple consumers.

And I guess that's one of the really interesting things

about building for this nebulous platform, right?

It could be a voice assistant,

it could be a device that doesn't exist yet,

it could be somebody using a screen reader.

It could be curl.

Exactly, exactly.

And that's all web, that's all the platform.

So yeah, conventions matter.

And another thing that I think matters with conventions

is just what users expect.

If you go to a website,

there are certain things you expect in the experience.

And it takes you to a page,

you click the back button,

and it takes you to the page you were at before.

And you can break that convention.

And to do that, in a certain sense,

you're going against the grain to do that,

but there are plenty of ways to do that type of thing

where you break users expectations.

What I feel is, my understanding is that

we are talking about this more and more

because people have been accustomed

or they have been breaking those standards and conventions

more and more by doing things by hand.

Is that your impression as well?

Yes, I think you're right.

I think that the web was basically built

with this idea of structured markup and links.

It's basically the web.

That's why it's called the web, I think,

is because you have these things interweaved

with this fundamental tool of the web.

And it was like a document delivery platform.

And then you get these things added on,

you get CSS to style the web.

That vision evolves.

I think it was originally thought of as something

that users could bring their own CSS,

and that isn't really a common practice.

Because who wants to use an application

and running it themselves?

I don't want to go to YouTube

and then have a very ugly page,

and therefore I have to style it myself.

No, that sounds terrible.

It's nice to be able to customize things, but yeah.

I guess, to a certain extent,

that speaks to how things have evolved.

Because in the early days,

there were these simple tags,

and bold, and whatever, flash,

whatever those fun early web 1.0 tags were

that we've lost nowadays,

the blink tags and stuff.

In those simpler times,

you have these primitives that you use,

and you style them.

But now it's so much more sophisticated

what we express.

And the semantic HTML we have

is doing GitDiffs in GitHub.

If someone uses a tab,

then you can choose how to render it

as two spaces, four spaces, eight spaces,

if you're weird.

Yeah, things were simpler then.

There was less expressive power.

There was less to express.

People weren't really building apps.

They were basically sharing documents.

They were sharing articles

and tables of contents and things like that.

It makes a lot of sense

that you style your browser the way you want.

So it's basically,

I'm not styling this website.

I'm styling whatever the documents I'm getting.

Which you can still do to some extent

with the browser settings.

But CSS has taken a life on its own.

Right, you could say,

this is my preferred font.

This is my preferred font size.

This is how big I like heading 1s

and heading 2s.

The divs would have seemed incomprehensible

in the early days of Web 1.0.

And nowadays, it's like,

yeah, I'm not surprised.

That makes sense.

Yeah, so the vision of what the web does has evolved.

And I think that the platform,

there's this sort of back and forth

about reaching the boundaries

of what the platform can do.

And then it catches up

and you try to standardize that

and you try to provide new primitives

to build in these new features

that were at the bleeding edge before.

I mean, jQuery is the classic example

that you're starting to add dynamism into web pages

and you have all these utilities

to go find an element on the page

and these patterns emerge.

this seems to be a generally agreed upon convention

of how people are building websites.

It seems to be a good idea.

It seems to be a good practice

that we have some common patterns for now.

Let's build that into the platform.

So it's always going back and forth.

And I think what's happened is that

single page apps and JavaScript heavy applications,

we were pushing the boundary

and so we sort of strayed away

from the web platform a little

because it couldn't,

I mean, I remember the early days

when you couldn't do push navigation

and you had to use hashes in your URLs

because the browser would ignore those.

Otherwise, the browser would try

to actually do a quote unquote real page load

to load a document when you change the URL.

That was like a built in assumption

that the derivatives had to be built

into the platform to support that.

So it makes sense.

We've been ahead of what the platform could do.

But then when the platform catches up

and it says, okay, I've solved these problems,

I've accounted for these use cases,

then we have to say, okay,

now we can start using the platform again.

And I think that that's sort of where we've found ourselves

at this point in time.

Yeah, but you still need to support IE8 or 6.

The very interesting thing about our time, isn't it?

Is that, I mean, I think this year, IE11 will officially

drop support permanently once and for all.

I thought it was already the case,

but yeah, soon or let's check it.

Internet Explorer 11 is going end of life

on June 15th, 2022,

meaning that for most Windows versions

using Internet Explorer won't be an option anymore.

I feel like there was maybe like a soft end of life date

and now that's the hard deadline.

I don't know exactly what the nuances of that were,

but enough people have been able to make the case.

I mean, for sure IE11 is no longer support

getting active development,

even for I think security issues,

they don't get active development, I believe.

But either way, it's fully end of life in June this year.

That's a big deal as far as using the platform goes

because we can assume that we have some of these

built in platform features, more of them.

Now that's of course a gray area to some extent

because you do have different devices

that might be running an old version of iOS

or an old Chromebook or things like that

that can't update to.

So it's not as simple as Evergreen,

but still it's a big step.

I mean, the web, the browser and web standards.

Do you know of any other platform?

Or is web standards just a weird entity

where we have something that we can rely on?

For instance, if you develop games in Unity,

can you call that a platform?

I think you can.

I think you can call to the same extent.

It's a platform.

There's a platform for development.

There are certain standards and APIs.

I mean, it is interesting because the web platform

is this interesting space where you put things out there

and many different devices

in many different modalities can consume it.

And you don't know what version.

Like somebody could navigate to a website

from an Xbox or a watch or a screen reader

or a voice assistant

or they could be scraping your page.

They could be viewing it through a Twitter

social image preview, scraping the markup.

There are so many different ways that it could be consumed

and not to mention SpiderMonkey versus WebKit, et cetera.

And you have to build it in a way

where you can support all those

things like CSS and that sort of thing

because, well, that's...

I mean, those were...

I think that browser vendors realized

that that was a bad direction

because people ended up permanently relying on those

and building as if they're targeting different platforms.

Yeah, which is not what you want.

Right. You want to move towards a single platform

and try to build a unified experience as much as possible.

In that sense, it is unique.

Of course, you can build an iOS application

for different sizes of device

and somebody could run it on an M1 Mac or whatever.

But yeah, I mean, the web is probably the largest

and most diverse platform.

I think that's fair to say.

Especially since I have trouble finding other platforms.

And especially because, you know,

you're using the web platform kind of.

So, like, conventions matter.

Conventions matter for user experience, you know,

from somebody who doesn't use a computer very much,

but they sort of have their workflow

and they expect the back button to do something

or they expect to bookmark something

and be able to get to the same place.

Conventions matter for those types of users.

Conventions matter for users who, you know,

have certain constraints in how they use the device,

like, you know, if they have restricted motion

and they need to use keyboard only navigation

or if you're a power user

and use keyboard only navigation.

These are all places

where conventions really matter.

And if these focus outlines that you get

aren't showing up to show you where your focus is,

that breaks their expectations.

And that might break the way

that they're expecting to use the platform.

So, when you go and you pave a new path

that doesn't follow the platform,

then to me, the bottom line is

you take responsibility for making sure

that all these different use cases are handled.

And that's a big responsibility.

If you can avoid it,

it's better to just rely on the platform

to do those things,

and that's what the platform does now.

It's what the platform will do in the future, too.

If it consumes it in a particular way in the future,

you have to keep up with that

and make sure that your application supports that.

But isn't using the platform

premature abstraction or optimization in that case?

I don't see it that way.

using the platform.

I think one of the classic examples is,

imagine that you didn't have any links on your page.

And, okay, so now you have something in your model

that says what page you're on.

Let's not call it a URL.

Let's just call it a page

because we're not using the platform,

so we don't have a concept of URLs.

And we have onclick handlers for these things.

Let's maybe underline them

or underline them on hover or something like that

because that looks like something you could click to,

but it's not an anchor tag.

Maybe it's a div.

And it has an onclick.

It changes the page content you're viewing.

Well, in an Elm application, that's a lot harder.

That's a lot more work, right?

If you did a desktop application,

you have to redo all of those manually,

which is, I'm guessing, part of the reason

why frameworks or platforms, I guess,

like Electron, had so much uses.

Because you get a lot of those things for free.

The downside is that it's running

a very performance heavy thing under the hood,

and you get a lot of those things for free as a developer,

and the experience for the user is much nicer.

Electron is such an interesting topic

for use the platform because in a certain sense,

it's saying, hey, we've got this platform.

Let's just bundle it up for you.

In another sense, it's completely eschewing the platform

because it's saying, well, we have progressive web apps,

but let's just do a fork of Chrome

and install and bundle with every application you build,

and it can consume all this memory.

There are pros and cons.

In one sense, it is embracing the platform.

In another sense, it is really not embracing

this primitive of progressive web apps.

I definitely have mixed feelings about that one.

I wish that we just had more device vendors

embracing progressive web apps.

There are definitely reasons why a native application

is the right tool for certain use cases.

How would a progressive web app

replace a desktop application, just to clarify?

Well, if it's an Electron application that doesn't...

I mean, there are so many things

that the platform of progressive web applications provides.

Of course, it's varying support in different platforms,

but access to device sensors

and being able to sync data when you come online,

being able to handle offline support,

so having cached resources.

You get those with progressive web apps,

but not with Electron?

When I think about the web platform,

one of the things that's really unique about it

is you go to a URL and it loads an application.

It streams in an application to your device.

Whatever device you're on,

you can probably stream a web application to it,

which is pretty amazing.

That's not how Electron works.

Yeah, because it also streams

in a very lightweight manner.

Which can be very big still,

but a lot less than shipping a native desktop app

which you need to install,

which you need to go through.

Install Wizard, maybe even.

The application delivery mechanism is amazing.

Also, if you want to share...

If I'm going to a concert and I say,

oh, you're going to this concert,

how do I find out more?

I can't copy an Electron app and send it to them,

but I can copy the URL I'm on,

on my browser or on my phone,

hit share, send it to them in a message,

and now they're looking at the same thing I was looking at

on whatever device they happen to be at.

That's the web platform, and it's cool.

Now, if that's a conference website

or a news source or something

and you want to read more about it

and you want it to still be there,

if you load that conference program on your phone

and it's a progressive web app,

then you're looking at the conference program.

It loads the page as soon as it can,

but then it starts installing

the service worker in the background

and it starts caching these assets

so it has the program available for you

on your device offline, and then you go into airplane mode,

and Electron application can't do that.

It's a streaming application and document platform,

which is really amazing.

I think that we should embrace that more

because it's a really unique thing about the web.

And now it doesn't feel like it's the web

because it's for desktop.

Because under the hood, it's using a browser.

That's why it's working the way it is.

Well, that is the interesting thing, isn't it?

What does it mean to use the platform?

But it is this set of standards and conventions

that we can build on top of,

and something that's not a browser

could hook into those same standards and say,

oh, there's a concept of a service worker?

I'm going to use that,

even though I'm not a web browser.

I don't know what...

It's a voice assistant,

and you go on the airplane

and you say, hey, voice assistant,

what's in the conference tomorrow?

What's the keynote conference tomorrow morning?

And it can tell you, maybe.

And it could use the service worker to do that,

or whatever, even though it's not a browser.

So that's the weird thing about the platform

is you're kind of building

according to these standards and conventions

so that different devices and tools

can leverage those things

and it kind of sounds like write once, run anywhere on Java.

Well, in a sense,

there are common elements there.

And I mean, Java failed to do that, right?

Java applets were a thing,

and it didn't really take off.

I think the web is just a very powerful idea,

and of course it's imperfect.

It's trying to build this very ambitious

and huge in scope thing that's constantly evolving,

and the technology is changing very quickly,

and it has to remain backwards compatible.

I think given all of those constraints,

it's actually an amazingly successful platform.

Yeah, like all the critiques that we can give

to any of the browsers,

like even Internet Explorer, the old versions,

it's still a very complex piece of software

for good and bad.

They're all amazing technologies.

I think the more we can embrace it, the better,

especially nowadays.

You know, there's a really interesting article,

I'll link to it, by Alex Russell,

who spearheaded a lot of the Progressive Web App stuff

and has a lot of really interesting thoughts

about the web in really broad terms.

He's really worth following,

and he has an article where he talks about

the idea of platforms providing features

and then not being at parity with the performance

and feature set of native platforms,

but then it tries to, then it catches up.

So you've got this constant back and forth

where the web platform is never going to be ahead

of these native platforms,

but you want to catch up over time.

at the end of the day,

it's really about conventions.

And when I think about...

So the reason why it matters is because

you get a lot of things for free,

and all those things that are for free

are things that people expect

because they have been there in other websites,

and most of the websites, actually, right?

So when I try to break it down,

I kind of thought of a few areas

that are pretty obvious.

One is accessibility.

If you try to reinvent the wheel

rather than embracing the platform,

then accessibility devices, screen readers,

or people navigating websites

in ways that aren't the same as how you navigate them

are not going to be able to do so easily or at all.

For example, if you don't use H1, H2s,

or if you have forms that aren't actually forms,

they're just hanging inputs floating in the ether,

or if you don't use actual links,

but you use divs with onclick handlers,

those have serious accessibility implications.

So accessibility is one area.

I almost feel like it's a bit weird for accessibility

because you have...

So semantic HTML that gives you a lot of things for free

and for interaction.

And at the same time,

you also have APIs through ARIA

to add the things that you didn't add

through non semantic HTML.

So you can make a div with an onclick event handler

and then say that its role is a button.

So you have two ways of doing it.

One is a lot more complex than the other, definitely.

But I don't know why both things exist.

I'm sure there are valid use cases

where you can't use ARIA

or where ARIA adds more information.

And see, that's sort of where I've personally arrived

The web is massive.

We can't all be experts about every single detail.

But there are some basic rules of thumb that we can follow

that are going to make our lives easier

and the lives of our users easier.

And so do I know every single detail

of ARIA accessibilities and screen reader experiences

and the cases when it makes sense to use ARIA

and it doesn't make sense to use ARIA

and it doesn't make sense to use ARIA.

Does anyone else make sense?

No, I'm not an expert.

And there's a lot I don't know about that.

But I know that if I can use a link, I may as well.

And I know that if I can use a form, I may as well.

I also know that if I pull up a, you know,

if I pull up voiceover, the built in screen reader on Mac,

which is something that many users on Mac use,

is the rotary, which is something you go

and you're in screen reader,

you can do control option U and it pulls up this rotary.

And you can hit the arrow keys to navigate left to right

between these different panes of like the hierarchy

of H1, H2, H3s.

You can see links, you can see forms,

you can see lists, you can see tables.

So these things matter to screen reader users.

And knowing that gets me a lot of the way there

to a baseline of using the platform

and building more accessibility friendly experiences.

It doesn't get me all the way there,

and I have to rely on a lot of Googling

and knowledge from other people and things like that

but that gets me 90% of the way there,

just knowing that if a screen reader user

is looking at a site and if they're looking at a table,

it will tell them which column they're under

and which row they're under.

And it knows what the name of the column is.

And it can say you're in row three of the country column.

And if I'm looking at a link,

then if you pull up the rotary

and you look at the links on the page,

then it will read out link, click here,

link, click here, link, click here,

as opposed to link, buy your copy of my book title

or whatever, right?

Those are just like,

that's not that much knowledge.

And I think that as people building for the web platform,

we can get so much mileage

and also just saying,

I know that if I'm making it overly complex

and relying on building these things myself

rather than using the built in semantic HTML

and things like that,

if you just know,

okay, sometimes I need to do that,

sometimes it's the right choice to do that,

but it should probably be my last resort

and I shouldn't make that choice lightly.

I should make that choice knowing

that that's the harder path

So if I'm going to do a link on a web page,

I don't have to do much research

to know if that's a good idea.

But if I don't do a link

and I'm navigating to a different page

through that interaction,

I should probably think

through the implications of that.

So if you redo your link through a div,

you probably need to implement the fact

if you do control or command click.

You have to have the color change

when you hover it.

You have to make it selectable

with the keyboard, tabbable.

You have to make it keyboard focusable.

And plenty of other things.

Which the deeper you go,

the harder it seems to do manually, right?

You have to click the link,

and on space, you have to scroll the page.

Whereas with buttons,

if you hit space,

you click the link.

You click the button.

And also, if you right click the link,

then you should be able to copy

whatever URL it is linking to.

I have no clue how to do myself.

I don't even know if that's possible.

If you go to the left of most browsers,

it will show the URL,

so you know what you're going to do.

Which actually,

I use that feature a lot.

I just love when it says JavaScript colon void.

This might seem like a bit of a straw man,

like come on, divs instead of links.

But actually, it's extremely common.

It happens so much on Twitter

that I'll try to navigate somewhere.

I want to make sure that I don't miss

any good context from something I'm reading,

and I go back to it.

I open a bunch of tabs.

I'm sure I'm not the only one out there.

And so you notice when you're middle clicking

to open a new tab,

that's another thing that happens

when you click on links.

Middle click as well.

Middle click a link,

does it open a new tab

or does it just do nothing?

And it's so annoying

because it does the...

The normal navigation?

The normal navigation.

Oh, that's the worst.

That's even worse.

That's even worse than doing nothing.

If it does nothing,

at least you can mentally prepare

for what's about to happen.

But if it just follows a link,

then you're like,

no, I lost all my progress.

And this is actually extremely common.

So this is not a straw man.

This is, I mean,

this happens to me on Twitter quite frequently.

So it matters and it happens.

so the key areas that I think about

for why it matters, accessibility.

How many more are they?

I came up with four.

Okay, let's go to number two.

Let me know if you think of any others.

Performance, user experience, and simplicity.

So performance,

the platform can do,

if you use CSS,

platforms can make assumptions

about how you use CSS,

and they can optimize for that.

If you use image source sets,

then the platform can give you

performance benefits for that, for example.

But it could also give you

a better user experience.

So there are many reasons

to use the platform, right?

But performance is one key thing.

So if you use the standard behavior,

if you try to re implement the link

like we just mentioned,

there's a lot of code

that you're going to send over the wire,

which would be exactly

one character otherwise.

That's a great point.

Not to mention that it makes

your code simpler, right?

And these things all kind of

make a better user experience.

There are so many ways

it can affect user experience, right?

if you have flashes of unstyled content,

if you're using the platform,

you can try to use media queries

to make things responsive.

I've ranted about how I don't like

managing responsiveness

through my model in Elm

because number one,

it's kind of unresponsive content

because, but if it was a media query,

then it's not stateful

and the platform can optimize for it

and it's going to lead

to a better user experience, I think.

Yeah, I do feel a bit conflictive

with the media queries.

So, but maybe it's just

I have a gap in my understanding.

So if you want to do

a mobile friendly application website,

what I tend to see is

people render a lot of HTML

and then depending on the media query

or depending on the size,

they have their media query

disable or hide elements.

But that means that all the elements

are present in the DOM, right?

So you have hundreds of DOM nodes

that are not used

and affecting the browser's computations.

So I feel like performance wise,

that is probably not great.

If you do it in Elm,

then also it goes through

the virtual DOM diffing.

So I don't know

what the performance implication

I'm guessing it's not that bad

because people tend to use it,

but I'd love your opinion on that.

That's an interesting one.

Yeah, I mean, if you have

a screen based on the responsive view you're in.

Well, maybe you have a table

that you show by default on desktop sizes

you have to click somewhere

for that table to show up.

That's interesting.

Yeah, I would say,

you're using the desktop experience,

but on mobile you have to click

something to show it.

my first inclination would be,

well, if the number of HTML nodes

is not a problem on desktop,

probably not going to be

a problem on mobile either,

with some of them being hidden

and it's probably not going to be

the performance bottleneck.

So I don't know,

I wouldn't think of that as a concern

unless I have a specific reason to.

If a user is using this on desktop or on mobile,

if they have to go to

mobile.mysite.com versus mysite.com,

am I serving them two completely different,

unfamiliar experiences?

That would be my bigger concern,

and I would feel more confident

if I'm using a few media queries

to have something be a row versus a column

based on the platform and a few things like that.

I would be more confident about delivering

a similar familiar experience

if I was doing that approach

than if I was serving up

two essentially different sites.

Definitely, yeah.

Or if I had a lot of logic

in my application code for that.

Yeah, I don't know if what I mentioned

is a performance bottleneck.

I'm guessing it isn't.

What you do get from using media queries

is function calls for updates.

You get a lot less cycles

if you listen to the size of the window.

That's something that will be a lot faster

and a lot more responsive.

That's the thing.

I don't particularly feel confident

about the performance

if I'm having an on hover highlight

that comes from Elm.

I don't trust myself to build that experience

in a reliable way.

I feel like it's probably going to be janky

in some way or not performant.

It's just like if I can do it with CSS,

I would prefer that.

Something I've been mulling over recently

and I haven't come to a conclusion yet,

it's sort of a forming or exploring idea

in my mind right now,

should use the platform push me towards

more of a vanilla CSS experience?

Of course, there are pros and cons.

We love our type safety in Elm.

Like Elm Tailwind modules, for example.

It's really nice being able to just use breakpoints

and things defined with Elm CSS

and then add your own custom Elm CSS styles

into very nice developer experience.

I think it's a pretty good user experience.

I haven't really noticed performance issues.

Although it does increase your bundle size

of your JavaScript, your compiled Elm.

And per byte, I think that you're going to have

more of a performance burden per byte of JavaScript code

compared to per byte of CSS in general.

I probably agree with that CSS will be lighter.

So doing CSS inline versus using CSS files,

both are supported by the browser.

So both are using the platform, right?

I mean, putting everything into JavaScript

in a certain sense is not embracing the platform, right?

Because the platform is like,

you can have style sheets, you can have...

JavaScript is a tool for enhancing experiences,

not creating experiences from scratch, right?

I think that's the gist of my take on use the platform.

But JavaScript is a web standard.

Therefore, anything I write in JavaScript

is using the platform.

Yeah, right, exactly.

You found the loophole.

Yeah, like if I open an HTML tag and I don't close it,

the browser support it, I'm using the platform.

And actually, this does get to an interesting case

of use the platform.

So there are parts of the platform

that are not necessarily going to give you

the most customizability

or allow you to create rich user experiences.

So that's a part of the platform, technically,

although they're actually trying to remove it.

Apparently, it's used by scammers to make it look like

you're getting an official system notification

when they screen share with people.

I think that's the reason they're trying to remove it.

It also gives a wonderful user experience.

Precisely, right?

Pretty rarely, right?

So that's one where you probably want to throw it out

and say, the platform doesn't really give me

a good building block in this case,

so I'm going to need to create my own, right?

And no, you could imagine a world where that's different,

but that's the platform primitive that we're given.

So to a certain extent,

you can't just blindly use the platform.

It does take a little bit of experimentation

and experience to figure out

how to provide good experiences

and are going to be able to give you the user experience

you want to try to build.

Like, you know, like alerts.

Don't alerts block the main thread

and strange things like that, too?

It probably does, yeah.

I think they might.

I think about it, yeah.

So it's pretty odd.

Somehow, it's just this thing that exists in the platform

really as a debugging tool and nothing more.

You could imagine a world

where that is the best practice,

that we have an alert primitive in the platform

that gives us a really nice way to do things.

Or you have to enable a flag in your browser

to enable the alert feature, like in debugging mode,

just like with Elm, you have a debug.to do

and debug.log only for development purposes.

Actually, mobile phones, or at least Android,

You have to do something to get it into, like, developer modes,

something quite...

that you wouldn't find on your own, I think.

I think you have to go to settings and go to about

and press it like 10 times or something.

Oh, okay. Interesting.

It was something like that last time.

As far as I can remember.

By default, I wonder.

I don't know. I haven't tried it. It's enough.

But that is, like, the web platform is this massive, you know,

hodgepodge, and everything is backwards compatible.

And so sometimes, you know, early days of the web,

when JavaScript was, you know, just emerging,

you throw it in there,

you don't give much thought to the implications of it,

and then you can't really change it

because it has to say backwards compatible forever, ish.

Except for alerts.

Like, we maintain everything backwards compatible

except alerts because no one likes them.

Which, in a way, makes sense.

Like, if no one likes something, not even the users,

then, yeah, maybe you want to break the website.

Yeah, it's a weird line.

I think the people who run CodePen and CodeSandbox

like it because people use it a lot there

when they're learning the code.

So they're unhappy about that.

How will we test cross site scripting injections?

We have to do three alerts.

It is actually quite useful to test that.

Yeah, so you've got to know the rough edges.

You have to, you know, I mean,

there's a lot of knowledge that you need.

But hopefully having certain rules with them makes it easier.

And I'm going to go ahead and say that links

are a very important part of the web.

I'm also going to put a stake in the ground

and say that forms are an important part of the web

and one that in the frontend space we've forgotten about

and in the Elm world I think we've forgotten about.

So let's talk about forms.

Form over function.

Instead of defining a JavaScript function,

you should just write a form.

It was a bad pun.

I had to get one out there.

But you didn't say no pun intended.

Well, you would have seen right through it.

No, because I didn't get it.

Yeah, so I'm one of those people who don't use forms

and very likely because I misunderstand them.

It's a poor form you're in.

That one I got.

So the way I learned forms back in the day

when I studied computer science

and the basics of web applications,

you have a form and you have a submit action

or an action which is usually submitting something to a web server,

making a post request and sending the data from the form.

And I find that to be useful for static websites

like just plain HTML slash CSS,

but I don't see how it applies

for when you want more interaction

and when you want to do something else

and submitting, making a post request to something else.

Something somewhere.

Yeah, and to a certain extent,

I think this is again like we were talking about

when you just sort of throw away the platform

because it doesn't do what you need it to

and then you build it from scratch

because you want to build client validation

and things like that and it doesn't support it.

I think we're getting back to saying,

okay, actually maybe we can use forms a little bit more

even if let's say that your submit actions

and those things just are disabled,

they don't work, they don't do anything.

Still, if you have a form wrapping your input elements,

screen readers care about that.

Also, you know what else cares about that?

You're in the last field of the form,

you hit enter and it's going to do the on submit action.

Well, that's when I would do it

because I'm done with the form and I'm ready to submit it.

Wherever you are in the form.

These are relevant things

whether or not you're handling the on submit with JavaScript.

I think that's the first point.

Also, if you embrace some of these things.

Now again, we were talking about the rough edges

or things that aren't quite usable and use the platform.

Let me clarify.

You can just use unsubmit,

html.events.onsubmit

just like you would do with any other form.

Any other elements.

It wouldn't necessarily want to make an action

to send something to.

It's going to prevent default on that

when you put an on submit on the form.

Basically, what I'm suggesting to somebody who says,

I don't want a real form post to happen,

but I want to make an accessible user experience

and something that's intuitive for keyboard users

and things like that.

What I'm suggesting is

just wrap your input fields in a form always

and add an on submit handler

instead of a button on click

because that button on click

isn't going to get triggered if you do on enter.

It's going to get triggered on every field.

What else are you missing there?

It happens so often that I'm filling out forms

and I use some auto complete

to fill in an address or credit card or something.

Then it says, invalid, please enter something.

I'm like, really?

I'm so surprised that I entered something

with an auto fill.

There are so many,

it's just so widespread that

people are trying to outsmart the platform.

They're trying to say,

you cannot copy paste into this field.

It's like, what?

You can't copy paste your password into a field.

Why can't I do that?

What if I'm using a password manager

and that's my workflow for whatever reason?

When it says reenter email address to confirm it,

you enter it once,

you can paste your email address.

The second one, you have to type it manually to be safe.

Don't tell me how to live my life.

Yeah, I feel like I will do a better job by pasting.

There's so many things like this

or disabling right click or just don't do that.

The passwords is I think my pet peeve.

I'm using a Mac at work

and it doesn't have an option to display the password that you typed.

Whereas in other platform,

at least my personal Linux laptop,

you usually have a button to show the contents.

I found that so annoying

because especially on a Mac,

it's like how do I do a backslash?

Now everybody knows your password.

I didn't say I didn't change it.

The keyboard doesn't show you what to do

so you have to play with it.

Since you cannot see the character that you just typed,

you have to try it out.

When you're trying to log in,

you can type things in.

You're really stuck.

Especially with the fact that I usually have a French keyboard.

Things are not always as you expect.

For instance, if you play some video games,

sometimes the keyboard just assumes that you're using QWERTY,

I'm using a Nozerti.

Sometimes I just even remap the keyboard to be like,

this is QWERTY.

I'm not moving a character.

Keyboards, keys are annoying sometimes.

This is why conventions matter.

Anytime you assume that you have a better way

to solve a problem than the standard one,

again, the onus is on you

to then think through every possible use case.

Whereas if you use the standard,

you can change the tab.

You don't have to think through every single thing

a link has to do.

You can just write a link and that's fine.

And then there's also actively disabling things

that you get for free.

I think I mentioned it when we talked about accessibility

where I was working on an application,

and we had a form,

and the submit button had the focus ring,

which my manager didn't like.

And I had to actively remove it.

And yeah, in hindsight,

I should have just refused because there's good reasons

for it to be there.

Yeah, that should be raising red flags

when we're trying to disable something.

We should at least say, why is this there?

Yeah, we should at least understand

what is the benefit of this,

which I think we understood,

and we should have caved in.

I wouldn't cave in today, Dillon.

I wouldn't today.

I am a grown man now.

Yeah, I think that's quite ubiquitous.

So do you see any use cases

for not using the platform?

I mean, I think, again,

knowing through experience

these sort of half baked parts of the platform

provide the user experiences we need,

there are things like that, right?

Like the platform provides this alert primitive.

You probably shouldn't use it.

The platform gives us input type equals date time.

I think that's the right name for it.

But it's not quite ready for primetime.

It's not great, right?

So, I mean, it's okay.

It's like a good starting point,

but you'll probably outgrow it

because you want to create

also like drop downs, which are,

you have the select,

but it doesn't have a filtering,

like an input that you can type things in.

Right. Well, it has some filtering.

Well, not exactly filtering,

but it will go to an entry

matching what you type.

But it's, yeah, it is not...

There's some missing base UI primitives.

There absolutely is.

You might want to create your own building block.

But in those cases,

I think my only advice is to not take that lightly

and to understand that you're now handing off

that responsibility from the platform to yourself.

So if you can use some sort of community standard,

if there's some package that provides something like that,

or a web component,

or something that you can install

and they can run testing on it,

they can open issues,

they can put in pull requests,

or at least if it's like a company wide thing

that multiple teams use or something,

But just don't take it lightly.

That's my only suggestion there.

Yeah, because if you want to have

most of the same performance gain,

user experience, and accessibility,

you will need to do a lot of work.

So if someone did it already for you,

it's usually slightly not what you want.

But if you do use something that is popular,

then I guess it's more likely

that that would make it into the standard

rather than your nonstandard version.

Yeah, in Elm, I think we're a little bit,

like if you're trying to find

a really nice select component in React,

it's a million and a half.

There will be slightly not be what you want.

Probably, but at least you can forget

and it's probably going to be thinking

through a lot of these considerations,

although there are certain ways

that React doesn't use the platform

that are controversial to like artificial events

and things like that.

Synthetic events, that's the word exactly.

But even so, we have a harder time finding

date picker components in Elm.

But I mean, I think a web component can be

a really good fit for this kind of thing too,

especially because you probably want it

to have internal state that you don't care about

and you don't want to wire in.

Yeah, like I was thinking the same,

like even if you rewrite it yourself

and maybe you want to do it in Elm,

then you probably want to wrap it in a web component

so that you don't have to have lots of updates cycles,

use it as a stateful component.

Yeah, and if you use it as a web component,

then you can use it just like any other HTML tag

with regular event handlers.

Exactly, exactly.

It's simpler to use it

and you can create a robust user experience.

So I think one of the biggest use the platform

kind of, I guess, things that people miss

that I think is pretty low hanging fruit

If there's a window,

if there's a screen on your application

that you can get to that represents

like a meaningful resource you can view,

but the back button won't take you back and forth to it

or you can't share a link to it or bookmark it,

that's probably an opportunity to use the platform

and embrace URLs there.

I think that's pretty common

to just have that be

internal application state that you,

like even if you open a modal, that's fine.

Open a modal, you can change the URL

and then you hit the back button

and you close the modal

and like that's okay, right?

You can do that.

Yeah, I'm not sure about a modal,

but for the rest I definitely agree.

Well, let's say like it's a modal

and why shouldn't that be slash product slash new?

Oh yeah, okay, yeah.

And then if somebody in their workflow

goes and creates products,

every morning they go and create a product,

they can create a bookmark.

Now they can go create a new product,

go straight there, why not?

I usually go to create issues in GitHub

by typing slash new.

Right, so that's like the user convention

I think you could argue that that is potentially

going to make your Elm code cleaner

because now your model,

it's just a routing concern,

not a model concern.

We have to kind of manage this internal state,

am I viewing the new form or not?

And then you can also have

the same loading strategies,

whether the person directly went to that URL

or if they went to the different button click routes.

Right, exactly.

And if you're testing it,

you want to manually run through

and make sure it's working fine,

it's easier for you to test it.

It's just a good idea.

There's really not much downside to that.

Would you put everything in the URL?

If someone expands an accordion,

would you move it to the URL?

if they toggle the mobile menu?

No, I wouldn't put that in there.

If you're on Google Flights and you filter

and you say starting date and date

and destination and all these things,

you probably want to be able to copy paste that

into a new URL so you can slightly tweak it

if you're like me and you're obsessively opening

a million tabs or you want to share that link

or you want to do the same thing.

This is what the web platform gives us.

It gives us a way to have shareable resources,

It's actually really hard to recreate that

in different platforms, like native platforms.

They try, but the web is very good at that

and we should embrace that.

You can also use that for like pre filling forms.

Like if you do slash new for a GitHub issue,

you can just go to the URL to set the title

or the description and a tool could give you

like a pre created URL.

You just click on it and then it's already

the name of the issue and some description.

Or you have like a custom search in your search bar

that goes to use a search because you can tell it

and then you can search there from your search bar

Actually, we were talking about forms earlier

and the default method for forms is get.

You can do a get or a post.

Often people will think of forms as post,

but what if you do a search?

If you by default, if you have a form,

so let's say you have like a Elm package search

that could be a form and probably should be a form

for your Elm review.

And unfortunately, you're not going to see

the Elm review package in there

because you're going to see a million Elm review packages,

not JFM, Angles, Elm review.

But putting that aside.

You can scroll.

You can scroll down.

No, even further.

Yes, no, no, even further.

You will have search functionality in your browser.

But maybe that's not the best example

because you don't necessarily want to go to a new page.

But if there was a separate search page,

not an inline search,

then the form will by default, when you hit submit,

it will add the form field as a query parameter.

Does it add them or does it replace them?

Yes, so by default, a form will submit to the current URL

and by default, the HTTP method will be get.

You can override that by saying method equals post,

but by default, it's a get.

So let's say we're on the Elm package homepage

and we wrap that input for the search in a form.

And then we say input and we give it name equals q

is a common one for query.

And if you have a query and you don't have any

on submit handlers or anything,

then what it would do is it would load the current page

with q equals whatever you had in your form field.

So it will add query parameters

for every form field that you had

and do a get to the current page

and do a full page navigation.

But does it add them to the existing query parameters

or does it replace those?

Like if you already have a query parameter for like...

I guess you could encode the existing parameters already.

But I think it's good to be aware of these things

and like in the case of like a package search,

I actually think that would be one really nice thing

on the Elm package search site is if it supported,

if it changed a query parameter as you typed,

that would not be that difficult for it to manage that

and share the search results with someone.

And then you could register it as a custom search engine for...

And again, using the platform, right?

What is the platform? Is it the browser?

Well, it could be the browser navigation bar

that's adding in that query parameter

or it could be Alfred or some sort of app launcher

that you do a package search

and either query the results that way

or you could load the page when you search.

But yeah, I think it's really good to be aware

of what a form does, like what a vanilla form does.

And hopefully soon we'll talk about Elm Pages 3.0

which has this sort of full stack Elm story

where now this concept of doing a form post

actually becomes more meaningful

because you can do a real form post and handle it

and then respond from the server in Elm code

or to a get request with query parameters.

You've entirely spoiled the episode.

Or did I tease it? Stay tuned.

Yeah, so this philosophy, you know, like Remix.js

has been exploring this idea of progressive enhancement

in a really exciting way.

That's been a big inspiration for me

and I think it's really inspiring

in the ethos of the web development community these days.

And I think it is more,

people are starting to look at things more

as we're web developers, not front end developers,

JavaScript developers, Elm developers.

We're not back end developers

who can make something appear in a web browser.

Yeah, we have these web standards

that give us all these fun things to build with

and I think it's sort of like a whole other can of worms

that I'm sure we'll talk about a lot

when we get to Elm pages 3.0.

But I think there are a lot of benefits.

You're using the platform

and you can write simpler code.

And it's an exciting time to be a web developer, I think.

Just like back in 1998.

Was JavaScript around then?

When was JavaScript invented?

How did you commit that to memory?

Just like Java.

Well, did we miss anything?

I guess there are a few things

that we didn't hit on that are on my list.

So I'm sure we'll get into this

when we talk about Elm pages 3.0,

but HTTP status codes are part of the platform.

I think you embrace those.

And I think it's always frustrating.

If you've ever consumed an API

that's running on a 200,

possibly returning HTML with some error in it,

even though you sent a header

that said content type application JSON,

and you assume that that's an okay response,

but it's obviously an error, right?

Did you say GraphQL?

I think you said GraphQL there.

I didn't say GraphQL,

but that is an interesting case there, for sure.

The GraphQL, in a way, does go around

certain web standards, you could argue, but...

Because also, it is new, in a way.

Yeah, I guess whether it will do good

will be in how well it will be adopted

by browsers later.

Yeah, and there are certain standards to it.

And if, like, you could have...

Yeah, it is an interesting question.

Is it okay to have a 200 response with errors?

You could argue if your GraphQL schema

is describing the possible error states

that you could get, and you have to handle those.

That's actually a pretty good state of the world.

And especially if it's like,

this isn't something that fatal error on the server,

this is like an expected thing that can happen,

and you get back a user, and it's null.

And it's a good state, because it's a nullable field,

we didn't find the user.

That's, I would argue, a pretty good use of web standards,

even though it's not returning a 404.

In that context, I think that's appropriate.

Yeah, you still get a few of those.

Like, you still get 400s,

or if you have a bad request,

or an invalid GraphQL request.

But there's some cases where it should return

And to a certain extent,

it's like, use the platform well to describe what?

So in this case, the platform is telling you,

did you make a valid GraphQL request?

If you did, it's a 200.

It's a valid GraphQL request,

and I didn't find a user.

Is it a malformed request?

In the sense that this is not a valid GraphQL query.

So the server will respond and say, malformed request.

So you're using web standards just at a different level.

And I think that's appropriate.

But there are so many things

that I think can improve user experiences

and make it simpler to manage code.

I think people more and more are moving

towards using cookies to manage sessions,

because managing those types of things in JavaScript

can be really messy.

And I think that's a little bit more

and that these web standards exist.

And I think this opens up a whole new avenue

of using the platform.

Using the platform is not just about

what happens in the browser.

It's about the whole picture from request to response.

So yeah, it's an interesting time.

So are there any resources

we should leave people with before we go?

I've got a couple.

I should mention that, yeah.

Mozilla Developer Network,

great websites for any kind of information

about the web standards.

Really well done.

Yes, it's amazing.

And it's really good at providing

the relevant information,

not just bombarding you with every single detail,

but giving you little details

that are going to a particular page.

So yeah, look at the MDM docs for forms,

form submissions, inputs,

HTTP status codes, links.

Look at these things.

It's really interesting.

And the more you're looking at that,

that's a good sign that you're probably

doing a pretty good job using the platform, I think.

It's going to make you better at leveraging that.

A link should do this

when you click it with a middle click,

or it should show something when you do this.

I don't know if it...

That's a good question.

So on a related note,

there's a page that I find really amusing.

It's actually quite informative.

and it actually does a really good job

of showing what should a link do when you click it.

It shows examples of divs

that should be anchor tags and things like that.

And it walks through,

why is that a problem for screen reader users,

for keyboard users, that sort of thing.

It's really neat.

So that's worth perusing.

I'll also leave a link

to some voiceover resource

for getting your bearings

of what screen reader users see.

Yeah, and I also wrote a short post

about use the platform.

It's in my digital garden.

I'll probably keep it updated from time to time

with my latest thoughts on the topic.

Well, I think we've covered the platform

pretty well for now.

Yep, I hope that even though

this wasn't much Elm,

it will improve your Elm code.

We're going to get some state

out of your Elm code

and into the platform.

All right, well, Jeroen,

until next time.

Until next time.