¿Cómo se generan las páginas web en la actualidad?

En Rendering on the Web se analizan las distintas formas que existen de generar páginas web en la actualidad:

As developers, we are often faced with decisions that will affect the entire architecture of our applications. One of the core decisions web developers must make is where to implement logic and rendering in their application. This can be a difficult, since there are a number of different ways to build a website.

Our understanding of this space is informed by our work in Chrome talking to large sites over the past few years. Broadly speaking, we would encourage developers to consider server rendering or static rendering over a full rehydration approach.

In order to better understand the architectures we’re choosing from when we make this decision, we need to have a solid understanding of each approach and consistent terminology to use when speaking about them. The differences between these approaches help illustrate the trade-offs of rendering on the web through the lens of performance.


  • SSR: Server-Side Rendering – rendering a client-side or universal app to HTML on the server.
  • CSR: Client-Side Rendering – rendering an app in a browser, generally using the DOM.
  • Rehydration: “booting up” JavaScript views on the client such that they reuse the server-rendered HTML’s DOM tree and data.
  • Prerendering: running a client-side application at build time to capture its initial state as static HTML.


  • TTFB: Time to First Byte – seen as the time between clicking a link and the first bit of content coming in.
  • FP: First Paint – the first time any pixel gets becomes visible to the user.
  • FCP: First Contentful Paint – the time when requested content (article body, etc) becomes visible.
  • TTI: Time To Interactive – the time at which a page becomes interactive (events wired up, etc).

¿Grid o Flex?

En el artículo To Grid or to Flex? se analizan las ventajas y desventajas de realizar un diseño con CSS Grid o CSS Flex:

What surprised me about reading the responses in the thread was the number of people stating that they would only use Grid for page-level layout, and flexbox for everything else. If you take this as a rule, then you’re severely limiting yourself when it comes to Grid’s power. The main piece of advice I would give is to take every design individually, analyse the options available and don’t make assumptions about which technology you need. Here are some of the questions you could ask yourself when it comes to choosing a layout method.

Often, if you’re having to use calc() a lot to get precise track sizes (factoring in gutters, for example) then it’s worth considering using Grid, as the fr unit will do the heavy lifting for you and save you any number of headaches. While that’s fine as a general principle, it’s not the whole picture. There are cases when you might need Grid, even though your layout doesn’t require calc(). One example might be a fixed-width, two-dimensional layout, where each track is 200px wide – you don’t need calc() to tell you how wide those tracks should be, but you might still want the behaviour of Grid. Likewise, there are cases for using flexbox where you do need calc(), so this can only be interpreted as a guideline.

JavaScript, ese lenguaje malo malo malo

Lenguaje malo y con programadores ignorantes, según podemos leer en Quora en la siguiente respuesta a la pregunta Which commonly used programming language has the most ignorant programmers on average?:

Hands-down, it’s JavaScript. The number of really, really bad JS devs out there staggers the mind. They are responsible for the huge number of crap JS libraries, especially in the npm repositories.

They actually believe that JavaScript is sprinkled with fairy dust. They think JavaScript is somehow unique in terms of features and capabilities, when, in fact, there is absolutely nothing new nor special about this poorly designed language. Dynamic typing? Prototypes? Lambdas? Asynchronous programming? We’ve seen them all before in other languages.


I agree with Ryan Gedwill’s answer. “JavaScript is the most ignorant community because they don’t understand the word simple.”

30 años de la World Wide Web

Se supone que el 12 de marzo de 2019 se cumplieron los 30 años de la World Wide Web. Eso podemos leer en La Red de Redes cumple 30 años: surfeamos por la historia de la autopista de la información y en otras páginas similares que se han publicado durante este mes de marzo:

Se cumplen 30 años de una de las creaciones llamadas a cambiar la civilización occidental tal y como la conocemos. Hablamos de la World Wide Web (WWW), un proyecto global de hipertexto que ha permitido por primera vez al mundo trabajar conjuntamente en la Red de Redes. ¿Y qué nos ha traído este avance tecnológico que se ha comparado, por su alcance, a la imprenta? ¡Encended vuestros módems, que vamos a surfear por la historia de la autopista de la información!

Bueno, realmente no nació entonces, más bien nació en 1990 o 1991. Lo que ocurrió el 12 de marzo de 1989 es que Tim Berners-Lee presentó un informe con una idea que luego dio lugar a la Web:

Se habló por primera vez de este protocolo para la transferencia de hipertextos hace 30 años, cuando, el 12 de marzo de 1989, el investigador británico Tim Berners-Lee lo describió en un informe para el CERN.


La propuesta original de Berners-Lee tenía solo 20 páginas, pero esas 20 páginas han creado un mundo interconectado en el que lo global es cada vez más local. A Berners-Lee le debemos, pues, herramientas como la URL, el protocolo HTTP y el formato HTML, avanzando la tendencia un poco WTF de hablar en siglas en Internet, que es algo muy LOL. Como veis, estoy al tanto de las últimas tendencias.

En los siguientes artículos podemos leer más cosas sobre este tema: