Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the house with the kids--Rupert and with me is Chris--comfortable in the booth--Coyier. How's it going, Chris?

Chris Coyier: Fine. Fine. Yeah, I'd say I'm encapsulated in this booth.

Dave: Encapsulated.

Chris: There's some--

Dave: You have some black foam in there. It's creating a nice shadow.

Chris: [Laughter] Yeah, that's right.

Dave: There are parts. I see parts.

Chris: Anyway, we're going to talk about Web Components. Those were open Web Component jokes.

Dave: [Laughter] Yeah, open Web Component jokes. How to impress your family. Step one: How to impress your family at holiday parties. Make Shadow DOM jokes.

Chris: [Laughter]

Dave: Families love this. They think that's funny. They don't even know what piercing the Shadow DOM is, but they think that's hilarious, so use that at your Christmas party.

Step two, tip number two, so there was a little Web Component drama. I went on a trip into the mountains and didn't have the Internet.

Chris: Yeah?

Dave: But there's a little Web Component drama that broke out. I don't even know what it was. I think somebody used one and that caused a big whole stink. [Laughter]

Chris: I actually don't even know what you're talking about. I have some things to discuss about Web Components, but I missed this drama.

Dave: I just saw Zach Leatherman getting into it. I think he's using it now in some places or something - anyway.

Chris: It's it funny how those are the big stories. They're like, "GitHub used one once."

Dave: Who dat what? Oh, my gosh!

Chris: [Laughter]

Dave: It'll never work.

Chris: They did, I think, for some kind of menu component or something. They also used to use it for a time component of some kind. That is interesting. Of course, it's interesting when Web technology that isn't everywhere else in the world does get rolled out on big sites. I do find that kind of newsworthy sometimes.

Dave: Somebody used Svelte in a big way, I would be like, "Ooh, that's interesting."

Chris: It is. It's always interesting.

Dave: Yeah.

Chris: This whole show won't be about Web Components, by the way, if you just don't care about that, but it is an interesting set of technologies that's still kind of hotly talked about and interesting. There are releases all the time in this world, you know. Big companies are still thinking this is the way.

I just happen to notice a couple of Web Components articles. The way that I save news, I use that Figma -- not Figma. Notion Web clipper.

Dave: Notion. Yes.

Chris: You just click it. Sometimes, I'll tag the post too. Then if there are a bunch of links that all kind of have the same tag, I'm like, "Hmm, what can I combine about these articles?" What's happening right now that a lot of people are talking about this thing?

Dave: Yee-haw. That's a round-up. That's a round-up.

Chris: Yeah! Yeah.

Dave: You just round-up the link. Yeah.

00:03:08

Chris: Yeah. Hopefully, the point of doing this is commentary around it, but one of them I saw was called Shoelace, which looks brand new. It's a pattern library like bootstrap or whatever.

Dave: Mm-hmm.

Chris: But the thing is in Web Components. It's not the first of its kind, but it's a recent release in it. I do think that pattern libraries are the best possible use case for Web Components. They're the coolest thing you can do with Web Components, I think, because it just seems to be built for that. You know?

Dave: Yeah. It's distributable. That's the one thing Web Components wanted to be.

Chris: Right.

Dave: Like open Web tech. You're not tied to a framework. Just use little chunks of code that you can drop in anywhere.

Chris: Right, and are you or aren't you tied to a framework? That's kind of the question, you know.

Dave: Well, this is what I--

Chris: You know you can. For example, there is this technology called Stencil. Stencil is from the Ionic people. They've been going heavy on this, so Ionic is also a pattern library that ships with Web Components but it used to just be for one thing, wasn't it? Didn't it start with Angular or something? I don't know.

Dave: It was Angular to begin with and then I think they went Web Component like Stencil. Now they offer React and React native, so … stuff now.

Chris: And Vue.

Dave: And Vue.

Chris: That's super cool, I think. You can make these native Web Component libraries and then the bindings for your other frameworks are just pick and choose.

Dave: Mm-hmm.

Chris: Oh, you want this other system? I think that's notable and interesting, so there's that. Then this Shoelace library that I just mentioned is also built on Stencil, so there are some connections to these things. But Stencil isn't the only one. Google is hot on LitElement in the lit world, you know. Microsoft has this thing called FAST.

Dave: Oh, I didn't even know about FAST.

Chris: FAST is their kind of version of Lit, I think. Although, I should say that I'm just kind of like learning and watching about this stuff. What I don't have is absolute expert level stuff. I'm not shipping major projection products in this, so my opinions are a bit tempered by that, as somebody who is kind of watching and is interested in this and has the perspective of--whatever--a couple of decades now of building websites, so there's that.

The thing -- so, I talk about in this article, A) there's Stencil, there's Shoelace, there's FAST, and FAST is not only a framework but it has a pattern library thing that you can use too. There are people vying for your attention for their network of stuff to use here. It didn't super directly draw the thing like this is the same as React and Vue fighting for your attention. It's a little different than that. Notably, because of something like Stencil where you can write the framework and still use either framework.

Historically, part of this has been, like, you know React doesn't actually work that well with Web Components, right? There is a lot of friction there. But anyway, ignore that for a moment. These things are built on a build chain of stuff. If you choose to use Stencil to build your things, that's a great, cool, good choice. No problem there. But there is a build step involved. You are buying into some technology if you build your stuff there. It is not absolutely nothing that you're buying into.

Some of the comments were like, "You don't have to, though. If you want to put some ionic tabs and some fast tabs and some Shoelace tabs all in the same page, you can totally do that."

I'm like, yeah, I mean, I guess you can but you can also load MooTools in jQuery on the same page. You know?

Dave: Yeah. Yeah, there's a footprint. You know I ran into this. I have this thing called Awesome Standalones. It's like a list of Web Components that standalone, like kind of cool things you can just drop into your project like a carousel or something like that. But you're no framework dependent. Nothing like that.

But my thing was, I want pure Web Components, no frameworks. If I see it imports a framework, then I don't want to include it in here. But then I had to flex on that because a lot of Web Components use something like Lit or something like that or Stencil.

