 Hi, I'm Jen Weber, I'm a senior software engineer at a non-profit called ActBlue Technical Services. I'm also a member of the Ember Learning Core team. Today, I'd like to tell you a little bit about why I think HTML first apps are the future, and how that should impact your day-to-day work. You're going to get a short history lesson about how HTML came to be. Together, we'll critique some Ember templates as if we're doing a little mini PR review. You'll learn some useful patterns in Ember apps, we'll learn how to critique other frameworks and how they treat HTML, and we'll talk about what the future holds. I'd like to invite you to think for a moment about your own history of using HTML. What was the first HTML that you ever tried to write or edit? What was the feeling that that gave you? My first HTML was trying to edit a Tumblr theme. I was in my first year of college, some other friends of mine had Tumblers, and I noticed that their themes had this thing called a following list or a blog role. I really wanted to add it to my app. I copied and pasted some things from another template, adjusted some styles, and it had become my own. Now, anyone who followed me could find even more angsty teenager poetry and essays. I asked around on Twitter a couple weeks back to see what other people's first HTML was, and a theme emerged. Abby Milberg says it was Neopets followed momentarily by GeoCities. Both were resplendent with marquee and blink tags. Brian Aka had an Angel Fire website with their stepbrother, where they'd write weekly stories in chapters together. Edward Faulkner, EAF4, says, My Eagle Scout Project was making webpages for local nonprofits and teaching other scouts how to do this. The hardest part was convincing people that they wanted a webpage in 1997. T.S. McDonald made a fan site for the TI-86 graphing calculator, which they made when they were 10 for extra credit in math class. Many people built something with an emphasis on community, something that linked them together. HTML is a great tool for bringing people together and building successful businesses. But HTML is more than you think. HTML is the key to building apps for devices that I have never seen or cannot even imagine. Back when people were building apps on GeoCities, I didn't know that I'd be looking at the web on my phone today. As I was researching this talk, I looked at websites from the 1990s using my laptop and phone. The authors didn't build with my use case in mind, but their sites worked. Maybe the apps you build today will be shown on a watch, a touchscreen, as big as a wall, a heads-up display of some smart glasses. Maybe I'll ask a voice assistant to help me use what you have built. Are you ready for that? I think we're going to need a lot more than a bunch of nested divs in order to get there. If we think about the future, how does it change the way that we build apps today? For inspiration and understanding, let's look at the history of HTML to see what we can learn about how the early visionaries successfully built for today's world. For this part of the talk, I had to do a lot of new research. I became a web developer about five years ago, and I knew almost nothing about how the web came to be. My favorite article that I found comes from w3.org. It was written in 1998 by Addison Wesley Longman, and what I love about it is that this article has a little bit of attitude. It gave me a sense of just how much sharing, communication, debate, and conflict went into the tools that we use today. Let's start in the 1940s. The idea of annotating text indicates its layout into paragraphs and headings has been around for a really long time. It was well established in academia in the 1940s. The 1980s brought ways to link files on a computer's own file system, but a computer on the other side of the world was still out of the question. In 1989, Tim Berners-Lee wrote the first proposal for the World Wide Web. Berners-Lee, a researcher at the European Organization for Nuclear Research, had worked out how to make files available globally. They needed to be transmitted in a standard format, so he wrote a proposal for HTML. Rather than writing a new language from scratch and trying to convince other people to use it, he based his work on Standard Generalized Markup Language, or SGML, which was already a globally accepted standard. It just didn't have any context of hypertext links. 1990 was the year of the first website and web server running on a computer at Berners-Lee's lab. This is the URL of that first webpage. In June of 1993, the first formal proposal was published with a minimal set of tags. Many of the things that I use daily were not in there, no inputs, no buttons, not even span. It was more about lists, headings, and paragraphs. Along the way, other computer scientists and researchers started to take notice and come up with their own renditions and opinions. For example, Dave Raggett studied printed media like newspapers and magazines in order to compose a richer set of tags, which he called HTML+. A proposal for HTML+, was published later in 1993, and that proposal included things such as inputs and tables. A lot of the work that was done was done in the open. This was cool because a lot of people could follow along and participate, but some things also got kind of sticky. Design and discussion passed through many, many different groups. We talk a lot about individual inventors such as Tim Berners-Lee, but you can see from this list just how many people must have been involved. These committees and working groups rose and fall, they changed and evolved over time. As the web grew in popularity, so did the communication burdens and the debates. Longman writes, the HTML working group was an excellent idea in theory, but in practice, things did not go quite as expected. The group was notably slow in coming to a consensus on a given HTML feature, and commercial organizations were hardly going to sit around having tea, pleasantly conversing on the weather whilst waiting for the results of debates, and they did not. Following this, business pressures pushed browser vendors to create their own smaller structured groups with an interest in speed getting things done quickly. In the early 2000s, this became known as the browser wars as vendors battled for the attention of users. Some interesting facts that I learned along the way while researching this. The internet engineering task force had a theme song, and it's about as good as your high school's alma mater. HTMLERB is the name of the group that killed the marquee and blink tags. This was part of a negotiation between browser vendors. Netscape would only agree to let go of blink if Microsoft would give up marquee. I also learned about computer scientists like Dr. T. V. Ramon, who helped to make sure that HTML could be used in other ways than just viewing it on a screen. Ramon is the inventor of Emacspeak, which is a free Texas speech tool released in 1995. Ramon was part of early HTML discussions, helping to make sure that the web was accessible to people who were blind or had partial sites such as him. In more recent history, 2004 saw the beginning of the Web Hypertext Application Technology Working Group, or WWG. In 2011, WWG announced that there would be a living standard for the HTML5 specification. A living standard is something that's improved over time and never complete. New features can be added, but functionality was not going to be removed. In 2014, HTML5 became recommended. It included many, many new semantic tags such as nabs, headers, form controls for emails, dates, and times. In 2019, we saw an end to competing standards that had occurred between W3 and WWG. Now today, WWG is the main authority on what HTML5 specification is. Today, HTML is about iteration. There are no plans for an HTML6. Tim Berners-Lee is the director of the World Wide Web Consortium, aka W3C. Dr. TV Ramon is working on voice interfaces for Google. A lot of his research and philosophy focuses on the idea that information on the web should be agnostic about the way that it is presented. Browser vendors are not totally in harmony. The work of creating, maintaining, and implementing web standards continues every day. Browsers are creating their own proprietary APIs, and that continues to be a source of conflict, risk, and innovation. Overall, HTML is the result of millions of hours of debate, design, research, and implementation work by thousands and thousands of people. It also includes billions of hours of user experience that informed its current shape. The considerations that went into it are more numerous than any one of us could know. Every single tag has a purpose, and it's connected to the browser features that we may never see. For example, on the W3 website, there's this totally massive table that shows how semantic HTML elements such as nav and button map to different roles and features in the browser. You can check this table out by looking for the accessibility API mappings on W3.org. This mapping is what makes up our daily experience of the web, things like when your password manager fills in your login information, being able to press to paste on mobile browsers, gives you keyboard navigation of forms, and it provides cutting edge capabilities to cutting edge critical accessibility technology and assistive technology such as screen readers. These features and their connections are more than any of us could learn, but you get it for free when you use semantic HTML correctly. Semantic HTML is a way to automatically get all of the roles and mappings that make these features possible. When everything is divs, you miss out on some of the most powerful programming tools in history. Semantic HTML goes far beyond what your template markup looks like. This is something that I wish I knew at the start of my career because so much of what we talk about as best practices for the web make a lot more sense in this context. Today, I understand that Semantic HTML needs to be part of my areas of expertise so that I can help other developers close their own knowledge gap. We can make apps that work for everyone, including our future selves. So we've talked a lot about HTML, but I don't know about you. Most of my work doesn't take place directly in HTML files, so it's time to talk about where single page apps fit into this story. When single page apps came on the scene, I'm talking about frameworks such as jQuery, Ember, React, AngularView, all of these, they faced some unique challenges. In a purely HTML based app, every time you went to a new URL, the whole page was refreshing, and a lot of other technologies were relying on that behavior. An example is URL history so that you could do things like click the back button. Another is search engine optimization. Crawlers for search engines such as Google assumed that the DOM had all of its content ready right when it was reading the page, whereas we know that a lot of our content today is populated through JavaScript code. There were also issues with accessibility since you weren't changing the URL, since you weren't refreshing the whole page, screen readers didn't know that the context has changed. There's fixes that have been in place for all of these different issues. Today in browsers, we have things like push state and replace state that help with managing the URL history. The crawlers that are being used have evolved and in cases of the frameworks themselves, we have tools that help with pre-rendering and provide that pre-render content to the search engines so that you don't have to choose between having good search and having a really snappy user experience. Lastly, with accessibility in the Ember community and in other developer communities, there are tools for helping to manage your routing transitions through the app and make them available to people who are browsing the web in different ways. What does it mean to put HTML first? It means that whenever we're working on apps, we want to write valid semantic HTML by default. We want to follow HTML like patterns in non-HTML so that there's not as many new things to learn. We want to emphasis readability of templates over their dryness. Dry stands for don't repeat yourself. I've also been introduced to an acronym called Damp, which is descriptive and meaningful phrases. Damp places an emphasis on being able to quickly skim code or markup with the idea in mind that we spend most of our time reading code as opposed to writing it. Lastly, it means to test for mistakes in your HTML. These are things that you can do as an individual developer, but they're also things that can come as part of the features of the framework that you've chosen to use. When you choose to build an app with Ember, you get some benefits of an HTML first approach with little or no work and prior research needed by you. In this next section, I'm going to show you how things used to be done in some older versions of Ember and compare with how they look in Ember Octane. Things are continually evolving and improving, and this is the best way for you to be able to see it. In older versions of Ember, when you generated a route, you would get something like this, which has an outlet in it. Today, when you generate a new route when you're using Ember Octane, it comes with this page title helper. The page title is an important part of accessibility and SEO. This is the title that's used in things like up at the top on your browser when you see the name of the page in your tabs. It's used in the search engine results. It's used for helping people know where they are as they're navigating through your app. In older Ember, we used to show things like input examples all by themselves. This isn't valid HTML because every input needs to have a label. In today's docs, we show more full-fledged examples that include labels. This is something that will hopefully help others fill in their gaps of knowledge, and it matches more what we see in real-world apps. In older versions of Ember, there was this thing called the application wrapper. It's an optional thing that you can still have present in today's apps, but when you generate new apps, it's not there anymore. What the application wrapper did was it put a div just inside the body. This had some problems because some landmark roles such as header, main, footer work best when they are direct descendants inside of the body, not wrapped one layer deeper in a div. So today, if you generate a fresh app using the latest version of Ember, you won't see that wrapper anymore. In older Ember, we used curly braces around components. This worked well, but it isn't necessarily following some of the same patterns that we see in HTML. Namely, it was difficult to tell whether what you were looking at was a helper or if it was something that was going to render new HTML elements. Today, when we look at Ember templates, they look an awful lot more like HTML, and some of the features of the components that you use in Octane are more closely aligned with HTML attributes and properties. So armed with this knowledge, what can we do to review our own code and make improvements to it? I'm going to show you a few different code samples, and as you're looking at them, I want you to think about what could be improved, but also how you would communicate those improvements to somebody else in a way that is empathetic and about sharing knowledge instead of blame. Some of the things you can look for are whether the template uses semantic HTML, if the semantics are readable so that they can be easily maintained. We want to know that our template linters are passing, we want to have accessibility tests and see those pass as well, and we want to write our apps in a way that makes room for non-Java script developers. So for example, if a CSS specialist joins a team, is it possible for them to work within an Ember app without learning all of the ins and outs of Ember? Could they be productive on day one? That's a question to ask yourself whenever you're looking at these templates. All right, so take a look at this example, and think about what could be improved. If you'd like, and you're watching this video later, you could pause it and study it for a little bit. The main issue with this component is that it's attaching a click action on something that isn't supposed to be clickable. It's attaching it to a div, not a button. The problem with this is that by using a div instead of the semantic button, we've lost a whole bunch of automatic behavior, such as being able to tab to this and interact with it by keyboard to press enter and have it click the button for us. So to fix this, turn it into a button. In an Ember app, your linter should tell you that something is wrong here. So I use VS Code. I have the language server installed, and when I do that, I get this little squiggly line that warns me, hey, you're making a mistake here. I can also run my linter from the command line, and it's all there installed for me from the moment that I first create my app. All right, what's wrong with this example? This example works, but it has a little bit of a problem with understandability. Someone needs to know a little bit about JavaScript and Ember in order to understand what text is going to be rendered here when. Is it going to say save? Is it going to say cancel? And furthermore, this pattern of using modes, it's not so bad if you have just one mode or two, but they can start to proliferate, and the result can be that your templates grow in complexity to a point where it's hard to read and know what the actual HTML output is going to be. So this could be improved by passing in the text using a block-style component instead, or maybe breaking this out into two different components. This example has some similar issues as the previous that it is a bit difficult to read. The let helper can be something that greatly improves your readability of your templates, but it can also be something that adds complexity. Additionally, anytime you're adding things, classes to your components in such a way that you can't just search the project to find where those class names are used, you might be in trouble. This also is a barrier for anyone who's come to work just on the CSS of an app. This component might be a little bit brittle because they might search for something like example-button, not see that text anywhere in the app except for in the CSS and think that that rule is okay to remove. I also want to mention date pickers really quickly. A lot of them have major challenges with accessibility. Semantic HTML, the inputs provide a way for us to add Tuesdays and times with more of a guarantee that it's going to work across all devices. It's going to work for lots of different types of users and things like assistive technology. Consider replacing custom date pickers with native date pickers. Next, let's review some other stuff. Let's take a quick look at how we could evaluate other tools in the wider JavaScript community for what they're doing well or not when it comes to an HTML first approach. Again, keep in mind how would you communicate this in a way that is constructive and helpful and uplifting. In the open source community, people put a lot of effort into these types of tools and it's up to all of us to share and grow together. Some things to look for in any framework that you're evaluating. Are they using semantic HTML in their examples? Is the markup that developers write readable? Are there things such as template linters that help you catch problems like the one that we just saw a little bit ago with the click action? Are there accessibility testing tools? How much work is it to put them in place? How much needs to be custom in order for you to have some additional assurance that you're building the right thing? Lastly, does that framework make room for non-JavaScript developers to participate in the experience as well as I like to think of people who are just learning how to be web developers? There's a lot to learn and a smaller overhead can make a big difference. So this is an example from React. We saw earlier that you can write the same sort of thing in Ember and clicking on that div would work. But we know that that's not great for accessibility. We know that that's not great for keyboard controls. And the difference here is that if I use the tools that just create React app, there's nothing here that warns me that I've made this mistake. Another major issue can be readability. So this is again an example from React. And experienced React developers would tell you that there's a lot of ways to clean this up, to make it easier to maintain, to prevent having a whole bunch of get conflicts if people are working in the same file. But again, it's something that you can do whereas it's a little bit difficult to create a similar sort of complexity using Ember templates. So why is HTML first, the future? I don't know everything about what users need even right now. When I'm working on my computer, it's really different than what everybody else is going to be using my app on. Our technological future must be creative and inclusive and empathetic. And using semantic HTML is the easiest way to be ready for whatever that future holds. You can find some more examples of how semantic HTML is an important part of Ember and how you can build it into your own development process by going to my GitHub repo at genweber.html first demos. You can also find a link to my slides which has all of my sources for today's talk. Special thanks to Yehuda Katz, Melanie Sumner, Edward Faulkner, and Chris Manson for educating me on a lot of these topics. I'd also like to thank everyone who worked to bring these amazing features to life in Ember, especially Robert Jackson and the people who contributed to the Ember template linting project. Thanks so much for watching.