“I myself do not believe in advertising and use AdBlock”: an interview with the founder of Smashing Magazine

Many here are already familiar with Smashing Magazine - a site for web designers and web developers. They also publish books and hold Smashing Conference conferences .

With an attendance of about 5 million per month ( 10 times less than that of Habr , but nonetheless ), he is one of the leading online publications on web design. An interesting feature - if you go to the main page of the site, it detects the included AdBlock , but does not prohibit browsing the pages - instead it modestly hints that it would be nice to buy some kind of book. All those who promoted the idea that the popular site could not survive without a lot of advertising, now tensed :-)

We interviewed one of the founders of the site (and the speaker on HolyJS ) - Vitaly Friedman. We will talk about the history of the site, its technological stack and development process, miracles with the ability to use AdBlock impenetrably , as well as plans for the future.

- Vitaly, welcome! You are the chief editor and founder of the rather famous Smashing Magazine. Can you briefly tell how you came to such a life? How did you find yourself on the web, why did you decide to start your project and was there something of your own before Smashing Magazine?

Vitali : The story is quite simple, there is nothing special about it. I just worked all the time. I was born in Minsk, and when I was 16 years old, my parents moved to Germany. Back in Minsk, I started writing small articles, experimenting, twisting, watching what can be done with Flash, HTML, and so on. And when we moved to Germany, everything was very simple: I needed money. I studied at Computer Science and Mathematics, and we had one project at the university where a webmaster was required. And, since the money was needed, I decided, why not participate. In the end, I started spinning, spinning, even deeper into web design. And then, as I graduated from the university, despite the fact that I always wanted to be a backend developer, I realized that this was not entirely mine, because the PHP code that I wrote was, say, completely bad. And I decided to quickly reorient myself and go to the area that interested me most. I went to CSS, to the front end, for six or seven years I was a freelancer. Then we created a magazine, because I needed some kind of resource for finding equipment and tools that I could use in my work. Very quickly, we discovered that I was not the only one; there were many people who were spinning in this area, they also tried to find something and could not. Then I spent an insane amount of time writing articles. The most important principle was that we decided to publish at least two articles a week for one year. It was such a commitment. At that time I was still at university, so it was hard. Articles are often written in cafes, at night, in between examinations. But all this was serious, and so Smashing Magazine appeared.

- How was the technological stack of the Smashing Magazine platform chosen for the first time?

Vitali : Initially, he was not chosen at all. I worked with a colleague who already had a magazine in German, he used WordPress for several years, so we just took this platform without thinking. We chose a random topic, there was no logo, we just started publishing articles. That is, they did not sit and did not think whether to choose WordPress or something else, it just happened so historically.

- New Smashing Magazine - it is still at the stage of running.

Vitali : He is almost ready, we should start soon. We will have a slow rollout, which means that we will gradually open access to an increasing number of different headings on the site. Now we have a stable, good, working version, there are a few bugs that need to be fixed or covered, there are not so many of them, so we want to launch everything very soon. Let's see what happens next.

- You have a rather large portal, this is not a move to some kind of new engine or some kind of trivial update. You are doing a completely new design, a new architecture, a new UX, a new workflow. What was the reason for such a global change? Who initiated - managers, techies or marketers?

Vitali : This is a very good question. Usually I am a big opponent of “big bang redesign” in design, I always resisted it and wanted to develop projects with small steps rather. In this case, we had to do this because there were financial reasons for that. Not because we are bankrupt and so on. But if we compare the number of people who use AdBlock, as it was in 2012, when we laid out the previous redesign, and how everything developed over time ... Advertising gives us 1/16 of income compared to what we earned in 2012-2013 . Again, this is normal, because about 60-65% of our readers use AdBlock. I myself do not believe in advertising and use AdBlock. There are reasons for this, but I think you shouldn’t go into details, everyone already knows this. But for us, this meant that since most people do not see ads, we had to figure out how to sponsor the site in a different way. We have several principles, one of them - all the people who work on the site should receive a salary: every editor, author - everyone should receive something for their work.