Chris: Sure.

Dave: But, yeah. Then if you have Lit in your page and Stencil on your page and some other thing--

Chris: And it's hard to compare them exactly because they are like 2K each. Lit is super tiny, right?

Dave: Yeah. Yeah.

Chris: So, it's not quite the same.

Dave: It's not like two React or something, React and Vue or something like that.

Chris: No, but it's not just what you ship to the client, but it's also your build chain.

Dave: Mm-hmm.

Chris: You can't have three build chains. You're buying into the technology on two levels there. It's not just what happens in the browser. It's what happens in the build process, too.

Dave: Because if one is written in TypeScript and one is not, what do you do? Does that impact you? I don't know.

00:08:26

Chris: Can I finish?

Dave: Yeah. Go ahead.

Chris: The ending thing was me just kind of being like, "Isn't this a little weird? I can open CodePen and write a Web Component. I can just write one. It's not that hard. I've done it many times. It's curious to me that everybody buys into some kind of additional thing too.

This is where my ignorance shows a little bit. I guess I kind of get why but not entirely. It seems like absolutely everybody picks something. They pick Lit or HyperHTML or some kind of thing. They say that the dev experience just isn't quite there if you're just using a raw Web Component. I thought, like, why is nobody doing it, though? Is it absolutely required to use the kind of build step for your Web Components even though it's a native Web technology?

The answer, this is where I got called out the most for the article is that they say Web Components weren't really designed to be used raw. They were designed as low-level primitives in which for frameworks to be built on top of. That was the idea from the beginning. I guess I just didn't really realize that.

Dave: Mm-hmm.

Chris: That you're almost not supposed to use them raw. I was like, "Really? Okay."

Dave: That, in my opinion, is maybe the biggest flaw of Web Components and mis-marketing or whatever. It's that it was maybe too low-level and normies like me and you can't use it or shouldn't be using it. Why would you build something in the Web platform that normies aren't supposed to use? That's weird.

But again--I don't know--I think people would use them more if they had some nice sugar. I think WordPress would use it if it had some nice sugar, and that's what these libraries like Lit and things add. Then I love the prebuiltness, you know. Yeah, it's like I'm not -- I know ING, the bank, has some components.

Chris: Mm-hmm.

Dave: Somebody was like, "Oh, you can use ING button on there or the Lion button on your website and it's a standalone." I just was like, but I'm not going to use Lion's design system. The coupling to a design system, too, is kind of weird. You're not just importing a button. You're importing a whole design system, and so that comes with CSS and stuff.

Chris: Yeah.

Dave: I think we're ahead. The distribution is easy now with NPM or whatever. We're ahead of the distribution, sort of. But I don't know that we've figured out how to--I don't know--cohesively author Web Components. Does that--?

Chris: Yeah.

Dave: I don't know.

Chris: It leaves us dumbfounded. Whatever happens, however we got here, the fact that we can't have a conversation without hanging out heads and saying, "I don't know," that's the failure. There's no good story. There's no good way to talk about this stuff that's just like, "Yeah! Do that! That's great!"

00:11:47

Dave: Mm-hmm. Right and, for me, I think there's a gateway to using Web Components. I use this one from Google called Two Up, a lot. It's one of those before/after photo slider things.

Chris: Yeah. Yeah. Yeah. I love that one!

Dave: I didn't want to code that.

Chris: That's a great one.

Dave: Dave Rupert does not want to code that. I don't want to spend a Saturday figuring that out for a dumb blog post. But I will punch that into a blog post no problem. It just takes two image and it'll handle all the sliding for me.

Chris: Uh-huh.

Dave: That's awesome.

Chris: I know.

Dave: I love that.

Chris: You know I'm not using that specifically, but the block editor in WordPress, you get a bunch of bonus components if you use Jetpack. This is totally unrelated to -- it's related to the conversation that they have a two-up slider. Just because it's there and it works so easily and flawlessly, I just use it. I love it when technology is just like, "Here you go. It's easy to use."

Probably, internally, they should use this Web Component. I doubt that they do, but that's the kind of -- it's just such a tremendous use case for it, especially because it doesn't really need much UI, so you're not really buying into a design system there.

Dave: Right.

Chris: It's just a bar and you slide it.

Dave: A bar and some arrows.

Chris: Yeah.

Dave: You could add whatever to the bar. Yeah. That's it, too. I don't even -- like you said, the Web Component story, right? Are we startups? We're startups, so we talk about stories. Man, the story. Tell the story.

The Web Component story, it was piercing the Shadow DOM and styling your own components and things like that. That was kind of difficult and confusing until very recently with Part and stuff like that, which that's still confusing and something you have to learn. I wonder, too, if that's the missing part of the story is, how easy it is to style and change and update Web Components or, if I important a Web Component, am I just stuck with it or what, you know? I think that's some of the thing, right?

Chris: Yeah, we didn't even get into the styling story, which I find tremendously confusing.

Dave: Yeah, so there's--

Chris: Which leads to the point where, if I was going to kick off a new product and it felt like a product that I should definitely be building in components, which I've got to say I'm on that train. I think that's most projects these days, like, the front-end development has shaken out where the component model is kind of the right model regardless of what you're building. You don't always need a reactive component model. You don't always need everything that the frameworks offer, but even just building a blog, I think the right primitive is the component. But anyway--

Dave: Mm-hmm.

Chris: If I was kicking off a new product of any scope, but let's say it's something like CodePen, the thing that I have experience with, would I pick Web Components? Oh, most definitely not.

Dave: Mm-hmm.

Chris: I would pick something with a much more robust developer model.

Dave: Yeah.

Chris: That's still Vue and React, to me.

Dave: Mm-hmm.

Chris: I'd probably pick one or the other.

Dave: Yeah. No, I mean -- and I would pick Vue. I mean I have a project in Vue.

Chris: Yeah.

Dave: Even though I like Web Components. It probably doesn't need to be Vue, to be honest. The more I work with it, I'm like, man, I kind of really overengineered this one.

[Laughter]

