Make the web great again
The modern web is a complex dynamic system that is continuously moving and changing. We’ve read times and times before how difficult it is to follow all the changes since every day new instruments and frameworks are invented. These inventions get dated before ever becoming part of the common practice. All this is nothing but the obvious result of a dashing growth and development, that inevitably heightens the barrier to entry for developers-to-be.
It gets freakishly insane, when to create a simple data entry form, you must first configure the babel, then the webpack, and then also deal with the settings specific to the chosen framework… Already, these are too many new terms for the newbie, who were assigned this simple-looking task on your team. Ofcourse, most likely the project will already be set up and configured, and the beginner will certainly not be left to the mercy of fate, as you briefly explain what is what. Let’s admit though, that it has become too difficult to keep up with. We spend simply too much time on all the build systems and their exasperating configuration.
First, let us go back in time — has it always been like this? Did the creators of the web invision such a future for us? No, damn it, no! The bland web, filled with tricks and hacks, was different — simple and clear! Here is where we add the script, here’s where we put the styles, and here is our page layout. So what went wrong, has it really become so bad? Didn’t javascript and the whole web grow and improve to become stronger and more expressive? The web has developed modularity. The advantages of various architectural patterns is obvious… And yet, where is that original simplicity? Have we really lost it for good?
The answer is actually quite simple and straightforward. The web has expanded to become more complex to the point where now it is common to see multimedia web applications and 3D games written entirely with web technologies. 10 years ago this was unthinkable.
The main problem is that we often want from the web what it is not yet ready to give — the latest standards, experimental architectural patterns, only the newest and most modern technologies, and of course — it must work everywhere, for everyone, and we want it NOW!
That is where the wild gang headed by webpack breaks the scene and begins to rule the show. You instantly get buried in complex configurations and your project is compiling for 90 seconds straight, weighing at least fifty megabytes. Show’s over. We embark on a long and sad journey, doing configuration after configuration in an attempt to squeeze a little more performance and take up a little less space. And what kind of development and creative flow can there be, if we spend so much time setting the assembly line? Admit that you too have a webpack expert in your team, doing assembling web packs most of their time.
It’s not like we are accustomed to this, but rather very certain that it is normal. What else is there to do? We surround ourselves with types and frameworks, corporate structure, security. Makes total sense. But where did the ease of experimenting (for which this weakly-typed dynamic language was conceived in the first place) vanish? That’s it, it is no longer there, buried under the piles of bundles and enterprises. But really, nothing can be done?
Let us stop for a second and think: what are we doing with our lives and why? After all, if we use webpack, rollup, parcel (whichever is your choice) and we create all these unreadable bundles that can not even be debugged from source maps, then someone must still need this, right? Yes for fast and efficient production you will not get very far without bundling. Even the hot new HTTP2 doesn’t make our lives much easier. That is why developers are stuck in their offices doing long ours instead of Netflix and chill; burning hundreds of thousands of kilowatts, packing in departments, packing in companies, packing all around the globe passing their shifts to one another following the movement of the sun. That is how the life goes, and this is the law. Dura lex, sed lex. So the Shakespearean question “to bundle, or not to bundle?” dies without ever leaving the mouth of a young Hamlet, who opens the visual studio to sculpt another masterpiece.
Wait, you said that this is all necessary for the production, but what about the development? Why can’t you comfortably develop as in the olden days, running the server and then packing everything only when shipping to production? And why do we generally use the same tools for production and development? Why not use a solution designed specifically for development, because what we are doing doesn’t seem to make much sense.
And in fact it really doesn’t. But we continue doing it for the lack of alternatives or simply because this is what we are are used to. Well, what if I told you, that today, there finally is a way to change it all!
Meet hq — a dedicated server for developing web applications. hq is a static server on steroids that understands everything that a normal server is too young to comprehend. Want the latest tricks from javascript, but your browser still does not support them? — There you go! Your library uses commonjs — not a problem! Down with the swarm of tools that work only with one specific framework; hq supports them all, straight out of the box. hq is so cool that it does not require any configuration, it just works. No, parcel! It’s not like you do it, hq does NOT require any configuration. Configuration is just not there, so there is simply nothing to configure. Install it once
npm install -g @hqjs/hqand then run it with a single command in the project root and start experimenting immediately
hqWell, you say, something similar was offered to us by the old gang. Maybe a bit more configuration, a little less simple, but it is all very similar, why do we have this new Chuck Norris in the world of dev servers? And here I will answer you with the new motto of the House of Greyjoys — “We Do Not Bundle!”. Yes, you’ve heard it, we do not bundle!
Hi, I’ve been doing web development since I was 13. I first tried bundling when I was 19. My friend pressured me to try it when I came to visit him in his garage, where he was bundling day and night. “What are you doing?”, I asked. He told me this is a new thing, it’s trendy, cool, and I definitely have to try it. At first, I simply glued the files for a while. But then I tried a small bundle with the closure compiler and I simply could not stop any more. Gulp, browserify, and then webpack… My bundles were getting worse. I did not know how to quit, I got into a vicious circle that did not let me go. Every time I got to a new project there was already someone bundling and it was simply impossible to refuse. It came to a point where it was no longer ok not to bundle! Developers and close friends refused to communicate and ghosted me when they learned that I wanted to quit. So there was simply nowhere to go. It took a miracle to quit, but now I am relieved to say — I’m clean! I am no longer a bandlee when I develop! My friends and my team too got off bundling with me, this is no longer acceptable in our company. And you know what? I never felt so good! The world shines with new colors, I now have time for work and for my family.
Seriously, the absence of bundles has made my life a bliss. Remember when you failed to add a breakpoint not just on an expression, but even on the correct line! Or these variables generated by webpack __webpack __ @ #% ^ $ & # !!! If you ever read them, you for sure were bound to summon Satan. Writing them in the console is something you wouldn’t wish on your worst enemy. Oh, and they are hidden behind normal-looking names, making their true meaning almost impossible to guess. And talk about debugging, even with full source maps. How many times a day do you swear at the code inside the node_modules? How many curses are thrown at the unfortunate React and Angular developers because it’s impossible to understand the error message and where it occurs? After we switched to hq, we’ve let this all fade as a terrible nightmare. Time has become abundant. Now it’s not necessary to roam around the code to see why something is just quietly not working and what is this library worth 10 megabytes. Now you can clearly see it all! There is much less suffering, work has become easier to do and guess what, — you can even enjoy doing it.
The best part is that hq does not seem to be something new or complex. It feels like it has always been there. hq is a static server that just understands you. The start of a new project becomes incredibly fast: a single line in the console and you can start experimenting all you want. Frameworks, libraries, formats, architectural complexities — all these are no longer barriers; with hq everything just works as in the good ol’ days. Fast, easy and logical. Also, hq is open source, so you can always improve something or add support for new formats.
To be completely honest, we found a few drawbacks. When the assembly with webpack was taking a few minutes, it was a wonderful excuse to go to the kitchen for a cup of fragrant coffee, now everything is working so fast that there is simply no time to do this. What a pickle! But at the end of the day, is it really necessary to look for an excuse for good coffee?
How does this all work? Here, you may get the impression that hq is a hefty monster woven by Dr. Frankenstein from a variety of heterogeneous and unconnected parts flavored with a lot of black magic. But in fact everything is quite uniform and light. hq serves every file individually as requested, same way regular static server would. That gives you only very simple dead code elimination without proper tree shaking. On the other hand, a lot of time that was wasted on dependency analysis is saved. All transformations are instant and performed on the go. If you use modern browser and stick to the standard your code would hardly be changed at all.
While you try to follow the standards, you can’t guarantee that all that libraries that you depend on will do the same. Most of them will probably use the format of commonjs modules and won’t work in the browser just as they are. hq takes care of that as well and transforms commonjs modules into ESM. It handles non standard, but pretty common imports (like css or json importing) and destructures importing objects when required.
hq will work tightly with the browser, using its cache system to speed up asset delivery and only sends what has been changed. It will automatically reload the page when you modify the code so you will see feedback immediately.
It can work with many different frameworks, but does not rely on any of that frameworks’ code in particular. Instead hq performs ast transformations with babel through plugins that were designed for hq to help it understand the diversity of different technologies and techniques used by those frameworks.
Bottomline, despite all the complexities and challenges presented by the modern web, development of projects can remain simple and intuitive, just as it was at the dawn of the web technologies. Try hq now to improve the development experience in your old project, or use it to create a new exciting project.
npm install -g @hqjs/hq