Los formularios son una de las partes más importantes de la web. Sin ellos, no habría una manera fácil de recopilar datos, buscar recursos o registrarse para recibir información valiosa.

Puede incrustar formularios en sitios web con el elemento HTML form. Dentro del elemento de formulario, se anidan varias entradas. Estas entradas también se conocen como controles de formulario.

En este tutorial, exploraremos el elemento HTML form, los diversos tipos de entrada que toma y cómo crear un botón de envío con el que se envían los datos.

Al final, sabrá cómo funcionan los formularios y podrá crearlos con confianza.

Sintaxis básica del formulario HTML

<form action="mipaginaweb.com" method="POST">
    <!--La entrada de cualquier tipo y áreas de texto entra aquí-->
</form>

Tipos de entrada de formularios HTML

Usas la etiqueta <input>  para crear varios controles en HTML. Es un elemento en línea y toma atributos como type, name, minlength, maxlength, placeholder, y así. Cada uno de estos tiene valores específicos que toman.

El atributo placeholder es importante, ya que ayuda al usuario a comprender el propósito del input antes de escribir algo.

Hay 20 tipos inputs diferentes, y los veremos uno por uno.

Type text

Este tipo de input toma un valor de "texto", por lo que crea una sola línea de entrada de texto.

<input type="text" placeholder="Introduce nombre" />

Un input con el type="text" se parece a la siguiente captura de pantalla:

Type Password

Como su nombre lo indica, una entrada con un tipo de contraseña crea una contraseña. Es automáticamente invisible para el usuario, a menos que sea manipulado por JavaScript.

<input type="password" placeholder="Enter your password" />

Type Email

Cualquier entrada con el tipo de correo electrónico define un campo para ingresar una dirección de correo electrónico.

<input type="email" placeholder="Enter your email" />

Type Number

Este tipo de entrada permite al usuario insertar solo números.

<input type="number" placeholder="Enter a number" />

Type Radio

A veces, los usuarios tendrán que elegir una de las numerosas opciones. Un campo de entrada con sus atributos de tipo establecidos en "radio" le permite hacer esto.

 <input type="radio" />

Type Checkbox

Por lo tanto, con un tipo de entrada de radio, los usuarios podrán elegir una de numerosas opciones. ¿Qué pasa si quieres que elijan tantas opciones como sea posible? Eso es lo que una entrada con un atributo de tipo establecido en checkbox hace.

<input type="checkbox" />

Type Submit

Utilice este tipo para agregar un botón de envío a los formularios. Cuando un usuario hace clic en él, envía automáticamente el formulario. Toma un atributo de valor, que define el texto que aparece dentro del botón.

<input type="submit" value="Enter to Win" />

Type Button

Una entrada con un tipo establecido en button crea un botón, que puede ser manipulado por el tipo de detector de eventos onClick de JavaScript. Crea un botón como un tipo de entrada de envío, pero con la excepción de que el valor está vacío de forma predeterminada, por lo que debe especificarse.

<input type="button" value="Submit" />

Type File

Esto define un campo para el envío de archivos. Cuando un usuario hace clic en él, se le solicita que inserte el tipo de archivo deseado, que puede ser una imagen, un PDF, un archivo de documento, etc.

<input type="file" />

El resultado de un input con el type="file" se ve así:

Type Color