Dave: But I just knew I was hitting data sources and stuff, and so I just was like, "You know, I should just use Vue." But, man, yeah, I'm just not 100% in even though I'm like Mr. Pro Web tech anti-framework or whatever. Not really, but even though that's sort of in my ethos, why am I not all in on these? It's hard.

Chris: Yeah.

Dave: It's just not quite there yet and I'd love to figure out what it is.

Chris: But it does have -- the feather in its cap, to me, is that it has the Shadow DOM. It has something that a framework can't do. The Shadow DOM is totally unique to the Web platform and a very powerful concept.

Dave: Mm-hmm.

Chris: The thing that's going to blow this thing out of the park is if a major framework brings along all of its power and decides to go in on Web Components.

Dave: Yeah.

Chris: If Vue 4 was Web Components, that's going to change the game.

Dave: Right. Yeah. No, that would be interesting to see. Yeah, I don't know. I would love to explore it more but, again, it's time and I'm not going to make that gamble on my clients and websites and stuff. That's hard.

Chris: Right.

Dave: But I'd like to go that route. There is so much potential there, but--

Chris: Yeah.

Dave: Hmm.

Chris: All right. That's my thing, and grain of salt and all that because I don't have nearly the experience that a lot of people do, let alone the CEO of Ionic or whatever. [Laughter] I'm sure you know what you're doing over there, so please continue doing what you're doing.

Dave: Well, it is interesting; they had to kind of tailor. They were like, "You know what? A lot of people are using React. We'll have to ship a React version of it. We have customers that want that, and so we'll have to use that," and that Web Components didn't just work. "Just work" in big quotes.

00:17:04

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Notion. Oh, I love Notion! We talk about it regularly on this show, I feel like. This is their first sponsorship, so high-five about that.

Real quick, at the top, notion.com/shoptalk gets you 10% off a team plan, so know that. The URL is notion.so, but notion.com, that's all you've got to remember. Don't worry about the domain. notion.com/shoptalk will get you there.

What Notion has done for me--you know, I could talk forever about this--is replaced and consolidated a bunch of other apps. That wasn't even what I set out to do. It just has happened that way and I love that it did.

For example, my to-do lists, they're all in Notion now because the Notion document structure is perfect for that kind of thing. Documents of any kind, that's the thrust of Notion that are nested within each other. They can be of different kinds and it's all beautifully designed and customizable.

I had a publication calendar. I'd keep it in a spreadsheet because that was the closest thing I could figure out to organizing it. Now that is a database in Notion where I have all these different views of it like calendar view and list view. It's just a wonderful place to do a publication calendar. A huge upgrade, and I can share it with my team and share parts of it with access with other people. It's just great for a publication calendar, so I'm so happy to have that.

We have a wiki at CodePen in our Git repos that would explain internal coding guidelines and just things you need to know about CodePen and working there. That kind of wiki-like stuff is perfect. Get rid of that. Get it over in Notion. It's a lot more findable, a lot more nice to look at, a lot more organized. Love it.

Meeting notes, I never really got a good system for. I'd keep text files in a DropBox folder. No way. All my notes now, whether they're personal or shared or whatever, I do it all in Notion.

The biggest thing I use for it now is planning, so our active projects on everything. I use this at CodePen, CSS-Tricks, ShopTalk Show here. We all have different workspaces. We do it all in Notion.

Planning projects is so great there. You can do it however you want but, ultimately, projects for me turn into these conbon boards of tasks that get assigned to people, that have information in them, comment threads, all that. Project planning is wonderfully done in Notion, so notion.com/shoptalk, get yourself 10% off if we've got you convinced.

[Banjo music stops]

00:19:46

Dave: You know back in the day -- we're old enough -- maybe not all the listeners here are old enough to remember. There was MooTools, Prototype, Dojo, jQuery, YUI. There was a half a dozen different JavaScript frameworks and you would just write your JavaScript in that framework and there were different plugins. There were different ways to animate, different plugins, different everything. Eventually, just the great sifting of the Internet, jQuery kind of sprung ahead. I don't know why and don't remember the reason exactly, but jQuery kind of sprung ahead.

Chris: MooTools had classes. Nobody liked classes at the time. That was too weird.

Dave: Yeah. Well, but I'm curious, too. I think everyone is like, "I know. I'll write my own Web Component library." You know? [Laughter] It's like, "No!" The whole point of Web Components is, we should use the great hive mind of the Web and not repeat ourselves. You know?

Not that we need more kings and more kind of rock star frameworks or whatever, but is there one big standout Web Component framework we should probably all get behind and say we're starting our projects here? Does that exist? Open WC, Open Web Components seems like a thing. But is there one we could all kind of put weight behind and hit a critical mass to where Web Components become a thing?

Chris: Is there a secret conspiracy to this? Isn't that why Microsoft put effort behind Fast? Don't you think that's deep in there? Why does Google care about Lit? They care because they want to control a little chunk of the ecosystem. There's just benefit to that. I don't know why, low down.

Dave: Yeah, that's interesting. My thought would be Google made Polymer and Polymer was supposed to be the racehorse, you know.

Chris: Yeah.

Dave: That was supposed to be the thing. But then there was a lot of kickback and pushback against Polymer. But then I think even internally, Polymer had some trouble getting adopted. You know? There were some things on YouTube or something. I don't know.

I wonder if Lit exists to support ex-Polymer customers. Is it an internal project that they also make external? I wonder because Amp is also a Web Component framework or was - or is, I guess.

Chris: Yeah, you've got to wonder what the hardcore -- like the strategy way above the average developers that work on these things probably are privy to. High-level manager product owners at these companies, what do they talk about? Why are they like, "Okay. We're going to put $15 million in this budget bucket for this technology." Why does that get okayed? Why did that become a good idea at all? I am totally ignorant to that.

Is it because they're like, "Well, if we control the toolchain for this, then our internal products are built from it and we get some developer notoriety and it's easier to hire." Is it a hiring thing? Is it a--?

Dave: I think, for React, that's true. I think you control developers' minds. That's part -- like, if you have that mindshare, you have--

