a quick notepad about webdev and permaculture. created after a short discussion on twitter : https://twitter.com/greweb/status/828559195066757120
premier jour de l’An | |
je pense à la solitude | |
des soirées d’automne | |
les fleurs de quel arbre | |
impossible de savoir | |
mais un tel parfum ! | |
au milieu du champ | |
et libre de toute chose |
Réponse à @Saint_loup – https://twitter.com/Saint_loup/status/910627517719072768
Coté front-end, "bien" faire un site web ecommerce sous forme d'une SPA full JS pose des défis très critiques (webperf / accessibilité / seo – mais aussi staffing, organisationels, etc...) qui sont déjà très bien assurés nativement par une approche plus classique (pages HTML/CSS "statiques" bien écrites, dynamisées par une couche de JS bien écrit).
Certes, c'est possible de résoudre certaines choses en "full JS", avec du rendu coté serveur (approche en voque chez les "pure players" – qui ont un SI peu "épais"). Mais de même : nouveaux défis backend, il faut tout changer et ré-écrire coté serveur (sur pas mal de parties qui contiennent de la logique métier).
L'approche "classique" est d'avantage retro-compatible et futur-compatible :
- rien n'interdit d'y "saupoudrer" du preact ou de vueJS, par exemple)
- tu n'es pas coincé lorsque ton super framework sur lequel tu as tout basé (et que tu auras bien customisé) devient
setProxy(){ | |
export all_proxy=socks://url.to.proxy:80 | |
export http_proxy=http://url.to.proxy:80 | |
export https_proxy=$http_proxy | |
export ftp_proxy=$http_proxy | |
export ALL_PROXY=$all_proxy | |
export HTTP_PROXY=$http_proxy | |
export HTTPS_PROXY=$http_proxy | |
export FTP_PROXY=$http_proxy | |
export no_proxy="localhost, 127.0.0.1, .internal.domain" |
A personal logging / writing tool - a personal log, a text editor, a writing tool
Inspirations (philosophy and UX) :
- Lu Devine Dinvega's (@neauoire) ecosystem and approach
- Ulysses and Scrivener (for neat workflows and writing tools)
- iA Writer and others distraction free text-editors
I want a tool which fit and support my mental model and workflows. Building it and experimenting is the best way (not the easiest ^^)
A publishing / hosting / synchronizing engine
We Love Speed 2018 :
- Programme détaillé : https://www.welovespeed.com/2018/programme/
- Compte twitter : https://twitter.com/_welovespeed
- Photos (speakers+team) : https://www.flickr.com/groups/3951477@N20/pool/
Quelles métriques pour mesurer la webperf ? (fr) – Jean-Pierre Vincent (freelance)
context : https://twitter.com/nhoizey/status/1169577744650428417
The next version of Vue will have some Svelte inspired improvements, it seems.
I don't know much more, beside some quickly viewed screenshots of new syntax (I didn't practised Vue since ~1 year)
Svelte really shines on code simplicity/lightness. Developping a component really feels like writing a small HTML fragment (beside the templating directives) Particularities : mostly 2 syntaxes twists,
(from the trenches, for Xavier and Alexis)
- ~8/10 front-end developers working on a "core" ecommerce solution, with various technical levels/experience
- ~15 (more to come) front-end developers (from different countries) extending/overriding the "core" ecommerce solution, again with various technical level/experience
- 2 back-end developers maintaining a React widget / microfrontend
- 2 fullstack developers contributing occasionally.
- those numbers will evolve as Svelte is spreading in my client's projects ;-)
Svelte team asked some feedback about this RFC : Passing CSS custom properties to components](https://github.com/sveltejs/rfcs/blob/style-properties/text/0000-style-properties.md)
I'm not a big design system user, so I would very much like to get feedback from people who are. Would this solve your problems? What have we missed?
Hello,
I won't give any implementation feedback here at the moment, but some context of our team usage and direction.