And we started to think about it. This was not a global problem. In our case, quite early, back in 2013, we began to think about what alternative ways of earning we have or may be. For example, they created a conference, workshops, trainings, consultancy, books, e-books, a job board and so on, it was all in the process. But it was not exactly what we would like. We wanted to build some kind of stable foundation. One of the ideas was a subscription. Subscription on which people get some buns for 2, 5, maybe $ 7 a month. I do not believe in Donat, in the fact that donations can give a stable profit in the long term, and I do not want to rely on it. It is important for me to present a product in which people see some benefit for themselves, therefore not to introduce these membership fees, to say how good we are, how we have worked well all this time, and then demand money from you - I did not even consider this opportunity . Therefore, we decided to create a new product, which would be, in fact, a subscription, which would include various useful things, such as webinars, product discounts, MailChimp, on things that people already use. In addition, Smashing TV is a video broadcast of conferences or interviews, “Ask me anything” sessions, a rather large set. Smashing Magazine Print is print publications, Smashing Books. Like a mini-book that will be published three or four times a year. In this project there are many different things that make it, I hope, an interesting, beautiful product. What will change? In the old design, we really did not have the opportunity to show this product, the old version of the site looks like a blog. The only thing we could do was put some kind of ad unit, and we will have a membership. But in our case, this also includes the Options and Features panel. It has to do with everything we do. That is, if you have a membership, you get discounts on conferences, workshops, webinars, job postings, e-books. Integrating membership into each of these systems was very, very difficult. By the time we had job ads placed on Ruby, a fairly old platform specially built for us, the magazine was on WordPress, the Shop was on Magento, then moved to Shopify. All this is difficult to integrate. It would be necessary to create a system where it would be necessary to integrate the subscription into the Job Board, and in the Shop, and in the Magazine. If, of course, you have the opportunity to leave some comments, it turns out highlighting, when you buy an e-book, you should get a different price, because you have a membership, it's all very dreary and difficult.

We decided why we should not try to look at this problem from the other side. Why not use this opportunity to think about what “smashing” means, Smashing experience, to create a membership with an intellectual product in this whole new redesign. And so we decided to think about how to make a new platform, a new system, a new single technical stack, in order, first, to find out what “smashing” is and, second, to build a uniform UX where you start your journey where you finish, that is, to always everything just passed. I understand that this is a very long answer to your question, but it seemed like a reasonable option: let's sit down, think over what “smashing” means and how this whole thing can be built, what is needed for this, and we will build it in the end. Of course, we thought that we would cope by the 10th anniversary, but we did not even have time for the 11th anniversary. And now, after 16-17 months of development, design and tests, we are finally able to launch it.

- If you go back to the very beginning, to the selection process, I would like to clarify: from a product point of view, everything is clear and transparent, but from a technology point of view, how did you choose the new stack? It is clear that it was JS, but inside JS there is also a large framework-zoo: by what criteria did you choose, what did you see, what did you refuse? How did you come to this stack?