Chris: The story there was kind of like, we need the technology in order to build our product because our product will be better if we build the perfect tool for it. But is that still the case? I don't even know.

Dave: I think there's power, like corporate power. Not like we're all minions or orcs from Lord of the Rings or something, but there is corporate power in having developer mindshare.

Chris: Yeah. Maybe that's it. It's as vague as that. But that's what I mean. Once you have the mindshare, in what way do you then benefit? Mindshare isn't the final goal. The final goal is whatever mindshare buys you.

Dave: Well, I mean you look at Windows versus Mac in the early 2000s. They sucked up a lot of -- like Windows was where all the software was. Mac had bad software, or whatever. Then slowly with Rails and different things, developer mindshare started shifting over. And cool hardware, developer mindshare started shifting over to Mac. Now the Mac has all the cool software and Windows is kind of like, "Oops." [Laughter] "This hasn't been updated in a few decades." You know?

Chris: Mm-hmm.

Dave: I think developer mindshare builds your ecosystem. It builds your tools. All boats floats things. That's the same with React. You get the best extensions. You get the best plugins. You get the best state managers because you have mindshare, and so your React framework just grows and grows and grows.

Chris: This is fascinating stuff to think about. What's the real reason for it all? We got deep there quick.

Dave: Yeah.

00:25:16

Chris: Let's stay in this world for a minute, though. We have one from Jake McKelvey here who says, "I'm about to build a new single-page website for a client who started a nonprofit. Pretty basic. What they want is basically static. They're not even making the changes themselves. They're going to come to me," meaning Jake, "for the updates. It's just some basic copy, images, a donate button that just shoots you over to PayPal."

Jake says, "I've been making websites for a better part of a decade but I still don't have a tremendous grasp on the new Fangled frameworks and understanding of when or why I would benefit from using them and understand that it's still okay to just use HTML, CSS, and JS." If it works, it works. Just build websites, et cetera. "Can you help me understand whether I would actually stand to benefit from using one framework or another for something like this? Is there a framework that is meant for this kind of thing? My inclination is just to build it, keep it simple, so I'm not upgrading dependencies all the time." Yadda-yadda.

Jake, you're building literally a one-page site with a donate button where they're very happy to just shoot people over to PayPal. I mean I can't picture every aspect of the site, but that seems like the easiest one in the world for me to feel confident to say that you do not need a framework of any kind for this website.

Dave: Yeah. I would say, don't. If you're super happy with what you do, do that.

This is my philosophy. I think where frameworks come in handy -- and this could even be some kind of CSS Grid framework. This could be some CSS utility library framework. This could be a JavaScript framework. If you find yourself doing repetitive tasks, that's where frameworks can benefit you, whether that's on a page-by-page basis or a client-by-client basis.

In the early days of Paravel, I put my foot down and I said, "Every site is 960 grid because I'm not going to come up with a whole new layout system for every single site we're building." That was maybe heavy-handed of me for Reagan and Trent, but I just was like, "We have to have some structure I can build with. I can't just one-off every single page of this website. I need a consistent baseline." That was how we made our money in the early days.

Chris: Mm-hmm.

Dave: We just said, "We're going to use 960 grid." Then some responsive frameworks came out and we kind of tried to roll our own grids here and there, but that was after we kind of understood how grids worked in a design. That helped us.

The same with the JavaScript framework, like I think I just said. If I'm doing a lot of data fetching and a lot of template generating and stuff like that, I've done that in jQuery plenty of times. It's not fun. If you have ten buttons and ten templates that you're generating and spitting out, I would rather use a framework for that. That's where if there's a high repetition, I think a framework starts to pay off.

00:28:27

Chris: Yeah, my mind went right to the JavaScript framework thing. I still think this is -- I wrote this in 2017, because it was definitely a journey I had to take, too. There was kind of a long time where frameworks like React were a thing and I just didn't get it. I just didn't understand what you would need that for. Even while CodePen existed and we were building it and the whole thing was Rails and jQuery and React was there, but I'm just like, "Meh." I don't know. It was CodePen in which that I first used React after launching some investigation, learning more about it, doing some prototypes, having other developers on my team kind of advocate that that would be the right approach. Then we bought into it and now, slowly, have moved.

To this day, we're still not 100% across the board converted because the conversion is quite a process. Although, we're mostly there, et cetera. I think, shortly after that, me kind of getting it, April 20th, 2017, I finally wrote this article that says, "When does a project need React?" It was my take on that kind of moment, which I think you're looking for, Jake, where it's kind of like, maybe just raw HTML, CSS, and JavaScript aren't enough anymore. When is the tipping point where you kind of need to reach for it?

Dave articulated one very nicely is templating. If you need that, if it's that moment where you need -- clearly, you need client-side generated templates, your server isn't handling it or your server is giving you the data but you need to smoosh those into templates client-side, that can be good for that. Although, that story is complicated these days by being able to do some of that on the server, but let's not go there yet.

Dave: Mm-hmm.

Chris: My first one in the article was about state. Now, to me, state couldn't be more clear as a concept. But I feel like there are plenty of developers out there that are just like, "I built lots of websites and I never even think about the word 'state.' State is just not in my brain. It's just not important to the type of websites I build." There are probably a lot of developers out there that, "That's all I do. All-day long, I live and think in state." It's kind of an interesting, dividing moment. You know?

Dave: Yeah.

Chris: There are developers who live in state and ones that it doesn't matter. It's almost the difference -- and I hate to ever say this--

Dave: Uh-oh.

Chris: Sites versus apps. I don't like that distinction. Don't get me wrong. I think there is mostly gray in the middle but, on the edges, at least conceptually, you can kind of understand it. A site with a dashboard on it that's showing that you log into and you have paid plans and the dashboard shows stock data on it, is clearly what people think of when they think of app.

Dave: Mm-hmm.

Chris: There's lots of data flying around there. There are dashboard widgets that you're dragging around. You're--I don't know--changing your password. You're just doing all this app-like stuff. Then there are sites that are just like, "It's a blog. You publish blog posts. The blog you post has a URL. That's it." You know? Then the far other side, I think people understand that.

