Making the web great again
The modern web is a complex dynamic system that is constantly in motion. As noted in many articles, it becomes very difficult to keep track of all the changes as new tools and frameworks appear almost every day. Knowledge becomes obsolete before it has time to gain a foothold. Of course, all this is an obvious result of rapid development and growth, but this inevitably adds complexity to web developers and increases the threshold for entering a profession.
It comes to the point of absurdity, to create a simple user data entry form, you must first configure the babel, then the webpack, and then also deal with the settings specific to the chosen framework ... And these are probably too many new words for a newcomer to the team who was assigned this simple-looking task . No, most likely the project will already be configured and configured and the beginner will certainly not leave one to the mercy of fate in brief telling him what is what. But we have to admit that it has really become too difficult and we seem to spend a significant amount of time on all these assembly systems and configuration combat.
The answer is actually quite simple and straightforward. The web has really grown and become more difficult, now it is not uncommon to meet a multimedia application written entirely under web technology or a 3D game in a browser, which was unthinkable 10 years ago. But the main problem is that we often want from the web that it is not yet ready to give us - the latest technologies and standards, experimental architectural patterns, everything is only the newest and most modern, and of course it should work everywhere and for everyone, and quickly please . And then a wild gang headed by a webpack appears on the scene and begins to rule the ball. And here you are already hung with complex configurations and your project is going to a half minutes and weighs fifty megabytes. Finito la comedia. The fight begins with the configuration in an attempt to squeeze a little more performance and reduce the size. And what kind of development and implementation of ideas, then we can even talk about, if we spend the lion's share of the settings for the assembly line. Admit that you have a webpack expert on your team?
We are not so accustomed to this, but rather resigned, that this is normal, but what else? We hung with types and frameworks, corporate, security - not even carp. But where did this ease and simplicity of the experiment go, for which this weakly typed dynamic language was conceived? And everything, it is not there, disappeared under the mountains of bundles and enterprises. But really nothing can be done?
It is worthwhile to stop and think, what are we doing and why? After all, if we use webpack, rollup, parcel (underline the necessary) and create all these unreadable bundles which then cannot be debugged even with source maps, then surely someone needs this, right? Yes, everything is so, for fast and efficient production from bundles you cannot get anywhere and even the new-fashioned HTTP2 did not make the task much simpler. That is why developers are sitting in the office on long autumn evenings, staying longer at work and burning hundreds of thousands of kilowatts of energy, packed with departments, packed with companies, packed with the whole world passing the shift with the movement of the sun. It just so happened, and such is the law. Dura lex, sed lex. So the truly Shakespearean issue of banding or not banding is dying without even having time to break from the mouth of the young Hamlet who opened the visual studio,
(Everything is fine)
But wait, you said that this is all necessary for production, but what about development? Why it is impossible to develop comfortably in the good old days just by running the server and then pack everything before sending it to production? And why do we generally use the same tools for production and development? Why not use a sharpened solution specifically for development, because what we are doing does not look very logical.
And this is really not logical and we rather do so in the absence of alternatives or simply because we are used to. But what if I say that you have a choice?
npm install -g @hqjs/hq
and then run as a team in the project root to start experimenting immediately.
Well, you say, about the same, the old gang offered us, well, maybe a little more configuration, a little less simple, but everything is very similar, so why do we need this new Chuck Norris in the world of server maidens? And here I will answer you with the new motto of the house of Greyjoy - “We are not a bundle!”. Yes, in fact, we are not a bundle!
(House of Greyjoy. We do not
Hi, I’m in web development since I was 13 years old and I started banding when I was 19. My friend got hooked on it when I went to his garage where he bandaged days and nights on the span. I asked what are you doing? And he said that this is a new thing, it is now very fashionable and cool and I definitely have to try. At first I just glued the files, and then I tried a small bundle with a closure compiler and then I could not stop. gulp, browserify, and then webpack ... My bundles were getting harder. I did not know how to stop, I got into the whirlwind which did not allow me to go out. Every time I got on a new project, there was already someone who bundled up and it was simply impossible to refuse. Not a bandit was not prestigious! People from the profession and even close friends refused to communicate and did not call me back when they found out that I want to stop. So there was nowhere to go. But now I'm clean! I am no longer a bandit during development! My friends and acquaintances stopped with me, it is now not accepted in our company. And you know what? I have never felt so good! The world finally began to play with new colors and began to be time for work and family.
Seriously, the absence of bundles greatly simplifies life. Remember unbearable situations when it is impossible to put a break point not so much on an expression, but even on the necessary line! Or these variable names generated by webpack __webpack __ @ #% ^ $ !!! With their perusal, it is not surprising and to cause Satan, but you do not wish to write them to the console and to the enemy, but what is the most disgusting they are hidden behind normal, human names, so that they can also be guessed. In general, debugging often turns into hell, even with full source maps. How many times a day are you stuff inside the node_modules? How many curses are miserable for unhappy developers of React and Angular because it is impossible to understand the error message and where does this error occur? After we switched to hq, we forgot it all like a bad dream. Time has become really more now you don’t have to think why it isn’t going to, or it just doesn’t work silently and from where this library of ten megabytes came to us in the build, now you can see where! Suffering has become less, work has become easier and it turns out to make it a pleasure.
(This person is Varg or skin-changing, he can penetrate into the consciousness of animals. Now he is hovering with the eagle, looking out for the enemy)
The most pleasant thing is that hq does not seem to be something new and complex, it feels like he has always been with us everything is so simple and familiar. hq is a static server that just understands you. Starting a new project is incredibly fast, one team in the console and you can start experimenting. Framework, libraries, formats, architectural approaches - all this no longer creates barriers, with hq everything just works like in the good old days, quickly, simply and logically! Plus, the hq open source project, so you can always improve or add support for some new format.
Frankly, we have found flaws. Previously, when building with a webpack took a few minutes, it was a wonderful excuse to look into the kitchen for a cup of aromatic coffee, but now everything works so fast that there is simply no time for that. Although, is it necessary to look for an excuse for a good coffee?
How does all this work? There may be the impression that hq is a hefty monster woven by Dr. Frankenstein from a multitude of dissimilar and disconnected parts, seasoned with a bit of black magic. But in fact, everything is quite harmonious and uniform. hq distributes each file individually on demand, just as a regular static server does. This gives us only a limited opportunity to get rid of unused code, without full tree shaking, but it saves a lot of time spent on dependency analysis. All transformations happen instantly and on the fly. Moreover, only the necessary minimum is transformed. If you use a modern browser and adhere to web standards, then your code is unlikely to be changed at all. At a time when you can rely on standards, there is no guarantee that libraries to which you are so used will do the same. Most of them will most likely come in commonjs format, which does not allow them to work as they are in the browser. hq takes care of this and converts commonjs modules to ESM format, processes non-standard, but rather common imports (such as css or json) and destructures imported objects when needed. hq works in conjunction with a web browser, using its caching system to speed up the delivery of assets and transfer only the files that have been changed. It will automatically reload the page when you change your code, so that you can instantly evaluate the result of the changes. hq can work with multiple frameworks, but does not depend on their code. Instead, hq produces a series of AST transformations using babel plugins,
Thus, in spite of all the difficulties and challenges posed by the modern web, project development can remain simple and intuitive, just as it was at the dawn of web technologies. Try hq now to improve your development experience in an old project, or use it to create a new exciting project!
npm install -g @hqjs/hq