25/07/2017 Categoría/s: Citas,Desarrollo web,ECMAScript. 0 Comentarios

IndexedDB

Estaba mirando la especificación de Indexed Database API (especificación del W3C desde el 2015), pero gracias al siguiente tutorial, me he enterado mucho mejor. Y aquí lo dejo.

A website can have one or more IndexedDB databases. Each database must have a unique name.

A database can contain one or more object stores. An object store, which is also uniquely identified by a name, is a collection of records. Each record has a key and a value. The value is an object that can have one or more properties or attributes. The key can be based on a key generator, derived by a key path, or explicitly set. A key generator automatically generates a unique sequential positive integer. A key path defines the path to the key value. It can be a single JavaScript identifier or multiple identifiers separated by periods.

The specification includes both an asynchronous and a synchronous API. The synchronous API is meant to be used within web workers. The asynchronous API uses requests and callbacks.

Brian StewartUsing the HTML5 IndexedDB API

22/07/2017 Categoría/s: Citas,Desarrollo web,Libros. 0 Comentarios

Sugerencias para mejorar el peso y rendimiento de las páginas webs

Acabo de leer el —brevísimo— libro Web Page Size, Speed, and Performance, escrito por Terrence Dorsey y publicado por O'Reilly (la descarga es gratuíta).
El contenido del libro, como podrás imaginar, consta de consejos para mejorar el peso y rendimiento de una página web. Y creo que cada vez hay que valorar más aspectos como el peso y el rendimiento, teniendo en cuenta la tendencia actual. Cualquier "doctor web" nos diría hay un evidente sobrepeso.
Se puede encontrar una cita cuyo origen está en el mundo de la automoción, aplicable perfectamente al desarrollo web:

Simplify, then add lightness.

Collin Chapman

Sugerencia: puedes aprovechar para procasti…, digo, para ampliar tus bastos conocimientos leyendo un poco sobre Collin Chapman y la empresa de coches que fundó, Lotus.
Continuando, si es que se puede, en el libro aparecía un colofón con unos cuantos consejos, que cito a continuación:

  1. Start by measuring the size, request latency, and load time of your current site on various devices. You can do this right in the browser.
  2. Use online tools to measure more advanced site performance metrics and compare them against industry average.
  3. Know how long your page takes to finish rendering and what the time is to the first interaction. This is your first-impression metric.
  4. Evaluate your business goals and try to correlate site performance with traffic, conversiones, revenues, or whatever metrics is relevant to your business.
  5. Count all of the components that have to be requested to render your page Can you reduce this number?
  6. Slim down your HTML. Combine and minfiy your CSS files.
  7. Take a close look at where you reference scripts and when they excecute. Are scripts blocking page rendering or interaction?
  8. Make sure you're using images wisely and optimizing them for size and quality. A little bit of code can make sure you're not sending too many image bytes where they're not needed.
  9. Don't throw out social features just because they add to your request, scripts, and page size if they benefit the business; just be sure to use them tactically instead of spreading them all over the place.
  10. Starting with a focus on the mobile experience —most likely your fastest growing customer experience— may help you target performance optimizations that benefit all visitors to your site, even those using the desktop.

19/06/2017 Categoría/s: ECMAScript. 0 Comentarios

ECMAScript 2016: compatibilidad y novedades