On the app side, that's where state, there's just way more state happening. You're like, "Which widgets are active? Which widgets have what data? Which widget is collapsed or not collapsed? Which widget?" You know. I don't know.

Dave: Yeah.

Chris: There's just all this state stuff and JavaScript frameworks handle state elegantly. That's kind of like their top feature, perhaps.

Dave: Yeah, the reactivity, especially. If that state changes, that change will cascade down through the whole page and update your whole page based on one little data change.

Chris: Yep. Then there's this idea. There's that whole chunk of gray area in between that I talked about. You have this site, but it's like, uh, now it's got a commenting system. Honestly, you know what? It kind of Ajaxs in some other blog posts from other areas of the site sometimes. Eh, you grow and grow and grow. You're writing more and more JavaScript that goes with it. Imagine that was jQuery back in the day, but maybe, Jake, you're just writing vanilla JavaScript now and adding.

It starts to get to be a lot. It starts to get to be the point where you're like concatenating files together. Different pages have different JavaScript files on them because you don't want to load it all everywhere because it's too much. You get to this point where you're like, you're writing a lot of JavaScript and it's totally separated from the HTML.

There's also this concept that if you go into a framework, those two things start to get smashed together. Your JavaScript and your HTML start to live side-by-side in a way that they don't when you're just writing raw HTML, CSS, and JavaScript, which gets to this point where it's kind of called spaghetti. It feels so separated. To reason about how the JavaScript is doing what it's doing on the page, you're looking at the HTML and seeing what's there. Then totally separately, somewhere else in your codebase, there's some JavaScript that touches the DOM and figures some stuff out there.

It starts to get hard to reason about and it starts to have bugs because you're like, "Oh, somebody changed the selector in the HTML and it totally broke this component somewhere else in the app because the DOM selector is now wrong." You just get this spaghetti problem and this bug problem, and that's another moment where JavaScript frameworks stepped in and said, "If we smash all this stuff together, we're solving a lot of problems here. We're solving the bugs. We're solving the difficulty to reason about what's happening on any given component."

Component is a big word there, too. That's very helpful. It brings that component model that I think a lot of front-end developers are like, "Yep. That's a nice way to build."

Okay, that's my rant. [Laughter]

Dave: Rant. Yeah, I was going to say, too, the convention aspect is a thing too. When I build a website by myself, I just put files wherever and it's not helpful to anyone who shows up later. Hopefully, the framework you go with might have some conventions. "Oh, we put components files in a folder called components," or "We put pages in a folder called pages." [Laughter] Not every framework has that.

React doesn't really enforce anything like that but Vue kind of does but Nuxt, which is another layer on top of Vue, certainly does.

Chris: Yeah.

Dave: There's stuff like that.

00:35:06

Chris: Developers like conventions. If you think you don't, you probably will be convinced later that you do.

Dave: Imagine hopping into a project that you've never worked on and you know exactly what's going on. That's a huge deal.

Chris: Yeah!

Dave: Dave Rupert can hop into any Rails project on the planet and be like, "I kind of get what's going on."

Chris: Totally.

Dave: You know?

Chris: Absolutely.

Dave: I don't have to think, like, "Oh, man. Where's the database config?" [Laughter] It's like -- you know it's in the db.rb file. [Laughter]

Chris: Yeah. [Laughter]

Dave: It's always in there, so that's the power of frameworks, in theory. React it's like all these components, they all work the same. Whereas with a jQuery component, which you can have those, component A and component B are going to be radically different. They're just going to be like -- who knows. The classes can be all different. What you change, how you show, how you hide, all that stuff can be all different.

A framework, there is going to be some consistency, hopefully. That's when I would -- if you're having consistency problems, that's when a framework helps.

Chris: I love it. That was a nice little segment.

Dave: Yeah.

Chris: We should sell that MP3 for a dollar.

Dave: One dollar on why to use a framework.mp3.

00:36:28

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by WordPress.com. You might know WordPress.com as the hosted version of WordPress, so you need nothing at all. You want to spin up a site, you go to WordPress.com. You spin up a site.

It could be for anything. It could be an e-commerce site. It could be a landing page site for your business. It could be a portfolio site. It could be a photography-based site. It could be a blog, of course. I love all those ideas. Please have a site for the things that you do, including a personal website and those for your businesses. That would make me happy.

And it'll be a site that you don't have to worry about because it's totally handled by them, right? There are no performance no concerns or getting hacked concerns or all that. I really like it when people choose WordPress.com for sites with zero technical debt. Let them handle the stuff.

This is something that I don't think a lot of people know. It's a relatively new thing is that you can have -- and you've got to be on the business or e-commerce plan to have this, but you can have SFTP access to the site and you have database access as well. It's really similar to any other host, right? You sign up for a hosting plan and they're like, "Here's your welcome email with your SFTP credentials. This is how you SFTP in. Put the files here and that's how you operate a website."

A lot of us, these days--I know at least this is how I do it--have some kind of deployment system set up that has access to those SFTP credentials so that I'm working locally. I'm working in Git. I'm committing to branches and all that. The deployment software is like, "Oh, somebody pushed something to master. I'm going to go ahead and deploy that to the live site." That's how I do things.

I think that's a nice kind of DevOp setup that even somebody like me can do without extreme DevOps knowledge. There's no reason those SFTP credentials couldn't be to your WordPress.com plan, so you're just using it like a WordPress host, which I think is really neat. It's like you can still have this modern developer workflow be working locally on your WordPress site and then shipping it up to WordPress.com. You could have your own plugins, your own theme. You can mess with the functions.php file. It's still your totally custom WordPress site. It's just hosted on WordPress.com. it's kind of a mind shift because I don't think people think of WordPress.com in that way and that's because it's new and you can do it now, so try it out.

[Banjo music stops.]

00:38:58

Dave: All right, James writes in. I have to read these because sometimes people say, "Don't say my name." [Laughter]

Chris: Yeah.

