On-site running and web development
Hello!
Now I will tell you a strange story. Once, I lived in a condo in which, on the ground floor, there was a fitness room with treadmills. In my youth, I was actively involved in sports and then I managed to get to know the state that arises while running and is called “second wind”: this is when you suddenly begin to feel like a winged deity who does not know fatigue. Breathing, palpitations and body movements enter into a special resonance, and turn you into a running machine. The feeling is the brighter, in my opinion, the more you did NOT like to run up to this point. So, every day I walked past the treadmills and thought it would be good to remember the youth. Well, I remembered. The treadmill helped a lot with this, it allowed us to fine-tune the pace and achieve the desired rhythm. On the street, I can not do this: to run at steady speed through the city is very difficult, the terrain and obstacles interfere. After some time, I moved to a regular apartment (without a fitness room), and began to think about purchasing my own treadmill.
Yes, of course, one could simply buy a subscription to the nearest sports club, but I, like many of my IT colleagues, are a social phobia. If not even a sociopath. Exercise for me is an intimate process. Well, it was also tempting to use any free minute for training: “health is a geek” and so on ... In short, I looked through the offers of online stores, read reviews, wondered how much you could spend on this business, how to solve the issue with noise and where to put this rather big bandura ... Then the usual jump rope fell into my hands, and I said to myself: well, here it is, a good option for cardio workouts without too much hemorrhoids! All you need are high ceilings and ... Nothing worked out: in order to jump on a rope, rhythmically and evenly, you need to be able to do it. Go back to the treadmill thoughts or ... Wait, why not just try to run on the spot? Oh, somehow TOO simple and stupid. But I tried. And you know what? It's great! The sensations are practically the same as what I experienced on the treadmill, but everything is much simpler: you catch a fitness bracelet on your arm, you put on headphones with sausage music, you turn on the timer - and go! Yes, there are nuances, but believe me, they are insignificant. As a result, for some time I have just been a fan of this topic, so much so that I want to join the sect of these same crazy people. You ask me: what are you talking about, how is it all connected with web development? Yes, there are nuances, but believe me, they are insignificant. As a result, for some time I have just been sick of this topic, so much so that I want to join the sect of these same crazy people. You ask me: what are you talking about, how is it all connected with web development? Yes, there are nuances, but believe me, they are insignificant. As a result, for some time I have just been sick of this topic, so much so that I want to join the sect of these same crazy people. You ask me: what are you talking about, how is it all connected with web development?
Consider a popular technology stack for modern frontend development:
TypeScript + LESS / SCSS / PostCSS + React + Redux / Mobx + Webpack
De facto, this is now a standard. It is easy to be convinced of it, analyzing vacancies. Any new project in the current year, with the highest probability, will be launched with a similar list under the hood. This is such a good set of time-tested treadmills . Let's go through this list together and see what remains of it if we use the "Running in place" approach.
Wonderful stuff. Anyone who has written something serious for the web will understand this. Often in articles about TypeScript for beginners, giving examples, they talk about some very simple and trivial things, such as passing typed arguments to a function or the vicissitudes of casting types in JavaScript, from which you are saved. But TS capabilities are bigger and deeper than type checking at the compilation stage, it can lead the developer "by the hand" throughout the project, prompting and not letting it slip again. But TS has drawbacks: it does NOT work in a browser without transpay and its syntax is, so to say, “dazzled” in the eyes. When you work with a frontend, your workflow often involves checking how your code runs in the browser, you need constant access to native runtime. Loss of time to rebuild a project to show changes collectively, they can be colossal. Even if you have everything you need is cached and optimized. What to do? My option: use JS + JSDoc. Yes, the TS static analyzer supports the formatJSDoc . At the same time, you see your code in the browser directly and use the benefits of civilization. Blocks describing types and other hints are not mixed with the code and have obvious boundaries, which, personally, helps me a lot to read the code diagonally. If you are using VS Code, you can try this approach simply by adding the line // @ ts-check to the top of your code. If you need support for outdated browsers, a compilation from ES6 + is, of course, still needed, but now only for the production version. As a result, you simplify debug in runtime (from which the absence of errors and warnings during assembly will not save) and save a lot of time.
From this set, my favorites were LESS and PostCSS. I liked LESS for a more “native” syntax and the relative ease of the necessary dependencies for the development environment. PostCSS helped create all sorts of tricky tricks with SVG and keep track of the prefixes. The disadvantages, as in the previous paragraph, I would call the need for constant recompilation. Well, the dependencies themselves. However, in our 2018, we have such a wonderful thing as native CSS variables! This is an extremely powerful thing that no preprocessor can compare to: you can override your variables right in runtime! This opens up a whole world of new opportunities. For example, you can very simply, on the fly, change the themes of both the entire application and its individual blocks. Literally, the user can click on the skin for the application with any color-picker and you do not need to keep separate packages with pre-compiled styles or make your JS add-on with additional logic. And much more, more subtle and specific. I choose native modern CSS. But if you need to support IE11, thensorrow .
React brought us a new concept of modular decomposition, which very well fit the needs of client side development, because the structure of the components repeated the structure of the presentation, simplifying perception and bringing order to the heads of developers. That is why, in my opinion, he became so popular and thanks for that. However, now React is more and more cluttered with the properties of a cargo cult: people start dragging it into projects only because “everyone is doing it.” And this is terrible, because the engineering choice, especially in such an important issue, should be as conscious as possible. And for awareness, you need to understand that React is full of flaws. For me, this is, first of all, the fact that it is too thick an abstraction over the native DOM and brings in a huge amount of its own specificity, with which you want to understand instead of solving problems directly. This is especially felt and depressing if your tasks are a little less trivial than trite molds. On this subject, you can talk for a long time, remember JSX, VDOM, and so on, but for us the main question now is: what is the alternative? No, not Vue. And not, especially, Angular. For me, these are web components: a set of standardsCustomElements + ShadowDOM + ES Modules + HTML Templates . Why? Because these are standards supported by the web platform itself, not meta-platforms and JS-add-ins.
You can break your code into neat blocks and organize it as your heart desires with the help of native modules. Yes, modules are supported by all modern browsers and you don’t need rebuilding during development. Yes, in the modules you can separately store and styles and templates. Yes, for these files you can specifically enable syntax support and work with them as with native HTML and CSS. The life cycle of web components will help you organize render and updates without unnecessary parsing and changing the structure of the DOM. ShadowDOM will allow you to get rid of the cumbersome BEM and not worry further about the encapsulation of styles.
ShadowDOM is transparent to CSS variables and allows parameters to be passed in from any proper nesting level. This allows you to experiment with parametric design and do many other tricks. The web components fully work with the usual DOM API, while being full HTML elements: all standard methods are in your hands. You can use custom attributes to pass parameters and customize the display (although, unlike React, you can not pass anything except strings and boolean values, but for me this is not a problem at all). Your code will be easier and faster. Believe me, I have been able to compare. Some sadness: for most users, everything will work natively, but some will need polyfills.. If your statistics and target audience, mainly about modern browsers - feel free to dive into this topic, it's worth it.
It's harder here. On the one hand, there are a lot of articles listing the advantages and disadvantages and comparisons of various approaches to the storage of states. And to get to the specifics - you need a specific case. So it turned out that this topic has been haunting me for quite some time now: I come across quite complex tasks in working with complexly structured data. Well, in general: data close to reality are never simple in practice, conveniently normalized with a clear universal hierarchy. Most often this is some tricky graph that requires you to initially lay in the system the maximum flexibility. In this matter, I am an adept in cycling, but I will not begin to recommend my way indiscriminately to everyone. What I can definitely advise is not to disdain the basics of modern computer science, to read something popular science on graph theory, set theory, chaos theory. Moreover, I am not talking about some kind of hardcore: the most common ideas can be very useful and “clear the brains” in the right way. In the simplest case, you can quite well “on your knee” write your own repository of states with blackjack and subscriptions, and this will be no more difficult than digging through the documentation of popular libraries.
Abandon the build system completely, of course, we can. But the rezolving of the import chain in the real-time code is not the fastest. Therefore, we still need the bundles for the production version. Well, any minification / obfuscation, again, and compact daddy dist ... Therefore, Webpack - leave. But we need only a couple of modules for it with minimal configs, and no watches and rebuilds for the development process. Personally, my build config looks very compact and does not require a large number of dependencies. Recently, I often hear about the new Parcel assembler, and I am very impressed with its minimalist concept, but as far as I know it doesn’t work with ES modules, and in my opinion, this is a file. I hope this will change.
I often hear the opinion that if you write “on vanilla” - you will inevitably encounter the fact that your project will soon turn into an unsupported mess with noodles. Let me parry: firstly, if desired, porridge can be prepared from the reactor with redux (I have seen enough of it). And secondly, everything will be very good if you use modules, JSDoc and good OOP practices. So, what we have come to:
JS + CSS + Web Components + Webpack
Of the five “treadmills”, we have only one, essentially lightweight. And this is enough to feel the “wings behind his back.”
PS I am by no means arguing that my approaches will suit everyone. I ask to regard this opus, at least, as an occasion to think about what seems to us self-evident.
Now I will tell you a strange story. Once, I lived in a condo in which, on the ground floor, there was a fitness room with treadmills. In my youth, I was actively involved in sports and then I managed to get to know the state that arises while running and is called “second wind”: this is when you suddenly begin to feel like a winged deity who does not know fatigue. Breathing, palpitations and body movements enter into a special resonance, and turn you into a running machine. The feeling is the brighter, in my opinion, the more you did NOT like to run up to this point. So, every day I walked past the treadmills and thought it would be good to remember the youth. Well, I remembered. The treadmill helped a lot with this, it allowed us to fine-tune the pace and achieve the desired rhythm. On the street, I can not do this: to run at steady speed through the city is very difficult, the terrain and obstacles interfere. After some time, I moved to a regular apartment (without a fitness room), and began to think about purchasing my own treadmill.
Yes, of course, one could simply buy a subscription to the nearest sports club, but I, like many of my IT colleagues, are a social phobia. If not even a sociopath. Exercise for me is an intimate process. Well, it was also tempting to use any free minute for training: “health is a geek” and so on ... In short, I looked through the offers of online stores, read reviews, wondered how much you could spend on this business, how to solve the issue with noise and where to put this rather big bandura ... Then the usual jump rope fell into my hands, and I said to myself: well, here it is, a good option for cardio workouts without too much hemorrhoids! All you need are high ceilings and ... Nothing worked out: in order to jump on a rope, rhythmically and evenly, you need to be able to do it. Go back to the treadmill thoughts or ... Wait, why not just try to run on the spot? Oh, somehow TOO simple and stupid. But I tried. And you know what? It's great! The sensations are practically the same as what I experienced on the treadmill, but everything is much simpler: you catch a fitness bracelet on your arm, you put on headphones with sausage music, you turn on the timer - and go! Yes, there are nuances, but believe me, they are insignificant. As a result, for some time I have just been a fan of this topic, so much so that I want to join the sect of these same crazy people. You ask me: what are you talking about, how is it all connected with web development? Yes, there are nuances, but believe me, they are insignificant. As a result, for some time I have just been sick of this topic, so much so that I want to join the sect of these same crazy people. You ask me: what are you talking about, how is it all connected with web development? Yes, there are nuances, but believe me, they are insignificant. As a result, for some time I have just been sick of this topic, so much so that I want to join the sect of these same crazy people. You ask me: what are you talking about, how is it all connected with web development?
That's how
Consider a popular technology stack for modern frontend development:
TypeScript + LESS / SCSS / PostCSS + React + Redux / Mobx + Webpack
De facto, this is now a standard. It is easy to be convinced of it, analyzing vacancies. Any new project in the current year, with the highest probability, will be launched with a similar list under the hood. This is such a good set of time-tested treadmills . Let's go through this list together and see what remains of it if we use the "Running in place" approach.
TypeScript
Wonderful stuff. Anyone who has written something serious for the web will understand this. Often in articles about TypeScript for beginners, giving examples, they talk about some very simple and trivial things, such as passing typed arguments to a function or the vicissitudes of casting types in JavaScript, from which you are saved. But TS capabilities are bigger and deeper than type checking at the compilation stage, it can lead the developer "by the hand" throughout the project, prompting and not letting it slip again. But TS has drawbacks: it does NOT work in a browser without transpay and its syntax is, so to say, “dazzled” in the eyes. When you work with a frontend, your workflow often involves checking how your code runs in the browser, you need constant access to native runtime. Loss of time to rebuild a project to show changes collectively, they can be colossal. Even if you have everything you need is cached and optimized. What to do? My option: use JS + JSDoc. Yes, the TS static analyzer supports the formatJSDoc . At the same time, you see your code in the browser directly and use the benefits of civilization. Blocks describing types and other hints are not mixed with the code and have obvious boundaries, which, personally, helps me a lot to read the code diagonally. If you are using VS Code, you can try this approach simply by adding the line // @ ts-check to the top of your code. If you need support for outdated browsers, a compilation from ES6 + is, of course, still needed, but now only for the production version. As a result, you simplify debug in runtime (from which the absence of errors and warnings during assembly will not save) and save a lot of time.
LESS / SCSS / PostCSS
From this set, my favorites were LESS and PostCSS. I liked LESS for a more “native” syntax and the relative ease of the necessary dependencies for the development environment. PostCSS helped create all sorts of tricky tricks with SVG and keep track of the prefixes. The disadvantages, as in the previous paragraph, I would call the need for constant recompilation. Well, the dependencies themselves. However, in our 2018, we have such a wonderful thing as native CSS variables! This is an extremely powerful thing that no preprocessor can compare to: you can override your variables right in runtime! This opens up a whole world of new opportunities. For example, you can very simply, on the fly, change the themes of both the entire application and its individual blocks. Literally, the user can click on the skin for the application with any color-picker and you do not need to keep separate packages with pre-compiled styles or make your JS add-on with additional logic. And much more, more subtle and specific. I choose native modern CSS. But if you need to support IE11, thensorrow .
React
React brought us a new concept of modular decomposition, which very well fit the needs of client side development, because the structure of the components repeated the structure of the presentation, simplifying perception and bringing order to the heads of developers. That is why, in my opinion, he became so popular and thanks for that. However, now React is more and more cluttered with the properties of a cargo cult: people start dragging it into projects only because “everyone is doing it.” And this is terrible, because the engineering choice, especially in such an important issue, should be as conscious as possible. And for awareness, you need to understand that React is full of flaws. For me, this is, first of all, the fact that it is too thick an abstraction over the native DOM and brings in a huge amount of its own specificity, with which you want to understand instead of solving problems directly. This is especially felt and depressing if your tasks are a little less trivial than trite molds. On this subject, you can talk for a long time, remember JSX, VDOM, and so on, but for us the main question now is: what is the alternative? No, not Vue. And not, especially, Angular. For me, these are web components: a set of standardsCustomElements + ShadowDOM + ES Modules + HTML Templates . Why? Because these are standards supported by the web platform itself, not meta-platforms and JS-add-ins.
You can break your code into neat blocks and organize it as your heart desires with the help of native modules. Yes, modules are supported by all modern browsers and you don’t need rebuilding during development. Yes, in the modules you can separately store and styles and templates. Yes, for these files you can specifically enable syntax support and work with them as with native HTML and CSS. The life cycle of web components will help you organize render and updates without unnecessary parsing and changing the structure of the DOM. ShadowDOM will allow you to get rid of the cumbersome BEM and not worry further about the encapsulation of styles.
ShadowDOM is transparent to CSS variables and allows parameters to be passed in from any proper nesting level. This allows you to experiment with parametric design and do many other tricks. The web components fully work with the usual DOM API, while being full HTML elements: all standard methods are in your hands. You can use custom attributes to pass parameters and customize the display (although, unlike React, you can not pass anything except strings and boolean values, but for me this is not a problem at all). Your code will be easier and faster. Believe me, I have been able to compare. Some sadness: for most users, everything will work natively, but some will need polyfills.. If your statistics and target audience, mainly about modern browsers - feel free to dive into this topic, it's worth it.
Redux / Mobx
It's harder here. On the one hand, there are a lot of articles listing the advantages and disadvantages and comparisons of various approaches to the storage of states. And to get to the specifics - you need a specific case. So it turned out that this topic has been haunting me for quite some time now: I come across quite complex tasks in working with complexly structured data. Well, in general: data close to reality are never simple in practice, conveniently normalized with a clear universal hierarchy. Most often this is some tricky graph that requires you to initially lay in the system the maximum flexibility. In this matter, I am an adept in cycling, but I will not begin to recommend my way indiscriminately to everyone. What I can definitely advise is not to disdain the basics of modern computer science, to read something popular science on graph theory, set theory, chaos theory. Moreover, I am not talking about some kind of hardcore: the most common ideas can be very useful and “clear the brains” in the right way. In the simplest case, you can quite well “on your knee” write your own repository of states with blackjack and subscriptions, and this will be no more difficult than digging through the documentation of popular libraries.
Webpack
Abandon the build system completely, of course, we can. But the rezolving of the import chain in the real-time code is not the fastest. Therefore, we still need the bundles for the production version. Well, any minification / obfuscation, again, and compact daddy dist ... Therefore, Webpack - leave. But we need only a couple of modules for it with minimal configs, and no watches and rebuilds for the development process. Personally, my build config looks very compact and does not require a large number of dependencies. Recently, I often hear about the new Parcel assembler, and I am very impressed with its minimalist concept, but as far as I know it doesn’t work with ES modules, and in my opinion, this is a file. I hope this will change.
What is the result
I often hear the opinion that if you write “on vanilla” - you will inevitably encounter the fact that your project will soon turn into an unsupported mess with noodles. Let me parry: firstly, if desired, porridge can be prepared from the reactor with redux (I have seen enough of it). And secondly, everything will be very good if you use modules, JSDoc and good OOP practices. So, what we have come to:
JS + CSS + Web Components + Webpack
Of the five “treadmills”, we have only one, essentially lightweight. And this is enough to feel the “wings behind his back.”
PS I am by no means arguing that my approaches will suit everyone. I ask to regard this opus, at least, as an occasion to think about what seems to us self-evident.