Supongo que te estás refiriendo a lo que generalmente llamamos un motor de visualización . Esto significa que el lenguaje de fondo se entremezcla en la vista para crear dinámicamente los elementos. Esto luego se representa en el navegador como HTML.
En los últimos años nos hemos dado cuenta de que esto es muy engorroso y complica algunos de los conceptos clave que impulsan marcos como MVC. Debido a que el servidor tiene un rol activo en la creación de la vista, terminamos con un fuerte acoplamiento al código del lado del servidor.
En realidad, las páginas no necesitan ser renderizadas en el servidor como solemos ver con los motores de visualización. Lo que muchos sitios han hecho en los últimos años es que el servidor proporcione los recursos para construir una página dinámica. Básicamente, el servidor pasa HTML y Javascript sin procesar y la construcción mágica ocurre en el lado del cliente.
- ¿Qué significa back-end en el sector privado?
- ¿Qué es más difícil de crear, el front-end del sitio web o el back-end?
- Cómo desarrollar una aplicación de Android para el backend desde cero
- ¿Los desarrolladores web front-end se valoran menos que los desarrolladores back-end? ¿Debo cambiar mi enfoque profesional inmediato de front-end a back-end?
- ¿Node.js se convertirá en la mejor alternativa para el desarrollo de backend en 2015?
Piense en la forma en que AngularJS, EmberJS y KnockoutJS crean páginas. Aparte de servir HTML sin formato, el servidor en realidad no construye las páginas. Los datos se obtienen luego mediante solicitudes POST y GET.
Como resultado, podemos usar puramente Javascript para el front-end y un lenguaje completamente diferente para el back-end (como Ruby). Los dos nunca se cruzan a menos que estén intercambiando datos a través de POST / GET.