Dave: Okay. James, I believe, or we'll call him Johnny. "What are we supposed to do to make phone numbers and zip codes, or numbers in general, more accessible? For context, I've been trying to do more for accessibility, labeling forms, being mindful of contrast, alt text, all that good stuff. I was on a site using what I presumed to be a plugin called AudioEye--"

[Nefarious music]

Dave: We should have nefarious music that's come up before. "--that offers some accessibility tools right in the browser: contrast, font changes, reading guideline, screen reader stuff, et cetera. So, I started playing around with it and got to a zip code and then a phone number in the screen reader. Well, it didn't do what I hoped or expected. It read the zip code as sixty-two thousand seven hundred and four."

[Laughter]

Dave: "On the telephone number," href tel, whatever the telephone number, "it read a bunch of attributes that I assume were used by the plugins."

Chris: That's a good point.

Dave: Then the phone number.

Chris: Yeah.

Dave: It read two hundred and seventeen, which is the first three digits of the phone number.

Chris: Yeah.

Dave: For the area code. The rest of the numbers were read as individual digits.

Chris: Which is kind of what you want. That sounds good.

Dave: Four, five, six, seven, eight. Yeah, kind of weird. I guess because you had parentheses around it, maybe it was grouping that.

Chris: Yeah, that's good, though. You wouldn't want -- the zip code is definitely bad. If your zip code is one, two, three, four five, it should read one, two, three, four five, not twelve thousand three hundred and forty-five. That's just not how people say zip codes, you know?

Dave: Yeah.

Chris: But how do you force that to work? Can you? Do you know a trick to get it to read right?

Dave: Well, so that one was probably input type=number, which is not what you want to use for a zip code - for a few reasons like the number input has that little scroller. If you accidentally mouse wheel -- and you could picture somebody who has limited mobility or something like that and is trying to click on their webpage and accidentally hits the scroll wheel and scrolls their zip code up a thousand numbers, that's bad. Number inputs are kind of poorly designed in that way. You should probably just use a text input, but there's this new API, I guess, called Input Mode, which is an attribute.

Chris: Right.

Dave: There are a thousand different options for input mode or something - a hundred.

Chris: There really are, but they're all cool. That is worth checking out. They're kind of just like -- it's the first API that's like, "Just tell me what kind of input you want for this input." Do you want it to be the one that's really good for zip codes? Well then just tell me and I'll make sure that I give you the keyboard that's good for zip codes, rather than guess because of some pattern attribute or something. You don't have to guess anymore. You just tell it what keyboard you want, essentially. It's pretty sweet.

Dave: Yeah, and that's what I would recommend, the input mode. The support is pretty broad. You can also use the pattern as numbers and mobile Safari will be like, "Oh, that's a number input or number inputter." But you also have to remember, for a zip code, only U.S. is digits only.

Chris: Mm-hmm.

Dave: Other countries have non-digits. They have the alphanumeric … in their zip code.

Chris: Uh, tell me about it. Yeah.

Dave: Some countries have dashes. America, technically, as an 11-digit zip code system with a dash in the middle.

Chris: That stuff alone, I'm just going to use some third-party thing where it's their problem and not mine.

Dave: Wouldn't it be cool if you had a Web Component called Zip Code? [Laughter]

Chris: Yeah, right, as long as it had 5,000+ stars on GitHub is the only way I'd trust it.

Dave: Yeah, 10,00 stars.

Chris: [Laughter]

Dave: Social validation.

Chris: Yeah, for real.

Dave: I paid a … in China to--

00:43:16

Chris: But more like I just want to use the Stripe thing that's just like, oh, I don't even want to -- I don't even want to be responsible for that input. Somebody else do it.

It's not only inputs here, though, but I think he's talking about just the numbers in the HTML. Like a paragraph tag that says, "Dave Rupert's zip code is 1234." How do you get that to read right?

Dave: You know that's -- I think you'd just have to -- you know, I don't know that there's a really good way. I think screen reader users will either be accustom to it in a certain way.

Chris: Yeah.

Dave: It sounds weird to us, the non-screen reader users. But they may just be accustom to it.

Chris: Yeah.

Dave: Even capital Z-I-P for zip code, the screen reader might read, like, how do you make phone numbers and Z-I-P codes.

Chris: Yeah, and you just have heard it 10,000 times. You're like, "I don't care. I get what they're saying."

Dave: You're just used to it. But again, maybe that's even better than just hearing a series of random numbers like six, seven, two, five, three, four. You're just like, "Dude. What happened?" But 62,374, I'm like, okay, now I can group those mentally in my brain. Now I know it was only a five-digit number.

Chris: A credit to James here. He says, "Maybe I'm making assumptions about how different people interpret numbers, but I know I'd be hella confused if somebody gave me their zip code as 62,000-blah-blah-blah." I think that's -- yeah, so you're saying you'd be confused, but you are not the person this is for.

Dave: Mm-hmm.

Chris: Both Dave and you are making a very strong point here in that you just don't know unless you ask or test.

Dave: Yeah. There are also other bailouts. There's a key command to where you can read every individual character. If you heard the zip code is 2,974, or whatever, you could be like, "Oh, shoot. Let me go character-by-character: seven, eight, nine, three, seven. Okay, that's next door. I get that." There are other tools for people.

Chris: Okay.

Dave: Again, accessible text is not just screen readers. If somebody is using a braille reader, they'll just feel the numbers. Don't overfocus on the announcing, but it's important.

Yeah, if you don't put commas in it, that's a big thing. I don't know how you'd trick the screen reader and I don't think it's worth it to optimize the speech of the screen reader. But if you find a good way to, then I think you should use it. But I think what you'll probably end up doing is making a hack that'll have negative ramifications later. You kind of just need to supply the best HTML possible and that's using the right elements, that's using everything, and then the best elements possible and let the screen reader do the best job it can. Don't try to trick the screen reader. That's what I would say. Hopefully, that helps. Probably a bad answer. You can talk to accessibility experts over at the accessibilityproject.com.

Chris: There you go.

Dave: A11yproject.com.

00:46:50

