 Hello, everyone, and welcome back to the state of the web. My guest is Andrei Sitnik, lead front-end developer at Evil Martian and creator of many popular web development tools like Post-CSS, Auto-Prefixer, and Browser's List. And today we're talking about developing for a global web. Let's get started. All right, so Andrei, thanks for being here. I mentioned in the intro that you're the creator of many popular web dev tools. What was your motivation for creating them? The first tool, which I created, become popular, was Auto-Prefixer. And it was a few stories behind the project. And one of the reasons was that I'm originally from Russia. And in Russia, there was a very popular browser called Opera. But unfortunately, people outside of Russia and Norway didn't know about this browser. And as a result, they didn't support it. I mean, not like testing this browser. I mean that completely ignore that this browser exists, like avoid the prefixes I'm talking about, CSS vendor prefixes when you need to write, like, dash webkit, dash border radios at the moment. And they completely ignore the all prefixes. It was maybe not so big deal because all these properties was mostly about visual stuff. But it was not so great when you're using a website and they're just avoiding, don't knowing about some browsers. And especially, it's become more sensitive during the mobile development when Safari browser was extremely popular. And people just start to ignore all other browsers, like avoid unprefixed version, like writing only webkit border radios and not just border radios. And all these prefixes become very, very crazy. And as a result, it definitely should be solved by some automatical tools because it is very hard to teach people about all these best practices. It's sometimes better to just give them instrument which will care about it. So what is the user experience like for somebody visiting a website that is not developed with a global mindset? The main problem, maybe it's not like the real support because, you know, if the website doesn't have around our borders, it's not a big deal. Main problem was when websites just block your browser. Like they check user agent and just show this browser is not supported. Especially, it's a big problem right now when we have a lot of Chromium browsers and it works very similar to the Chrome. But unfortunately, still a lot of browsers just a lot of websites just block them. And of course, it's not so great. And it's beyond just a problem of not translating into somebody's language. There are other things like the date and time that are not formatted for somebody's own locale or even like first and last name fields. Do you have an example of any of these things? Yeah, I understand that if you will translate your website, it will be better. But I understand how big it is a problem. It's not a problem just translating messages. It's a problem that you need to create a community which will update the interface. And it's really hard, for instance, GitHub tried to do it, but they decided to not going there. And I completely understand it. It's a really hard problem. But sometimes, it's not a problem to use English websites. It's not so big problem. At least you can use a translator in the browser. But the main problem is when the whole interface works very well with your culture. Like my favorite example is the name field. Like a lot of people I create first name and surname or family name. But unfortunately, it doesn't fit the reality of the world. It doesn't fit even a Europe because in Europe, we have countries without a family name. They use only father names. And we have countries which use only one name sometimes. Or my favorite example, in some countries, these people with a name only with a one character. It could be like a Chinese character. Or even sometimes they just one or two or three English characters in translation. And websites just show them your name is too short. But that's my name. Unfortunately. Yeah, this is a problem. And so if you are creating a website and you need a name, just put a single field, people will figure out how it works. What they should put inside. So is the global mindset something that all websites need to consider? Or does it only affect people who intentionally try to target a global audience? I understand that sometimes developers are creating websites that are very local. I don't know, some website for university. But even in this case, we can remember accessibility. In accessibility, we have a lot of rules. But this rule is not important for the people who need stability features all the time. Sometimes every person needs some of accessibility features. You can have a very light sun on the street and can read the message or like it's to know the outside. And the same with thinking global. As I mentioned, there is a lot of people in Europe which doesn't have a surname, family name. And as a result, when you're making a website, it will be definitely people from these countries like living in New York, because like their parents came there and they will have a problem. So I think thinking global is very important for any website because it makes our solutions more flexible and flexibility is always better for the business. Because when you're creating a website only for one browser, I don't know, next time Apple creates a new browser and your website creating only for Safari wheel browser. But if you're creating it for any type of the browser, it will be automatically updated with new release of the browser. Even for a website that looks at their analytics and says 100% of my users are on Chrome, so therefore I don't need to develop for any other browsers. That could be a logical fallacy if their website is inaccessible to users of other browsers. So there's some survivorship bias going on there. It's maybe when we are thinking about short term, it may be a good idea. But if we will talk about not technology, not something being good, but just about the business, it's very important to also sometimes think about the long distance. I need to have a balance between short term and long term. And we should always remember that all the problem of Internet Explorer 6 was not because it was a bad browser. In that moment it was one of the revolution of browsers in the world. The problem was that we start to support only these browsers. And as a result, we will have the same problem right now. If we will support only Chrome, we will focus on the single browsers, it starts monopoly. Monopoly always leads us to stagnation. This is like a common rule. And stagnation in the end will affect your business. You will have a longer time to deliver a feature and this is very critical for business. And so I think about supporting all browsers. It's like for a ship company to support lighthouses. It's not looking as a part of the business, but if you will not have a lighthouses in your country, your ship business will go very bad. And same with the browsers. We need support browsers just to have a nice, easy-going business in like 10 years' perspective. I like that analogy. I want to go back to auto-prefixer. You mentioned how it adds these vendor prefixes, but it's 2019 now. Is this still a big problem that developers are facing? To be honest, I think you can safely remove auto-prefixer in the next two years. Maybe you should not do it right now because there is some prefixes which should care, like I don't know, user select or selection, which is very widely used. And also there is a lot of small Chinese browsers which you should care about and they still need prefixes. It's not a big deal to auto-prefixer. But even in Chinese market, like UC browser is growing very fast and it has a very modern WebKit engine inside. So I think it's not, it will be not a big deal in the next two years. And so, yep, year after year, you should definitely think about removing auto-prefixer. Could you describe how browsers list works and how that plays into the global web? Yep. I found that when we ask a developer to select, like, auto-prefixer, it inserts only actual browsers, not every, not inserts only actual prefixes, not all prefixes. And as a result, we need a list of the target browsers. And all companies, they have some sort of the listings, not maybe in the file, but maybe in speaking to each other. The main problem that when we ask developers to write the target browsers, they will be focused only on browsers which they know. And definitely they will ignore Opera Mini or UC browsers. Maybe not because they don't need to support it. For instance, Opera Mini has more users than desktop Firefox and desktop Safari together. It's very black market or UC browser. It's really huge. But a lot of developers just don't know it and just know of it. It's okay, but it's a problem of developing experience. If we want developers to not remove unknown browsers, we should use a very different user interface to select a target browser. And this was a reason of creating a browser list. In the browser list, you describe a query like some sort of more common way to describe what browsers you need to support. For instance, the last two versions feature browsers or not dead browsers, which doesn't have security updates or maybe bigger than 1% in my own statistics. And so browser lists do all this stuff. And it's used not only after prefecture but also in the baby and a lot of very interesting tools like PostSS Normalize or PostSS Preset Env. So we are thinking about the browser list and the single source of the truth about your target browsers. Not only for the tools, but maybe sometimes for developers, for the people when you have a new junior developer, if we will widely use browser list config, he or she will know where to go to check what is the current browser. And it will be much better to not spend your time of asking do we need to support Internet Explorer. Right. So you've described PostSS as a tool for tools, one of which is RTL CSS. Why is RTL so important? I will start talking about the PostSS to then describe RTL CSS. So PostSS is a framework to make CSS tools. It was created when I understand that when you're making CSS tools, there is a lot of common, like you need to parse CSS, you need to generate source maps. And I wanted to have a more diversity in CSS tools. I want maybe not just in CSS tools, but in CSS itself. So I wanted a lot of the people to suggest new idea for the syntax to create a polyfill to test it in the real world. And then when we have a real experience, suggest it to CSS working group. And so it was a framework to teach people to create a very different solutions. And RTL CSS is definitely one of my favorite example about what you can do with PostSS. RTL CSS is a tool. No, I need to start from linguistic. In some of the countries, like Arabic countries in Israel, people writing not from the left to right, but from right to left. And language affects a way how you think. And so writing in different direction affects how you think about the space and time. And as a result for them, the time going from different directions, the future is on the left hand. And same like the most attentional part of the web page will be in the different direction as different part. And as a result, we need to mirror the whole website. We need to put many from one site to another. We need to put a progress bar to a different direction. And RTL CSS is doing all of this stuff without changing your code. There is a very nice example in RTL CSS documentation when they just took a compiled CSS of GitHub, processed it, and create an Arabic RTL version of GitHub. It was a very nice example. So what are some things that developers can do to change their mindset and to think more globally? This is a good question. Of course, the main reason is not about that everyone must think globally. Because I understand that people don't have a time. We have really a lot of things to think about. And to make your site global, you need to do only a few simple things. For instance, don't block unknown browsers. If you see some browser in the browser list output, don't remove it just because you don't know it. Try to not remove Opera Mini if you don't really not sure that your website completely can support it. Or for instance, if you want to make your bundle smaller, don't cut all that Chinese browsers with old prefixes, just create two different bundles. One for yes models and it will be very small browsers for modern Chinese browsers for Chrome and Firefox. And the second one will be big for all other browsers. So it's not something really that you should learn every day making a website global. Just don't cut ways for other developers. But be think more global. Try to be curious about other countries. It's better for you as a developer. Because there is a lot of interesting idea around the world. For instance, the adaptive design was created in Russia by five years before it was created and become popular in the United States. Or for instance, in China right now there is a lot of interesting experiments about technology. And the American company already started to copy this as a startup. So it definitely will be better for you to know how it works in the global world. Because as a result, you will be the better developer because you will copy this great idea. What I can suggest to do it? First, I think it will be very better for our community if we will start to mix people from a different conference. Because right now there is a western conference and western speakers and they are together. And now in big countries there is local communities. And there is no so much movement between these two worlds. My biggest point that people from the small local community should go to the western conference and this will be very interesting part. I understand why they are not going there. They have a lot of great ideas. They have a lot of great talks. I don't know. You can just describe how the software is developing and working in your country and it will be a great talk. I'm really waiting for a talk about the Russian design on some western conference and about the Chinese way to do it. I don't know about how Arabic countries do all these RTL-CSS stuff. It's really interesting. But a lot of the people, a lot of great speakers in the country, they are afraid they are accent. And I completely understand them. But there is very interesting and very simple solution. If you're afraid of your accent, you just should put everything that you need to tell to your slides in the text. As a result, even if people will not understand what you're talking about, they will read it from the slides. And it's not a problem because of your accent. It's also a problem that people on this western conference in the center of New York, most of them will not be native speakers. And maybe your English will be better for that they are English. So putting everything on the slides is a good idea. So then you will not care about what you're talking about. And your voice will be just emotional addition to your information. And it will be not a problem with having a very strong accent to make your presentation. So the first idea is to mix in speakers. But the second idea is maybe more tricky not maybe about the globalization itself but about the diversity of ideas. Especially right now on JavaScript when we are all creating a reactive websites just because we are afraid to be blamed using not popular solution on some meetup. It's definitely not a good way to make... Resumé-driven development. Yeah, definitely. So we should promote smaller solutions. We should not focus on the one solution for everything. I have a rule to think twice if I want to retweet a very popular person and think less if I found interesting tweet from not popular user with less followers. And retweet some crazy interesting idea right now very interesting project called that protocol. It's a protocol to creating a new type of web protected from the censorship and also protected from all these privacy issues which we're having right now. But also there is a very nice idea of new way to making a website especially with bad internet connection. It's called Local First. It uses a very new... technically not a very new but very interesting and difficult idea called CRDT. It's not the only thing that they use like Local First is the idea that you have a database, some sort of database in your application. And instead of sending crew requests you synchronize this database with your servers. And as a result if internet is bad you can still work on your mobile application just wait a little longer until you will be sure that everything is synchronized. And so a few people creating can manifest about this way to make an application called Local First and they definitely promote it. And even right now I'm not spending so much time on Post-SS to spend more time of creating frameworks to this idea. Right now I'm creating Logax frameworks. That's great. Finally would you recommend any resources for people who want to learn more about these tools? This is a good idea I definitely recommend Manifest of Local First. It's very good idea which everyone should know about. I definitely recommend to look somewhere outside of React frameworks. Definitely recommend to look into Svelte framework which is really great and React which is very compatible with React but much better performance. It's just an interesting idea to go out of the box. And also I think we will put a link to Twitter of the people who are talking about the conference in China and other worlds where if you are speaking it definitely will be nice idea to go because it is completely new world with new ideas. It will be very interesting. And how could people find you on GitHub? My GitHub is AI and in Twitter I am Sydney Code. Great. Andre, thanks for being here. This has been great. Thank you for your question. So you can find links to everything we talked about in the description below. Thanks for watching. We'll see you next time. Bye.