ThickBox is a webpage UI dialog widget written in JavaScript on top of the jQuery library. Its function is to show a single image, multiple images, inline content, iframed content, or content served through AJAX in a hybrid modal.
JX Library es una librería para Mootools que nos facilita la realización de interfaces gráficas en nuestras páginas web.
Nos ofrece una variedad de elementos gráficos: layouts, paneles, árboles, grids, botones, toolbars, selectores de color, combos, … Jx
Vía / WebAppers
No actualices toda la página usando Ajax, ni modifiques elementos HTML que puedas modificar mediante Javascript y el DOM.
Ten en cuenta que habrá visitantes que tengan el Javascript desactivado o usen un navegador con una version de Javascript antigua o no completa como la de los dispositivos móviles.
Cachea, ya sea en el cliente o en el servidor, las peticiones más frecuentes. Por ejemplo, el autocompletado hace peticiones constantemente al servidor, lo que puede gastar recursos del servidor y la base de datos.
No tengas muchas llamadas concurrentes para cambiar la interfaz, normalmente los navegadores solo realizan dos llamadas HTTP a la vez, por lo que si tienes muchas llamadas para cambiar las imágenes, puede volverse muy lenta la carga.
Usa llamadas asÃncronas, ya que si las realizas de forma sÃncrona y hay problemas de red, el navegador se quedará esperando la respuesta.
Prueba tu aplicación web con una conexión lenta.
Comprueba el uso de memoria del navegador mientras ejecutas tu aplicación web durante 1 ahora, 2, 10, un dÃa.
Comprueba el código de estado http que devuelve XMLHttpRequest.
Prueba a desactivar el objeto XMLHttpRequest.
Usa indicadores de carga para saber que la aplicación está cargando algo.
Ten en cuenta que puedan usar el botón de “Atrás” del navegador.
Si es necesario cancelar un petición ten en cuenta que la petición ya está procesándose en el servidor y que el cliente procesará la respuesta.
Yo añadirÃa que hay que tener en cuenta que el orden de llegada de las respuestas no tiene que ser el mismo que el de las peticiones, si es importante el orden, usa bloqueos pare evitar problemas de concurrencia.
Como se puede ver, existen dos scripts dentro de npm: build que compila el js y extrae los CSS, y dev, que arranca el servidor de webpack habilitando HMR (🎶 ¡ya no puedo vivir sin él! 🎶).
Ambas configuraciones de webpack usan un script en común (webpack.config.common.js):
const webpack = require( 'webpack' );
const path = require( 'path' );
// Carga los ficheros .vueconst VueLoaderPlugin = require( 'vue-loader/lib/plugin' );
// Configura stylelintconst StyleLintPlugin = require( 'stylelint-webpack-plugin' );
// Para obtener un path para los aliasfunctionresolve( dir ) {
return path.join( __dirname, '.', dir );
}
module.exports = {
mode: 'production',
// Fichero inicial del proyecto
entry: './js/main.js',
// Fichero final para incluir
output: {
filename: 'js/main.js',
publicPath: '/dist/',
},
module: {
// Reglas para los ficheros
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: 'babel-loader',
},
{
test: /\.vue$/,
loader: 'vue-loader',
},
{
test: /\.css$/,
use: [
'css-loader',
'sass-loader',
],
},
],
},
plugins: [
new webpack.HotModuleReplacementPlugin(),
new VueLoaderPlugin(),
new StyleLintPlugin( {
files: [ '**/*.{vue,htm,html,css,sss,less,scss,sass}' ],
} ),
],
resolve: {
extensions: [ '.js', '.vue', '.json' ],
alias: {
'@': resolve( '' ),
},
},
};
El frontend se gestiona desde el fichero main.js, que inicializará Vue y añadirá el componente principal:
import Vue from 'vue';
import Buefy from 'buefy';
import'buefy/dist/buefy.css';
import App from './components/App.vue';
import'@/assets/scss/main.scss';
Vue.use( Buefy );
new Vue( {
el: '#app',
components: {
App,
},
render: ( c ) => c( 'app' ),
} );
// accept replacement modulesif ( module.hot ) {
module.hot.accept();
}
Y ya por último el componente App.vue, que muestra simplemente un poco de HTML
Google tiene una guía de estilos para programar en Javascript. Yo no soy muy partidario de ello, ya que cada cual programe como quiera siempre que sea código legible, es decir, ¿por qué usar variables con nombres así: nombreVariable y no así: nombre_variable?. Está claro que en un proyecto o una empresa sí tiene sentido usar guías de estilo, pero que una guía de estilo sea generalizada, no le veo sentido.
De todas formas los consejos están bastante bien y ante la duda de cómo hacerlo, podemos echarle un vistazo a cómo lo hacen en Google. Claro, que luego lo ofuscan y no hay quién entienda sus librerías.
Buen script que nos permite resaltar el código que mostramos dentro de un <pre$gt;<code lang=”[lenguaje]“$gt;…</code$gt;</pre$gt; en nuestras páginas web o blogs.
El script realiza una llamada Ajax con los trozos de código y su lenguaje y recibe el html de cada trozo de código ya formateado. Utiliza GeSHi para resaltar el código, pero puede utilizar otras. Ajax Syntax Highlighter
Vía / philsci
Ya hablamos en su dÃa de FireBug, una extensión que nos permite depurar nuestras aplicaciones web. La nueva versión tiene una gran novedad, “debuguear” Javascript. Ahora es posible poner puntos de ruptura, ejecutar el código paso a paso, inspeccionar variables, comprobar código, … Si antes ya era indispensable, ahora es totalmente obligatorio para cualquier desarrollador (vale, quizás me he pasado). A parte de el debugger hay otra serie de cambios que no dejan de tener importancia. FireBug
VÃa / SitePoint
Ya