Chris: We have one here from a maybe Swedish person. They wrote in their pronunciation notes. For their name it says, "Pronunciation impossible." [Laughter]

Dave: [Laughter] I'm going to give it to you.

[Laughter]

Dave: Chris, take a stab.

Chris: Well, they guessed that we would pronounce it Jerp-fen-wooden.

Dave: Okay.

Chris: Which is fine. But that's what they said we'd say. So, the actual name is Scherp von Wuden.

Dave: Scherp von Wuden. Nice to meet you, Scherp. [Laughter]

Chris: "I've been a no build tools, no frameworks dev for five years now," and he likes our kind of stuff sometimes when we talk about good ol' CSS and Dave's no build tools rants and the like, which -- [Laughter] you know we do do that sometimes.

Dave: Welcome to the curmudgeon club.

Chris: Yeah. [Laughter]

Dave: Hey!

Chris: I like to think we're fair and balanced. Anyway--

Dave: Oh…

Chris: Ew. I shouldn't have said that.

Dave: Woof!

Chris: [Laughter] "Yet the fields demand I move to frameworks. Hey, let's assume I'm wrong and everybody else is right. I don't want to be--" that's a weird statement, "a flesh made IE." What does that mean? "You throw around the concept of op state a lot but it's unclear to me what you mean by it. I'm sure I've had my share of state." Oh, this is funny. We just talked about state. "I'd use body tags class and other attributes as a global repository for letting the rest of the app know through the cascade what is going on, so I presume I'm missing out on understanding big win for frameworks by not understanding what you mean by state."

Let's not dwell on this, but I do think that it's an interesting concept of just using the body element and just slapping tags all over it to indicate state. Well, that's possible. You could say, on a body tag class, widget 342 hidden, and then that will cascade to wherever it needs to be in the DOM. You could say body.widget242hidden.widget display none or something. I mean sure you could hide your widget that way, but that's not. That's not -- it's still sitting there in the DOM then. It's just like -- that's not how modern apps do it. The state, whether a widget should be visible or not is probably handled somewhere else in a way such that you don't even have to render it in the DOM if it's not there - that kind of thing.

Dave: You know I had a client. When we started building this site they were like, "Oh, customers can be in three states: cold, warm, or hot." Everyone is like, "Oh, okay. Cold, warm, or hot." Cold is not -- you know brand new, very new to the site. Warm is they've engaged with the site. Hot is they've purchased something.

Chris: Mm-hmm.

Dave: We were like, okay, cool. That's great. Then it was like, we can manage that level of state. We are like, okay, yeah, we can do that with a data attribute and we'll show/hide things based on their state. That'll be great.

It was working but, slowly, more state came in, like, "Oh, do they have an account or no account?" Oh, okay. If they've logged in then, yeah, they have an account, so there's logged in, logged out state. Now we have, oh, another set of state.

Then there was another one. It's just like--

Chris: Yeah.

Dave: --"Oh, do they have items in the cart right now?" state. It started building and building and building. The little tricks we were doing to manage state, and even in just the design system, kind of started falling apart. It's worth actually probably we need a more -- ideally, a JavaScript object that says the state of all these things.

Chris: There you go. Right. You need what they call a source of truth. If your app needs to know a particular state, if your answer to that is, "Well, then I go document.queryselectorbody.classlist.contains some state or something," you're asking the DOM what the current state of the app is, that's a big red flag. The DOM probably should never be the source of truth for state for your app. Like Dave said, it's probably, at a minimum, some kind of JavaScript object if not some even more robust concept of state in your app. Sometimes, it's nice if there are really ceremonious ways to change that state that's not as simple as just changing some attribute that you're really being emphatic about how you're changing that piece of state.

Again, that's something a framework might help you with but it also might do the other side of that job. A lot of times they call this Pub/Sub. There are other words for it. But if you change that state, wouldn't it be nice to then tell everybody else who cares about that piece of state that that state has changed? jQuery is not going to help you with that. You know?

Dave: Yeah, it's a lot of listening and broadcasting events and stuff. That's kind of how React works under the hood. You could totally do that and, actually, CSS is a pretty good state manager. It's a state machine. It's like .blue, turn it blue. You know? It's kind of a state machine under the hood.

Chris: Vue is even better because they have a blessed state, global state tool. You know?

Dave: Yeah. In my experience, adding state to the body, it works but then, as the concerns start to grow, you start -- for me, it got, like, I need something to manage this. That's where a framework kind of helps.

Chris: Mm-hmm. There might even be race conditions and stuff when you start messing around with that.

Dave: Yeah. No, I mean yeah. Yeah. A product configurer or whatever, that can get pretty tough, so you have to -- that's a lot of state in there. Maybe if you're a certain--whatever--Patreon level donor, you get new, customizable--whatever--character features or whatever. That's a lot of stuff.

All right. Should we go to the next question that Scherp has?

Chris: Yeah. It can be last one here, I think.

00:53:26

Dave: All right. Last question. "You talked a lot about--" This is still Scherp. "You've talked a lot about SVGs and you staged that modern design tools are better than Adobe products at generating clean SVG code. My colleagues use Adobe." [Laughter] "For our last app, I put SVGs and they only partially rendered when I added more SVGs. I look at the code and it was Verbose. That got me thinking about the cause, besides the point, just code, the SVGs." Oy. "Here's my hypothesis. Aren't SVGs a tradeoff? Initially, you send a little code over the wire but the browser has computations to do. Where the example, a Raster image is large over the wire but easy to render. What do you know about SVG memory consumption versus PNG or JPEG?"

Chris: It's less. I think you're just wrong about that. Yes, it has computation to do, but there is more computation to do with a pixel image. It's got an equal amount of work or more … a Raster image. I don't have any data to point you to, but that's -- whenever you think about memory usage, people are always pointing at Raster images and showing how intense the memory usage is there. I don't really hear that talked about with SVG so much.

Now, there are limits to everything. If there are two billion points in your SVG file, the browser is going to chug on that. But it's like -- there are limits. There is this, again, a balance of everything. You'll know because the SVG file will be four megabytes or something. That's not acceptable for a Raster or SVG, so there you go.

