¿Puede prosperar como desarrollador o diseñador web simplemente usando marcos y bibliotecas que existen sin escribir mucho código usted mismo?

Tengo que estar de acuerdo con Giordon en esto, la respuesta simple es No. Es posible que pueda “sobrevivir” si está produciendo sitios simples con una funcionalidad común o similar, pero ciertamente no puede “prosperar”.

Aquí es importante hacer una distinción entre “programación web“, “desarrollo web” y “diseño web”. Una distinción extremadamente generalizada entre estas tres cosas podría ser que los programadores son chicos / chicas que escriben código y crean nuevas funcionalidades, los desarrolladores son chicos / chicas que usan controles, marcos y conectan funcionalidades preconstruidas para llegar a una solución, los diseñadores son los chicos / chicas que hacen que todo se vea bonito. Para “prosperar”, sus habilidades deben cubrir estas tres áreas, con un enfoque más detallado en una (o más) de ellas. Esencialmente, para diseñar un sitio, debe tener una comprensión de lo que el desarrollador o programador necesitará de su diseño para que las cosas funcionen, o para programar un sitio, debe comprender cómo interactúan los elementos de diseño o diseño. entre sí y cómo funcionan los protocolos web subyacentes, qué es REST, etc.
descargo de responsabilidad: La distinción anterior es simplemente para ilustrar la diferencia en el área focal en el desarrollo web. No me refiero a ofender a nadie con palomas agujereando su área específica.

Además, hay una gran cantidad de opciones cuando se trata de seleccionar un marco o una biblioteca, por lo que sin comprender al menos hasta cierto punto la tecnología subyacente y la forma en que interactúan todas estas cosas, será difícil para usted tomar decisiones informadas.

No. A diferencia de lo que todos dicen, no. ¿Por qué? Simplemente necesito un contraejemplo. Esto es JavaScript

La mayoría de los desarrolladores de “javascript” usan jQuery, o algún otro marco para todo su trabajo. De hecho, la mayoría de ellos rara vez tocan el lenguaje subyacente, particularmente debido a lo generalizados que son estos marcos, por no decir que no son sorprendentes o malos, pero así son las cosas.

La mayoría de las personas no se preguntan mucho sobre cuánto evoluciona JavaScript o no. Cuando salió jQuery, no había la opción de un selector CSS en JavaScript. Es decir,

jQuery(elements) 

no tenía equivalente de JavaScript. En ese momento, hace bastantes años, los equivalentes más cercanos eran

 document.getElementById('#id') document.getElementsByTagName('tag') 

¿Y si quisieras elementos con una clase específica? Esto ni siquiera estaba cerca, había un bucle sobre un conjunto de elementos y descubría cuáles tenían el nombre de clase correcto. Pero ahora, JavaScript tiene el querySelector que parece hacer todo lo que hace el selector jQuery.

Otro ejemplo es el aumento de las implementaciones de AJAX. Muchos navegadores tienen implementaciones diferentes, lo que fue una gran perra . Esto no fue particularmente culpa de JavaScript en ese momento, los navegadores eran muy “yo, yo, yo” y posesivos. Aquí hay un código de placa de caldera para simplemente configurar una solicitud ajax de navegador cruzado (que no se garantiza que funcione en todos los navegadores)

 var ajax = { request: function(url, requestType, callback, queryString) { var ids = ['MSXML2.XMLHTTP.3.0', 'MSXML2.XMLHTTP', 'Microsoft.XMLHTTP'], xhr; // Simplification of this check while essentially doing the same thing if (window.XMLHttpRequest) { xhr = new XMLHttpRequest(); } else { for (var i = 0; i < ids.length; i++) { try { xhr = new ActiveXObject(ids[i]); break; } catch(e) {} } } // Calling a function to return a function is redundant. // Do what you're trying to with as little extra as possible. xhr.onreadystatechange = function() { callback(xhr); }; xhr.open(requestType, url, true); if (requestType.toUpperCase() === 'GET') { // When initiating a get request, the send function needs no arguments at all. xhr.send(); } else if (requestType.toUpperCase() === 'POST') { xhr.send(queryString); } // If you want to be extra careful, include an else here to handle a bad requestType } } 

y como lo hace jQuery?

 jQuery.ajax(); 

El punto es que, en ese momento, jQuery fue un contenedor que arregló muchas cosas para nosotros. JavaScript es el único lenguaje para la ejecución del lado del cliente en el navegador, por lo que fue más difícil cambiar tanto como quisiéramos de una manera más rápida.

Diría que es posible que pueda sobrevivir de esa manera si está satisfecho con los diseños de fábrica de fábrica o está trabajando para alguien que está de acuerdo con eso. Si está buscando hacer algo grandioso y romper los límites de alguna manera, dése cuenta, entonces debe comprender cómo escribir las cosas desde cero para obtener un mayor nivel de control. Me parece que hay un punto en el que en realidad se hace más difícil (o casi imposible) doblar un complemento a su voluntad y tiene sentido desecharlo y escribirlo de la manera que desea que se comporte.

Sí. Al usar marcos y bibliotecas que ya existen, aún necesitará escribir código, pero su código probablemente será más específico del producto / proyecto y menos general. Le dará más tiempo para resolver cosas que son específicas del dominio y se preocupará menos por el código general que probablemente ya se haya hecho muchas veces antes. Es cierto que el código general sería algo más grande y menos óptimo y dependería de los marcos que utilice, así que elija sabiamente, pero por otro lado, siempre puede consultar el código del marco y aprender de allí.

Su pregunta asume que el desarrollo web se trata de crear nuevos sitios. En realidad, la mayor parte del trabajo consiste en actualizar los sitios existentes.