El Standard ECMA-262, ECMAScript® 2016 ó también conocido como ECMAScript 6 (ES6), publicado en junio del 2015 y cuya última revisión a día de hoy es de junio del 2016 ha sido sin duda, junto con la versión anterior, una gran evolución en el estándar.
Como siempre, con la aparición de nuevas tecnologías, existe la duda si adoptarla o no: por un lado está el coste (en tiempo) de conocerlo e implementarlo, el soporte —en el caso de las tecnologías relacionadas con la web— de los navegadores y dispositivos, los diferentes perfiles de los usuarios y los beneficios al implementarlas.
Lo cierto es que más allá de los puntos de vista de Progressive enhancement ("mejora progresiva") o Graceful degradation ("degradación elegante") siempre es necesario saber si los navegadores van a interpretarlo correctamente. Y al igual que tenemos Can I Use para conocer el soporte de HTML5 y CSS3, también está, para ECMAScript® 2016 tenemos ECMAScript compatibility table, donde, además del soporte de los navegadores, también nos indica el soporte de traceur, type-script, nodejs,…
En Mozilla Hacks hay una serie de artículos sobre las novedades de ECMAScript 2016: ES6 In Depth Articles
Y si a alguien le apetece ojear un breve libro del 2015 relacionado con ECMAScript 2016, tal vez le interese dar un vistazo a JS.next: A Manager’s Guide, escrito por Aaron Frost. Son sólo 43 páginas disponibles en formato pdf y epub.
Por último, y como reflexión personal, creo que es bueno (y a la vez exigente) el que en los últimos años se puedan adoptar con más facilidad las —en algunas ocasiones desbordantes— tecnologías que van apareciendo. Y aquí aparecen otros dos puntos de vista (citas extraídas del libro antes mencionado):

  • Myth of management: Those who have seen success in the past tend to think erroneously that their one road traveled is the only road worth traveling
  • Chronological snobbery: If decisions like which technology to use are being re-decided every few months, you may find that you have a chronological snob among you.

Confesión: tiendo a ser pecador del primer punto y me veo muy representado en el siguiente texto humorístico How it feels to learn JavaScript in 2016 :)

16/06/2017 Categoría/s: Libros,Pensamiento visual. 0 Comentarios

Garabatear problemas y soluciones 2

Hace ya 5 años, que escribí Garabatear problemas y soluciones, en el que mencionaba tres recursos:

  • El libro "Tu mundo en una servilleta. Resolver problemas y vender ideas mediante dibujos." (ISBN 9788498750621) de Dan Roam (el título original, si lo prefieres en inglés es "The back of the napkin. Solving problems and selling ideas with pictures.")
  • Un curso de mapas mentales
  • La charla El dibujo y su retorno, una charla impartida por Fernando de Pablo Martínez (dibujario inteligente)

Pero el tiempo pasa, y han surgido algunas novedades —que no se han mencionado por aquí— y seguramente resulten igualmente interesantes. Son los siguientes libros:

No será complicado encontrar charlas en TED o en Youtube de estos autores. Pero ahora sólo he venido a hablar de sus libros. Y recuerda, usa lápiz y papel :)

20/09/2016 Categoría/s: Desarrollo web. 0 Comentarios

¿De verdad es imprescindible usar jQuery? Reflexión sobre el uso de frameworks a largo plazo

Estoy aquí depurando el javascript de una página a ver si averiguo porqué no aparece la capa de color gris translucida en una ventana modal de jQuery User Interface.
Llevo ya dos discos escuchados dándole al F11 y viendo todas las vueltas que conlleva una sola línea de código con la sintaxis de jQuery en los ficheros de las dos librerías.
Tengo los dedos a punto de sufrir una crisis de ansiedad.
Y claro, uno recuerda youmightnotneedjquery.com, y se pregunta si en todas y cada una de las ocasiones que usamos jQuery, no estamos pecando de pereza al no intentar hacerlo en el javascript (ahora ECMAScript) de toda la vida, con sus cambios y novedades.
Pero por otro lado, la sintaxis de jQuery es tan sencilla…


He de admitir que por falta de tiempo, permisos de red (y sí un poco de pereza), no estoy muy al tanto de todos los frameworks de estructuras modulares, módulos de carga, gestión de paquetes, automatización,… pero sigo pensando que una dependencia excesiva de frameworks —que virtualmente son cajas negras para una buena parte de desarrolladores—, tiene su riesgo. Y que hay que pensar más allá del hype y pensar a largo plazo, para tener en cuenta los problemas que puede provocar una actualización sin retrocompatibilidad total (como el conocido caso de Angular), o casos extremos como la falta de evolución y/o soporte.

¿Quién usa prototypejs.org?

¿Quién se acuerda de script.aculo.us?

¿Cuántos de todos estos recientes frameworks estarán activos en, digamos 5 años?


Bueno, continuo dándole al F11.

Categorías