Dave: Mm-hmm.

Chris: You started talking about tools a little bit. I think there are big differences in what the tools output for SVG, but you should never use what just comes out of the tool anyway. Maybe someday that will change in the land of tooling and tooling will kind of compete on the quality of their output. There is stuff. Sketch has a plugin that will optimize your SVGs before it comes out and all that. I still -- whatever.

Just make it part of your build process so that if other people use different tools, it's okay. I think no matter what literal design software people use to make the SVGs or hand-coding it or whatever else, it should go through an SVG optimizing process so that you're just kind of guaranteed that the SVG is as good at it can be before it actually goes out to production.

Dave: Yeah, I use -- my colleagues use Adobe. What I do is I go into Adobe. I select the thing, the vector in Illustrator. I copy it and I paste it into SVG OMG, Jake Archibald's tool. That'll clean it up for me.

Chris: Mm-hmm.

Dave: It usually drops the size about 80% or something. I copy that and I paste it into my project.

Chris: Nice.

Dave: Whether that's CodePen or whatever. That's kind of my workflow. That's what I do. I got my designers all on that workflow as well. It seems to be working pretty well.

As far as the tradeoff, SVGs are just math. It's just a list of points. Computers are really good at math, so I think they can do it. I think, you get into images, you have compression and byte code and there are algorithms it takes to nearest neighbor to fuzz two pixels together if it's kind of small or there's not enough pixels to render. There's a lot of work behind the scenes to put an image, to paint an image of three million pixels onto a page. SVGs are typically just math.

Chris: Mm-hmm. Mm-hmm.

Dave: But that said, you can make a very bad SVG and it'll be really rough. Sometimes, from Adobe, they'll sneak a PNG inside the SVG. We had that on a client site.

Chris: Oh, sure. Drop shadows were notorious for that, right?

Dave: Oh, man. Surprise! The logo is actually just a PNG.

[Laughter]

Dave: We were just like, "What?!" You have to really kind of -- whatever. You have to kind of be a -- I don't want to say Nazi or cop, but you have to really look at the SVG and that's where it might be overwhelming. You have to really look at an SVG and just say, "What's in you?" Does it look good? You need to know the difference between good and bad. Then, eventually, you'll go to the level where you're like, "I'm just going to write this hamburger menu by hand." [Laughter] Because you're a jerk and you're just like, "You know? I know how to write three lines in SVG, so I'm just going to write three lines in SVG."

Chris: Yeah.

Dave: It'll be like eight bytes.

Chris: That's probably your best bet to kind of golf it, as they say, if you can. Golf … just removing characters when you can for the sake of smallness, but I often think of it probably incorrectly, but whatever. Handwriting it because you're going to write less characters than any software is going not do.

You know I heard from a fella at Wikipedia, I think, that was kind of like -- somehow had taken in charge of dealing with the SVGs for Wikipedia. There are obviously millions of billions of jillions of them, right? So, they have a lot of experience with the different tools. It does matter what the tool does and it does matter what the optimizer does. SVG OMG, I think, is a great choice because it uses SVGO under the hood.

I think there are more than two. There are three or four major optimizer tools. None of them are particularly well maintained anymore. I don't think there are any developers working on any SVG optimization tool, as sad as that is to the world.

Dave: Weird. Yeah.

Chris: But they have different approaches. They do different things. They error in different ways. Yadda-yadda. It's kind of one of those things where, if you're really taking this crazy seriously, you should try all the different ones and see what the results you get are as far as the fidelity and the file size and that type of thing.

For example, SVGO, notably, can reduce precision if you needed to. If for some reason Adobe software outputs five decimal places and that's way more precise than you'll ever need it to be in the DOM, it can just wank some of those off, which reduces file size and computational speed and stuff. That's neat but you've got to be really careful with that because if you whack precision too far, it's a fidelity thing.

Dave: Mm-hmm.

Chris: If you zoom in too big, it gets weird. I don't think all of them can do that.

Here's one, too. You have a G element in SVG, you know, just an arbitrary group. Well, that could have a transform on it. Have you ever seen this in an SVG where Abode will be like, "I'm going to take this G and transform it a thousand pixels to the left."

Dave: To the left, yeah.

Chris: Then for some reason, the path inside just transforms it back to where it was.

Dave: Yeah, all the paths inside start at 100, 100, or whatever.

Chris: Yeah.

Dave: They all start -- yeah, rather than….

Chris: There is no optimizer tool in the world that can sus that out. It's just going to leave it alone.

Dave: Yeah.

Chris: Yeah, so that's unfortunate, too. That's one of those things where the tooling then also matters, in addition to the optimizer that the less of that going on the better. You know?

Dave: I was going to say, Brenda Storer has a really good talk called "Cracking the SVG Code" where she explains path attributes and stuff like that and how to make an arc and stuff. This unlocked everything in my brain. I just was like, "I understand what's going on and what those letters and numbers mean. It's not just dark magic to me anymore."

Brenda Storer, a really good talk called "Cracking the SVG Code," and Sara Soueidan is also another one if you just want the full technical low-down on SVG. Talk to Sara.

Yeah, hopefully, you have good luck. Again, I would say SVG is fast when you can use it. It's just math. It's just math.

Chris: That's killer and high-five, Brenda.

Dave: Computers don't care.

Chris: I was also at that talk and it was very good.

Dave: I've never heard anyone explain it to me in a way that made sense, and this was it. It was like, "Ooh, I get it now! I understand."

Chris: Yay!

Dave: All right, well, we should wrap it up. Thanks, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

Head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris: People like you!

Dave: You! Chris, is there anything else you'd like to say?

Chris: Oh… real quick, if you are into that dual-screen stuff that Dave was talking about, he got a little bloggy about it and there are two great posts on daverupert.com about that.

Dave: Oh, yes. I blogged. I'm a blogger. [Laughter]

Chris: ShopTalkShow.com.

Dave: I'm a blogger. I'm a blogger.

[Laughter]

Chris: My beard just grew out a little bit here.