In pursuit of web standards

We have already told you what problems we encounter when doing front-end development in 2018. Let's see how far we go from standards when we write our code.



and how we can solve this problem.

')
Modern browsers can do a lot, they understand ES6, support ES modules, provide convenient tools for development and debugging. But is this enough and do we use all of these tools effectively?

Let's highlight the main differences between our source code and the code that we load into our browser:

The code is delivered in one file - although all modern browsers understand the format of ES modules, most development tools merge our code into one large file.

New javascript features - according to the compatibility table, only the latest desktop versions of chrome support 100% of the new language properties (and only a part of the experimental properties), other browsers need transpilation and polyfiles for missing properties.

@Component() class Toolbar {} 

New css features - cssdb contains a list of css properties supported by modern browsers, the rest should be compiled.

 @media (480px <= width < 768px) {} 

Commonjs modules - the format of modules native to node.js, despite its popularity and prevalence, is not supported by any browser and needs to be converted (ES modules are supported by new versions of node.js in experimental mode , most libraries are still supplied in Commonjs format).

 const component = require('./component'); module.exports = function() {}; 

Simple import - (import starting with the package name), browsers are not supported, work is underway on the draft standard (alternatively, you can already now consolidate imports into node.js and browsers using ES modules and redefining the node.js module loader to work with absolute paths like / node_modules / lodash / lib / get.js, but most libraries do not).

 import get from 'lodash/get'; 

Import of built-in modules - is also not supported in browsers, requires replacement with libraries.

 import zlib from 'zlib'; 

Destructuring imports - we are used to import anything from anywhere, regardless of whether the value we are exporting is exported:

 import { Component } from 'react'; 

in fact, the library exports one React object, which contains the Component property, and not a set of properties as one might think.

Import of third-party formats (css, json, etc.) - browsers are not supported and apparently will not (with the exception of the import wasm ).

 import './style.css'; 

Type declarations - typescript and flow have become very popular and help in the development of large libraries, but do not have browser support.

 const a: number = 1; 

Metal languages ​​- scss, sass, less, typescript, coffeescript, pug are not standard and need to be compiled.

 <style type=”text/scss”> .logo { color: white; &.active { color: red; } } </style> 

Jsx templates are not standard and must be converted using createElement:

 const element = <h1>Hello, world!</h1>; 

Vue templates - although they took inspiration from web components, are also not standard:

 <template> <div>This will be pre-compiled</div> </template> <script src="./my-component.js"></script> <style src="./my-component.css"></style> 

Relative paths in web components - if you are used to breaking your components into scripts templates and styles, then you know that paths are attached to the root of the project and the component becomes impossible to transfer and difficult to reuse in other projects.

 fetch('./my-button.html'); 

If you work with Angular:

Dependency injection - implemented using reflections and decorators' metadata, requires compilation.

Dynamic loading of styles via http - the framework does not support this feature out of the box.

As you can see, the web to which we are accustomed is far from the standard, although partially it strives for it. The task of hq is to smooth this difference until many things become standard, and others do not come out of use. hq is such a smart server that makes your code a little clearer to the browser while converting only the required minimum and not sticking everything together. Thus, regardless of the technology chosen and the hq framework, it does all this routine compatibility work for you and allows you to start developing immediately.

What other advantages does hq offer?

• No configuration
• Improved debugging due to the absence of bundles
• The code in the browser is as close to the source as possible.
• Simple project structure reflected in the browser
• All dependencies of the project are visible, who loads what, why and when
• Full use of browser tools: load / debug / code cover
• Very fast server operation
• When using standards, hq works like a normal static server.

Try hq right now:

 npm i -g @hqjs/hq 

and then run in the project root:

 hq 

PS: Thank you to justboris for valuable comments on the previous article.