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.
April 25, 2022


Hello, Jeroen.
Hello, Dillon.
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.
And web rings?
Web rings.
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
because it...
So the deep web?
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.
Only 10?
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.
And you say,
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, yeah.
So, yeah.
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.
I see it as...
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.
You click it.
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 so.
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.
So I think,
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,
you know what,
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
to take.
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
that you tab
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 yeah,
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.
Right, yes.
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?
Like using,
if you have flashes of unstyled content,
you can,
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 rendered,
not rendered,
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
of this is.
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
and in mobile,
you have to click somewhere
for that table to show up.
I see.
That's interesting.
Yeah, I would say,
I don't know,
you're using the desktop experience,
but on mobile you have to click
something to show it.
I don't know,
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
[00:39:32] versus,
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,
versus CSS.
I do wonder,
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?
Yes and no.
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.
Right, right.
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.
Right, right.
If you...
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.
For now, then?
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.
It's just...
Somehow, it's just this thing that exists in the platform
really as a debugging tool and nothing more.
It's users.
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 do
and debug.log only for development purposes.
Actually, mobile phones, or at least Android,
has a...
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.
That's true.
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,
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?
You can't.
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?
I don't know.
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,
which I'm not.
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
with Tessa,
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?
Well, yeah.
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,
that's ideal.
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
is using URLs.
How so?
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.
Why not?
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.
Yep, exactly.
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?
Like the menu,
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,
which is huge.
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.
Yeah, right.
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
for example.
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...
That's nice.
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
to a form post
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.
Right, right.
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?
Well, the...
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.
I think...
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.
I'm not sure.
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.
All right.
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.