Nous avons
déjà parlé des problèmes auxquels nous sommes confrontés lors du développement frontal en 2018. Voyons jusqu'où nous nous éloignons des normes lorsque nous écrivons notre code
et comment pouvons-nous résoudre ce problème.
Les navigateurs modernes peuvent faire beaucoup, ils comprennent ES6, prennent en charge les modules ES, fournissent des outils pratiques pour le développement et le débogage. Mais est-ce suffisant et utilisons-nous efficacement tous ces moyens?
Soulignons les principales différences entre notre code source et le code que nous téléchargeons dans notre navigateur:
Le code est fourni dans un seul fichier - bien que tous les navigateurs modernes comprennent le format des modules ES, la plupart des outils de développement collent notre code dans un seul gros fichier.
Nouvelles fonctionnalités de javascript - selon
le tableau de compatibilité, seules les dernières versions de bureau de chrome prennent en charge 100% des nouvelles propriétés de la langue (et seulement une partie des propriétés expérimentales), d'autres navigateurs ont besoin de transpilation et de polyphiles pour les propriétés manquantes.
@Component() class Toolbar {}
Nouvelles fonctionnalités de css -
cssdb contient une liste des propriétés css prises en charge par les navigateurs modernes, le reste doit être compilé.
@media (480px <= width < 768px) {}
Modules Commonjs - le format de module natif de
node.js, malgré sa popularité et sa prévalence, n'est pris en charge par aucun navigateur et doit être converti (les modules ES sont pris en charge par les nouvelles versions de node.js en
mode expérimental , la plupart des bibliothèques sont toujours livrées au format Commonjs).
const component = require('./component'); module.exports = function() {};
Importation simple - (importation commençant par le nom du package), les navigateurs ne sont pas pris en charge, le travail est en cours sur un
projet de norme (vous pouvez également consolider les importations dans node.js et les navigateurs à l'aide des modules ES et redéfinir le chargeur de modules node.js pour travailler avec des chemins absolus comme / node_modules / lodash / lib / get.js, mais la plupart des bibliothèques ne le font pas).
import get from 'lodash/get';
Importation de modules intégrés - également non pris en charge dans les navigateurs, nécessite un remplacement par les bibliothèques.
import zlib from 'zlib';
Importations destructrices - nous sommes habitués à importer n'importe quoi de n'importe où sans se soucier de savoir si la valeur que nous voulons est exportée:
import { Component } from 'react';
en fait, la bibliothèque exporte un seul objet React qui contient la propriété Component, pas un ensemble de propriétés comme vous pourriez le penser.
Importation de formats tiers (css, json, etc.) - n'est pas pris en charge par les navigateurs et ne le sera apparemment pas (sauf
pour l'importation de wasm ).
import './style.css';
Déclarations de type - le dactylographie et le flux sont devenus très populaires et aident au développement de grandes bibliothèques, mais ne sont pas pris en charge par les navigateurs.
const a: number = 1;
Métalangages - scss, sass, less, dactylographié, coffeescript, pug ne sont pas standard et nécessitent une compilation.
<style type=”text/scss”> .logo { color: white; &.active { color: red; } } </style>
Les modèles Jsx ne sont pas standard et doivent être convertis à l'aide de createElement:
const element = <h1>Hello, world!</h1>;
Les modèles Vue - tout en s'inspirant des composants Web, ne sont pas non plus standard:
<template> <div>This will be pre-compiled</div> </template> <script src="./my-component.js"></script> <style src="./my-component.css"></style>
Chemins relatifs dans les composants Web - si vous avez l'habitude de diviser vos composants en modèles et styles de scripts, vous savez que les chemins sont attachés à la racine du projet et le composant devient impossible à transférer et difficile à réutiliser dans d'autres projets.
fetch('./my-button.html');
Si vous travaillez avec Angular:
Injection de dépendances - implémentée à l'aide de réflexions et de métadonnées de décorateur, nécessite une compilation.
Chargement de style dynamique via http - le framework ne prend pas en charge cette fonctionnalité prête à l'emploi.
Comme vous pouvez le voir, le Web auquel nous sommes habitués est loin d'être le standard, bien qu'il y aspire partiellement. La tâche de
hq est de lisser cette différence jusqu'à ce que beaucoup de choses soient standard et que d'autres ne soient plus utilisées. hq est un serveur intelligent qui rend votre code un peu plus clair pour le navigateur tout en ne convertissant que le minimum nécessaire et en ne collant pas tout. Ainsi, quels que soient la technologie et le framework choisis, hq fait tout ce travail de routine pour vous assurer la compatibilité et vous permet de démarrer immédiatement le développement.
Quels autres avantages offre le siège social?
- Manque de configuration
- Débogage amélioré en raison de l'absence de bundles
- Le code dans le navigateur est aussi proche que possible de la source
- Structure de projet simple reflétée dans le navigateur
- Toutes les dépendances du projet sont visibles, qui charge quoi, pourquoi et quand
- Utilisation complète des outils du navigateur: chargement / débogage / couverture du code
- Fonctionnement très rapide du serveur
- À l'aide de normes, hq fonctionne comme un serveur statique classique
Essayez hq dès maintenant:
npm i -g @hqjs/hq
puis exécutez à la racine du projet:
hq
PS: Merci à
justboris pour les précieux commentaires sur l'article précédent.