Vitali : I would not say that it was a long process. In 2012, I met Matt, who was then working in Spain. He worked on various things, including various commercial projects, portals, and had his own Web Design Agency. At some point, three years later, he came from San Francisco, opened his start-up company Netlify. The Challenge was what it would be like if we returned, from the point of view of philosophy in architecture, to where we started. Initially, we just had a server, we had a browser, there you get pages from the server, and everything is ready. And we thought why then simply not to create “ready-made” pages with HTML / JavaScript, we just put them into the CDN, invest a lot of resources to make a good, smart CDN, use all modern technologies to speed up the return of data from CDN (HTTP (2, server push, and so on). And distribute it to users who are nearby, and then, in the second step, suppress JavaScript for interactive elements, such as comments, notifications, shop, check out. Through the Stripe API, through its API or through third-party APIs. The basic principle is to go to serverless and not use the server at all, because everyone has probably encountered such a problem as an Error Establishing Database Connection in their life.

I was intrigued by this idea when I heard about it, and even before the redesign began, we began to think if we could somehow accomplish this, is it possible to do something at all. It sounded pretty cool. Matt made a couple of demos, took a couple of articles and ran them through his CDN, via Netlify, and we found that the pages load six times faster. It was very surprising to me. That is, the rendering time (we are already pretty optimized, I would say, we are trying to do everything as it should), but I was just in shock, because on average we reached 400-500 milliseconds in start render time .

Of course, it’s clear why: all HTML, everything is generated statically, and then the data goes to the CDN, then you still get the CDN data, then you add a little JavaScript, it sounds pretty simple, and we decided: "Why not try?". Honestly, all decisions about which framework to use or not to use were related more to what the Netlify team and our team are familiar with. At that moment, Preact seemed to be a rather convenient architecture, because everyone who worked on this project, who worked at Netlify, with us, knew this architecture, Redux, React, and everything. We just decided to try it, test it and see what happens. That's how it turned out. That is, we did not make decisions not to use Angular or something else. The team just knew React, and we decided, why not try.

- The base is React, but there is a bunch of all the technologies that you have taken yourself to do all the " smashing ". And there is an understanding of how much is enough? What do you think, when will you do the next redesign?

Vitaliy : I hope that not soon, because I can't see this page anymore. In general, I think that the system is quite stable, there is a lot to build in it. We use Preact, not React. Perhaps this choice was a mistake. At Preact, many things that could have been done quite quickly on React, we have to partially rewrite manually. Depending on how the site is developing, how Preact will develop, we may be rewriting for React, although this is not such a big step, as I understood. I myself do not write JavaScript, to be honest. And so even better.

As far as I understand, the transition will take some time, but it is not terribly difficult. On the other hand, I hope that what we have built has a fairly decent architecture. There are some bugs that need to be fixed or corrected, problems that need to be solved. In general, we have built quite complex things that we could not do on the basis of what was. I hope that in a couple of years I will not have to redesign. Hopefully enough for 5-7 years.

- Just a normal life cycle. Regarding the time of the process, you have already said that everything was delayed for 17 months. You can orient on a team - how many people do this? Designers, developers, managers?

Vitali : I want to explain why it took so much time. We wanted to launch in September 2016, worked hard to make it happen. We missed this deadline because we had many other, higher priority projects that needed to be dealt with. The team was very small, so projects such as, for example, conferences and book publishing, took a very long time. In general, at the beginning of the project there were 10 people with a variety of responsibilities: from animation to performance and React. Most of the project involved the guys from Netlify: Matt and his team. This project allowed them to show what they can do. Our team included Dan Mall (Dan Mall) - chief visual designer, Sarah Soueidan - main front-end developer, but she only worked until February, she had other projects, after that we worked with Ilya Pykhalsky from Minsk , we know each other a long time ago, we met, it seems, at a conference in Ufa. He works (or worked) in EPAM and is also involved in other projects. I don’t know what his particular hobby is EPAM or Smashing, but he’s a cool JavaScript developer and he also deals with React.

Honestly, most of the CSS I recently wrote myself. There is an interesting CSS, but I try, of course, to follow the fact that a lot of code was written 16 months ago, a lot has changed, the CSS Grid Layout came out, the Payment request API has changed, and therefore every time is like a race against the mills, it’s always that something to update and change. In fact, in the past I would need to do CSS refactoring. It will be necessary to do this next week. In general, we have a very small team, two and a half people who are constantly engaged in this, project manager Marcus does our SEO and a lot of other things, including finance. I would not say that this is a big team that has been involved in the project for 18 months. This is a small team that was engaged in this project abruptly.

- What has happened to be done relatively easily during these 18 months, and what were the problems?

Vitali : I did not expect that there would be so many problems with accessibility. At first everything in CSS was very clear, cool, as needed. But when we started adding all React chips, when we discovered that there are states, we need to put content back and forth, change here, etc., we had to write a lot of JavaScript for accessibility. Now I would say that the checkout script does not work for us at all, there are also moments that I need to refactor. I would not say that problems with CSS were difficult, we easily solved them. Layout itself is quite complicated, but since we solved this problem, everything else was simple. There was not even a javascript issue. The only problem that we did not expect and which took a very long time to solve was that membership is the central element of everything. We need to look, log a person, make him an account. Authentication without a server - you need to do a bunch of APIs: authentication, commands, job board, because everything goes through JavaScript. We also separately use Go for management, admin, orders and so on. These things took longer than we thought. I would not say that this project was monstrously complex from an architectural point of view. It was necessary to solve a couple of difficult moments, and that was, rather, after finding bugs.

- That is a normal development process. What will happen next with the project? Will the concept of membership continue to evolve? A classic interview question: how do you see yourself in five years?

Vitaly : I can’t say exactly, because I don’t know what will happen in six months. It all depends on how the project goes. We made full membership, a lot of things are connected with it - webinars, various kinds of campaigns, campaigns, content campaigns, conferences, etc. I hope that everything goes well, and then we will have a good foundation on which we can build anything. In technical terms, if we can master, there are so many different ideas that I’m still looking for, what we are working on. Especially in terms of education. This is not what create Treehouse or lynda.com. I believe that it is important to have the opportunity, the physical place where you can shove people involved in education. People who are engaged in CSS, JavaScript, frontend, backend, who can teach students what they decide in practice. Need a physical place where this could be done, like Smashing University, maybe. Something like that. Traditional education, unfortunately, is far from optimal in this regard. Membership for us revolves around the community, so I think it would be very good to do something like Smashing School in terms of education. Many firms need front-end developers and designers, and many students want to go into this area, so it would be very cool.

- Beautiful plan! I hope everything works out with the membership and school. Thank you very much!