Este es un tipo de entrada elegante introducido por HTML5. Con él, el usuario puede enviar su color favorito, por ejemplo. El negro (#000000) es el valor predeterminado, pero se puede anular configurando el valor en el color deseado.

Muchos desarrolladores lo han utilizado como truco para llegar a seleccionar diferentes tonos de color disponibles en formatos RGB, HSL y alfanuméricos.

<input type="color" />

Este es el resultado de un tipo de entrada de color:

Type Search

La entrada con el tipo de búsqueda define un campo de texto como un tipo de entrada de texto. Pero esta vez tiene el único propósito de buscar información. Se diferencia de escribir texto en que aparece un botón de cancelar una vez que el usuario comienza a escribir.

<input type="search" />

Type URL

Cuando el atributo de tipo de una etiqueta de entrada se establece en URL, muestra un campo donde los usuarios pueden ingresar una URL.

<input type="url" />

Type Tel

Un tipo de entrada de tel le permite recopilar números de teléfono de los usuarios.

<input type="tel" />

Type Date

Es posible que se haya registrado en un sitio web donde solicitó la fecha de un evento determinado. La web probablemente usó una entrada con el valor de tipo establecido "date" para lograr esto.

<input type="date" />

Así es como se ve una entrada con tipo de fecha:

Type Datetime-local

Esto funciona como el tipo de entrada fecha, pero también le permite al usuario elegir una fecha con una hora en particular.

<input type="datetime-local" />

Type Week

El tipo de entrada de semana permite al usuario seleccionar una semana específica.

<input type="week" />

Type Month

La entrada con el tipo de mes completa los meses para que el usuario elija cuando se hace clic.

<input type="month" />

Textarea

Hay ocasiones en las que un usuario necesitará completar varias líneas de texto que no serían adecuadas en un tipo de entrada de texto(ya que especifica un campo de texto de una línea).

textarea permite al usuario hacer esto porque define múltiples líneas de entrada de texto. Toma sus propios atributos, tales como cols – para el número de columnas, y rows para el número de filas.

<textarea cols="50" rows="20"></textarea>

Multiple Select Box

Esto es como un botón de radio y una casilla de verificación en un solo paquete. Está incrustado en la página con dos elementos: un elemento select y option, que siempre está anidado dentro de select.

De forma predeterminada, el usuario solo puede elegir una de las opciones. Pero con múltiples atributos, puede permitir que el usuario seleccione más de una de las opciones.

<select>
      <option value="HTML">Select a Language</option>
      <option value="HTML">HTML</option>
      <option value="CSS">CSS</option>
      <option value="JavaScript">JavaScript</option>
      <option value="React">React</option>
</select>

Cómo etiquetar entradas HTML

Es importante asignar etiquetas a los controles de formulario. Cuando están correctamente conectados al campo de entrada a través de su atributo for y el atributo id, es más fácil de usar para el usuario, ya que simplemente puede hacer clic en la etiqueta para acceder a la entrada.

<label for="name">Name</label>
<input type="text" id="name" /> <br />
<label for="check">Agree with terms</label>
<input type="checkbox" id="check" />

Cómo funcionan los formularios HTML

Cuando un usuario completa un formulario y lo envía con el botón Enviar, los datos en los controles del formulario se envían al servidor a través de métodos de solicitud HTTP GET o POST.

Entonces, ¿cómo se indica el servidor? El elemento de formulario toma un atributo de acción, que debe tener su valor especificado en la URL del servidor. También toma un atributo de método, donde se especifica el método HTTP que utiliza para transmitir los valores al servidor.

Este método podría ser GET o POST. Con el método GET, los valores ingresados por el usuario son visibles en la URL cuando se envían los datos. Pero con POST, los valores se envían en encabezados HTTP, por lo que esos valores no son visibles en la URL.

Si no se usa un atributo de método en el formulario, se asume automáticamente que el usuario quiere usar el método GET, porque es el predeterminado.

Entonces, ¿cuándo debería usar los métodos GET o POST? Usa el método GET para enviar datos no confidenciales o recuperar datos de un servidor (por ejemplo, durante búsquedas). Utilizar el POST al enviar archivos o datos confidenciales.

Mini Proyecto: Crea un formulario de contacto básico

Tomemos lo que hemos aprendido sobre los formularios y usémoslo para hacer un formulario de contacto simple. También presentaré algunos conceptos nuevos a medida que avanzamos.

El HTML:

<form action=servidor-ejemplo.com">
      <fieldset>
        <legend>Contacto</legend>
        <div class="form-control">
          <label for="name">Nombre</label>
          <input type="name" id="name" placeholder="Introduce tu nombre" required />
        </div>

        <div class="form-control">
          <label for="email">Email</label>
          <input
            type="email"
            id="email"
            placeholder="Introduce tu Email"
            required
          />
        </div>

        <div class="form-control">
          <label for="message">Mensaje</label>
          <textarea
            id="message"
            cols="30"
            rows="10"
            placeholder="Introduce tu mensaje"
            required
          ></textarea>
        </div>
        <input type="submit" value="Enviar" class="submit-btn" />
      </fieldset>
</form>

¿Qué está pasando en este código HTML?

Primero, un elemento form está envolviendo todos los demás elementos. Tiene una acción establecida para “servidor-ejemplo.com”, un servidor ficticio donde se recibirán los datos del formulario.

Después del elemento de forma, todos los demás elementos también están rodeados por un elemento fieldset con la etiqueta legend debajo.

Usamos el elemento fieldset para agrupar las entradas relacionadas, y la etiqueta legend contiene un título que transmite de qué se trata el formulario.

Los campos name, email, y textarea están todos en un elemento div con la clase asignada "form-control". Por lo tanto, se comportan como un elemento de bloque para facilitar el estilo con CSS.

También están validados con el atributo required, en consecuencia, el formulario no se envía cuando esos campos están vacíos o cuando el usuario no ingresa los valores en el formato apropiado.

Después de todo eso, tendremos el resultado en la siguiente captura de pantalla:

¿Qué tan feo es eso? ¡Necesitamos aplicar algo de estilo!

El CSS:

body {
    display: flex;
    align-items: center;
    justify-content: center;
    height: 100vh;
    font-family: cursive;
  }

 input,
    textarea {
    width: 100%;
    padding: 5px;
    outline: none;
  }

  label {
    line-height: 1.9rem;
  }

  input[type="submit"] {
   transform: translate(2.2%);
   padding: 3px;
   margin-top: 0.6rem;
   font-family: cursive;
   font-weight: bold;
  }

 fieldset {
   padding: 20px 40px;
 }

¿Qué hace el código CSS aquí?

Centramos todo en el cuerpo horizontalmente con Flexbox y verticalmente con una altura de ventana del 100 %. Usamos una familia tipográfica de cursiva.

Le dimos a las entradas y a textarea un ancho del 100% para que tomen todo el ancho del contenedor padre. Las etiquetas tienen una altura de línea mínima de 1,9 rem (30,4 px), por lo que no se quedan demasiado cerca de sus respectivas entradas.

Diseñamos específicamente el botón (botón de tipo de entrada) con la propiedad de transformación para empujarlo hacia el centro, ya que estaba un poco descentrado. Le dimos un relleno de 3px para tener más espacio alrededor. Luego seleccionamos una familia de fuentes cursiva para él con un peso de negrita.

Porque el botón estaba demasiado cerca del textarea, establecemos un margen superior de 0,6 rem para empujarlo un poco hacia abajo.

Le dimos a nuestro elemento fieldset un relleno de 20 px en la parte superior e inferior, con 40 px a la izquierda y a la derecha para separar el borde que crea alrededor de los elementos de formulario en los que está envuelto.

Al final de todo, tenemos el hermoso formulario de la imagen:

Conclusión

Espero que este tutorial te haya ayudado a comprender cómo funcionan los formularios. Ahora debe tener el conocimiento que necesita para integrar formularios en sus sitios web para que pueda comenzar a recopilar datos.

Gracias por leer, y sigue picando código.

Después de jugar con Angular durante mucho tiempo, finalmente se me ocurrió una explicación comprensible de las directivas de Angular. En este artículo, primero entenderemos qué es exactamente una directiva y cómo usarla en Angular. También crearemos nuestras propias directivas personalizadas. ¿Entonces que estamos esperando? Profundicemos en ello.

¿Qué es una directiva angular?

Las directivas son las funciones que se ejecutarán cada vez que el compilador Angular las encuentre. Las directivas angulares mejoran la capacidad de los elementos HTML al adjuntar comportamientos personalizados al DOM.

Las directivas angulares se clasifican en tres categorías.

1. Directivas de atributo
2. Directivas estructurales
3. Componentes

Directivas de Atributo

Las directivas de atributos son responsables de manipular la apariencia y el comportamiento de los elementos DOM. Podemos usar directivas de atributos para cambiar el estilo de los elementos DOM. Estas directivas también se usan para ocultar o mostrar condicionalmente elementos DOM particulares. Angular proporciona muchas directivas de atributos integradas como NgStyle, NgClass, etc. También podemos crear nuestras propias directivas de atributos personalizadas para la funcionalidad deseada.

Directivas Estructurales

Las Directivas Estructurales son las encargadas de cambiar la estructura del DOM. Funcionan agregando o eliminando elementos del DOM, a diferencia de las directivas de atributos, que solo cambian la apariencia y el comportamiento del elemento.

Puede diferenciar fácilmente entre la directiva estructural y la de atributos mirando la sintaxis. El nombre de la Directiva estructural siempre comienza con un prefijo de asterisco (*), mientras que la Directiva de atributos no contiene ningún prefijo. Las tres directivas estructurales integradas más populares que proporciona Angular son NgIf, NgFor y NgSwitch.

Componentes

Los componentes son directivas con plantillas. La única diferencia entre los Componentes y los otros dos tipos de directivas es la Plantilla. Las directivas estructurales y de atributos no tienen plantillas. Entonces, podemos decir que el Componente es una versión más limpia de la Directiva con una plantilla, que es más fácil de usar.

Usando directivas integradas de Angular

Hay muchas directivas integradas disponibles en Angular que puede usar fácilmente. En esta sección, usaremos dos directivas incorporadas muy simples.

La directiva NgStyle es una directiva de atributo que se utiliza para cambiar el estilo de cualquier elemento DOM en función de alguna condición.

<p [ngStyle]="{'background': isBlue ? 'blue' : 'red'}"> Soy una directiva de atributo</p>

En el fragmento de código anterior, estamos agregando un fondo azul si el valor de la variable isBlue es true. Si el valor de la variable isBlue es falso, entonces el fondo del elemento anterior será rojo.

La directiva NgIf es una directiva estructural que se utiliza para agregar elementos al DOM de acuerdo con alguna condición.

<p *ngIf="show">Soy una directiva estructural</p>

En el fragmento de código anterior, todo el párrafo permanecerá en el DOM si el valor de la variable show es true, de lo contrario, se iniciará desde el DOM.

Crear una directiva de atributos personalizada

Crear una directiva personalizada es como crear un componente Angular. Para crear una directiva personalizada, debemos reemplazar el decorador @Component con el decorador @Directive.

Entonces, comencemos con la creación de nuestra primera directiva de atributos personalizados. En esta directiva, vamos a resaltar el elemento DOM seleccionado configurando el color de fondo de un elemento.

Crea un fichero app-highlight.directive.ts en la carpeta src/app y añade el siguiente fragmento de código.

import { Directive, ElementRef } from '@angular/core';

@Directive({

    selector: '[appHighlight]'

})

export class HighlightDirective {

    constructor(private eleRef: ElementRef) {

        eleRef.nativeElement.style.background = 'red';

    }

}

Aquí, estamos importando Directive y ElementRef desde "@angular/core". La directiva proporciona la funcionalidad del decorador @Directive en el que proporcionamos su selector de propiedades a appHighLight para que podamos usar este selector en cualquier lugar de la aplicación. También estamos importando ElementRef que es responsable de acceder al elemento DOM.

Ahora, para que funcione la directiva appHighlight, debemos agregar nuestra directiva al arreglo de declaraciones en el archivo app.module.ts.

import ...;

import { ChangeThemeDirective } from './app-highlight.directive';

@NgModule({

declarations: [

AppComponent,

ChangeThemeDirective

],

imports: [

...

],

providers: [],

bootstrap: [AppComponent]

})

export class AppModule { }

Ahora vamos a usar nuestra directiva personalizada recién creada. Estoy agregando la directiva appHightlight en app.component.html pero puede usarla en cualquier parte de la aplicación.

<h1 appHightlight>Highlight Me !</h1>

El resultado del fragmento de código anterior se verá así.

Creación de una directiva estructural personalizada

En la sección anterior, creamos nuestra primera directiva de atributos. El mismo enfoque se utiliza para crear la directiva estructural.

Entonces, comencemos con la creación de nuestra directiva estructural. En esta directiva, vamos a implementar la directiva *appNot que funcionará justo al contrario de *ngIf.

Crea un fichero app-not.directive.ts en la carpeta src/app y añade el siguiente código.

import { Directive, Input, TemplateRef, ViewContainerRef } from '@angular/core';

@Directive({

    selector: '[appNot]'

})

export class AppNotDirective {

constructor(

    private templateRef: TemplateRef<any>,

    private viewContainer: ViewContainerRef) { }

    @Input() set appNot(condition: boolean) {

        if (!condition) {

            this.viewContainer.createEmbeddedView(this.templateRef);

        } else {

            this.viewContainer.clear();        }

    }

}

En el fragmento de código anterior, estamos importando Directive, Input, TemplateRef y ViewContainerRef desde @angular/core.

Directive proporciona la misma funcionalidad para el decorador @Directive. El decorador Input se utiliza para la comunicación entre los dos componentes. Envía datos de un componente a otro mediante el enlace de propiedades.

TemplateRef representa la plantilla incorporada que se utiliza para instanciar las vistas incorporadas. Estas vistas incorporadas están vinculadas a la plantilla que se va a renderizar.

ViewContainerRef es un contenedor donde se pueden adjuntar una o más vistas. Nosotros podemos usar la función createEmbeddedView() para adjuntar la plantilla incorporada al contenedor.

Ahora, para hacer que la directiva appNot funcione, necesitamos agregar nuestra directiva al arreglo de declaraciones en el app.module.ts.

import ...;

import { AppNotDirective } from './app-not.directive';

@NgModule({

declarations: [

AppComponent,

AppNotDirective

],

imports: [

...

],

providers: [],

bootstrap: [AppComponent]

})

export class AppModule { }

Ahora es el momento de usar nuestra directiva estructural recién creada.

Estoy agregando la directiva appNot en app.component.html pero puede usarla en cualquier parte de la aplicación.

<h1 *appNot="true">True</h1><h1 *appNot="false">False</h1>

La directiva *appNot está diseñada de tal manera que agrega el elemento de plantilla en el DOM si el valor de *appNot es false , justamente lo contrario de la directiva *ngIf.

El resultado del fragmento de código anterior se verá así.

Espero que este artículo haya respondido a la mayoría de sus preguntas sobre las directivas de Angular. Si tiene alguna consulta o duda, no dude en comunicarse conmigo en el cuadro de comentarios.

Desde el principio de los tiempos, el método convencional para mostrar su HTML en una pantalla fue mediante el uso de la renderización desde el servidor. Era la única manera. Cargabas tus páginas .html en tu servidor, luego tu servidor las convertía en documentos útiles en los navegadores de tus usuarios.

La renderización desde el servidor también funcionó muy bien en ese momento, ya que la mayoría de las páginas web eran en su mayoría solo para mostrar imágenes y texto estáticos, con poca interactividad.

A día de hoy ese ya no es el caso. Se podría argumentar que los sitios web en estos días son más como aplicaciones que fingen ser sitios web. Puede usarlos para enviar mensajes, actualizar información en línea, comprar y mucho más. La web es mucho más avanzada de lo que solía ser.

Por lo tanto, tiene sentido que la renderización desde el servidor esté comenzando lentamente a quedar relegada al creciente método de renderización de páginas web en el lado del cliente.

Entonces, ¿qué método es la mejor opción? Como con la mayoría de las cosas en desarrollo, realmente depende de lo que planee hacer con su sitio web. Debe comprender los pros y los contras, luego decidir por sí mismo qué ruta es mejor.

Cómo funciona la renderización desde el servidor

La renderización desde el servidor es el método más común para mostrar información en la pantalla. Funciona convirtiendo archivos HTML del servidor en información utilizable para el navegador.

Cada vez que visita un sitio web, su navegador realiza una solicitud al servidor que contiene los contenidos del sitio web. La solicitud generalmente solo toma unos pocos milisegundos, pero eso depende en última instancia de una multitud de factores:

• Tu velocidad de internet
• la ubicación del servidor
• cuántos usuarios intentan acceder al sitio web
• y qué tan optimizado está el sitio web, por nombrar algunos

Una vez que se procesa la solicitud en el servidor, su navegador recupera el HTML completamente renderizado y lo muestra en la pantalla. Si luego decide visitar una página diferente en el sitio web, su navegador volverá a solicitar la nueva información. Esto ocurrirá cada vez que visite una página de la que su navegador no tenga una versión en caché.

No importa si la nueva página solo tiene algunos elementos que son diferentes a la página actual, el navegador solicitará la nueva página completa y volverá a mostrar todo desde cero.

Tomemos como ejemplo este documento HTML que se ha colocado en un servidor imaginario con una dirección HTTP de example.testsite.com.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Ejemplo de sitio web</title>
  </head>
  <body>
    <h1>Mi sitio Web</h1>
    <p>Esto es un ejemplo de mi nuevo sitio web</p>
    <a href="http://example.testsite.com/other.html.">Link</a>
  </body>
</html>

Si tuviera que escribir la dirección del sitio web que usamos como ejemplo en la URL de su navegador, su navegador haría una solicitud al servidor que utiliza esa URL y esperaría una respuesta de algún texto para mostrar en el navegador. En este caso, lo que verías visualmente sería el título, el contenido del párrafo y el link.

Ahora, suponga que desea hacer clic en el enlace de la página renderizada que contiene el siguiente código.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Ejemplo de sitio web</title>
  </head>
  <body>
    <h1>Mi sitio Web</h1>
    <p>Esto es un ejemplo de mi nuevo sitio web</p>
    <p>Esto es más contenido desde other.html</p>
  </body>
</html>

La única diferencia entre la página anterior y esta es que esta página no tiene un enlace y en su lugar tiene otro párrafo. La lógica dictaría que solo se debería renderizar el nuevo contenido y dejar el resto. Por desgracia, no es así como funciona la renderización desde el servidor. Lo que sucedería en realidad sería que se renderiza toda la página de nuevo, y no solo el contenido nuevo.

Si bien estos dos ejemplos pueden no parecer gran cosa, la mayoría de los sitios web no son tan simples. Los sitios web modernos tienen cientos de líneas de código y son mucho más complejos. Ahora imagine navegar por una página web y tener que esperar a que se muestren todas y cada una de las páginas al navegar por el sitio. Si alguna vez ha visitado un sitio de WordPress, habrá visto lo lentos que pueden ser. Esta es una de las razones del porqué.

Por el lado positivo, la renderización desde el servidor es excelente para SEO. Su contenido está cargado antes, por lo que los motores de búsqueda pueden indexarlo y rastrearlo sin problemas. Algo que no ocurre con el renderizado del lado del cliente. Al menos no simplemente.

Como funciona la renderización por el lado del cliente

Cuando los desarrolladores hablan de renderización del lado del cliente, se refieren a la renderización de contenido en el navegador mediante JavaScript. Entonces, en lugar de obtener todo el contenido del documento HTML en sí, está obteniendo un documento HTML básico con un archivo JavaScript que renderizara el resto del sitio usando el navegador.

Este es un enfoque relativamente nuevo para renderizar sitios web, y realmente no se volvió popular hasta que las bibliotecas de JavaScript comenzaron a incorporarlo en su estilo de desarrollo. Algunos ejemplos notables son Vue.js y React.js.

Volviendo al sitio web que creamos anteriormente, example.testsite.com, suponga que ahora tiene un archivo index.html con las siguientes líneas de código.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Ejemplo de sitio web</title>
</head>
<body>
  <div id="root">
    <app></app>
  </div>
  <script src="https://vuejs.org"type="text/javascript"></script>
  <script src="location/of/app.js"type="text/javascript"></script>
</body>
</html>

Puede ver de inmediato que hay algunos cambios importantes en la forma en que index.html funciona cuando se procesa con el cliente.

Para empezar, en lugar de tener el contenido dentro del archivo HTML, tiene un contenedor div con un ID "root". También tiene dos elementos script justo encima de la etiqueta </body>. Uno que cargará la biblioteca JavaScript de Vue.js y otro que cargará un archivo llamado app.js.

Esto es radicalmente diferente al uso de la renderización desde el servidor porque el servidor ahora solo es responsable de cargar una parte mínima del sitio web. El código principal repetitivo. Todo lo demás es manejado por una biblioteca de JavaScript del lado del cliente, en este caso, Vue.js y código de JavaScript personalizado.

Si hiciera una solicitud a la URL con solo el código anterior, obtendría una pantalla en blanco. No hay nada que cargar, ya que el contenido real debe procesarse mediante JavaScript.

Para solucionarlo, necesita las siguientes líneas de código en el archivo app.js.

var data = {
        title:"Mi sitio web",
        message:"Esto es un ejemplo de mi sitio web"
      }
  Vue.component('app', {
    template:
    `
    <div>
    <h1>{{title}}</h1>
    <p id="moreContent">{{message}}</p>
    <a v-on:click='newContent'>Link</a>
    </div>
    `,
    data: function() {
      return data;
    },
    methods:{
      newContent: function(){
        var node = document.createElement('p');
        var textNode = document.createTextNode('Esto es más contenido desde other.html');
        node.appendChild(textNode);
        document.getElementById('moreContent').appendChild(node);
      }
    }
  })
  new Vue({
    el: '#root',
  });

Ahora, si visita la URL, verá el mismo contenido que vio en el ejemplo del lado del servidor. La diferencia clave es que si hiciera clic en el enlace de la página para cargar más contenido, el navegador no realizará otra solicitud al servidor. Está procesando elementos con el navegador, por lo que utilizará JavaScript para cargar el contenido nuevo y Vue.js se asegurará de que solo se procese el contenido nuevo.

Esto es mucho más rápido, ya que solo está cargando una sección muy pequeña de la página para obtener el nuevo contenido, en lugar de cargar toda la página.

Sin embargo, con el uso de la renderización del lado del cliente, el contenido no se procesa hasta que la página se carga en el navegador y el SEO del sitio web se verá afectado. Hay formas de evitar esto, pero no es tan fácil como lo es con la renderización desde el servidor.

Otra cosa a tener en cuenta es que su sitio web/aplicación no podrá cargarse hasta que TODO el JavaScript se descargue en el navegador. Lo cual tiene sentido, ya que contiene todo el contenido que se necesitará. Si sus usuarios están utilizando una conexión a internet lenta, podría hacer que su tiempo de carga inicial sea un poco largo.

Las ventajas y los contras de cada enfoque

Así que ahí lo tienes. Esas son las principales diferencias entre el renderizado del lado del servidor y del lado del cliente. Solo usted, el desarrollador, puede decidir qué opción es mejor para su sitio web o aplicación.

A continuación se muestra un desglose rápido de los pros y los contras de cada enfoque:

Ventajas renderizando desde el servidor:

1. Los motores de búsqueda pueden rastrear el sitio para un mejor SEO.
2. La carga de la página inicial es más rápida.
3. Ideal para sitios estáticos.

Contras renderizando desde el servidor:

1. Solicitudes frecuentes al servidor.
2. Una renderización generalmente lenta.
3. Recargas de página completa.
4. Interacciones de sitios web pobres.

Ventajas renderizando desde el cliente:

1. Muchas interacciones en los sitios web.
2. Renderizado rápido del sitio web después de la carga inicial.
3. Ideal para aplicaciones web.
4. Sólida selección de bibliotecas de JavaScript.

Contras renderizando desde el cliente:

1. SEO bajo si no se implementa correctamente.
2. La carga inicial puede requerir más tiempo.
3. En la mayoría de los casos, requiere una biblioteca externa.