Buenas, soy un estudiante de informática y actualmente estoy estudiando C++. En mis ratos libres sin embargo me gustaría ir aprendiendo un poco de desarrollo web pero al meterme en el tema he descubierto que hay mucha gente que en lugar de aprender a crearlas de 0 eligen aprender a usar frameworks con sus templates (wordpress, joomla...) para conseguir resultados similares ahorrando mucho tiempo. Obviamente el tema de poder emplear el menor tiempo posible en aprender algo me resulta atractivo, pero no se si es conveniente en mi caso, ya que intentaré dedicarme a esto en un futuro. ¿Qué recomendáis según vuestra experiencia que haga? ¿Aprender a utilizar los frameworks desde el principio? ¿o aprender lenguajes de programación web? Si debería hacer esto último, ¿cuáles son los lenguajes de programación que debería aprender, ya sea por utilidad, potencia, popularidad etc..?
Joomla y wordpress no son framewoks, son cms, frameworks serian symfony, django, rails, springboot, etc.
Si te gusta programar pasa de cms, ya es que todo mas rollo tocar configuración, hacer pequñas modificaciones a un plugin o un template, es verdad que todo se puede hacer mas rapido pero si quieres programar no te va a gustar. Los cms normalmente solo lo se usa para hacer webs con contenido que se actualiza, rollo blogs, no aplicaciones como tal, aunque si que hay tiendas hechas con cms suele ser a base de juntar plugins.
Sobre aprender sin nada o con un framework, si quieres ser competente, tienes que aprender ambas.
Como bien ha dicho #2 Joomla y Wordpress son CMS (Content Management Systems) son aplicaciones para gestionar contenidos.
Para aprender, te recomiendo que cojas experiencia en OOP y empieces a hacer algo de 0, cuando sepas hacer algo desde la nada, podrás meterte a usar algún framework, te facilitarán la vida pero sabrás qué está sucediendo por debajo. Si sólo aprendes un framework, en el momento que quieras cambiar de lenguaje o framework te será como aprender de 0 otra vez. Creo que es importante coger una base sólida haciendo proyectos desde 0 (aunque sean proyectos con fines de aprendizaje), eso no quita que para proyectos con tiempos de entrega y donde hace falta ser productivo, tires directamente a por el framework que mejor se adapte a la situación.
#2 deja bastante claro todo.
Me gustaría añadir que lo mejor para aprender es crear un proyecto con una idea e intentar desarrollarla, ahí es cuando realmente te salen mil problemas y aprendes.
Obviamente para hacer eso tienes que saber las fases que tienen un proyecto y un poco de los lenguajes que vas a usar.
Sinceramente, creo que lo mejor es aprender un poco de todo (aunque recomiendo pasar de CMS por ahora).
Comienza aprendiendo Javascript a pelo, haz un cursito de desarrollo web básico y no te metas ni en JQuery. Aprende a usar vanilla JS de una forma eficiente, juega un poco con HTML y CSS, y cuando creas que ya puedes construir cosillas, entonces sí es cuando deberías pasar a aprender cosas más high level.
Aqui la mayoría de la gente suele tirar más por backend o frontend, pero yo te recomiendo que le eches un buen vistazo a ambas cosas. Con sólo JS puedes jugar con ambas partes de una manera bastante top, hacer aplicaciones muy bestias sin tener que aprenderte otro lenguaje es una cosa muy positiva si lo que buscas es encontrar trabajo.
Dicho esto, cuando ya te sientas "seguro" haciendo webs serverless con HTML, CSS y JS (o incluso con algo de PHP si lo has visto), este sería el roadmap que te recomendaría:
- Aprende a usar NodeJS + Express de una forma sencillita. Define rutas, comunícate con tu base de datos (aprende a usar una MySQL o una MongoDB), define business logic en el backend...
- Métete en React, Angular o Vue. Escoge una de las tres, y ve aprendiendo a usarlo. Verás que te va a ahorrar una cantidad de trabajo de la ostia, y que tus soluciones van a lucir mucho más limpias y funcionales.
- Aprende BIEN cómo funciona Javascript por dentro. Cuando ya sepas construir cosillas con el lenguaje y te hayas peleado con sus extrañas movidas, tendrás cierta "big view" de cómo funciona este lenguaje tan querido por muchos, y odiado por tantos otros. Te vendrá de putísimo lujo ver cómo realmente funciona y a adoptar sus funcionalidades más nuevas: .map, .reduce, async/await, etc... y por supuesto, trata de entender bien cómo funciona su asincronismo, que me conozco bastantes ingenieros que todavía no saben ni chainear una serie de métodos asíncronos xdd.
- Si te has metido en Angular quizá ya lo hayas visto, pero incluso en ese caso, te recomiendo que dediques un tiempo específicamente a revisar Typescript. Aprende de Object Oriented Programming si todavía no sabes, y trata de aplicar tu conocimiento dentro de este útil superset de Javascript, que hará que tu código luzca muchísimo más limpio, mantenible y escalable, que antes.
- Revísate otras tecnologías útiles como RxJs (la puta pana), Redux, Webpack... y si te mola el desarrollo móvil, mírate Ionic si has tirado por Angular, o React Native si has tirado por React. Esto te permitirá hacer PWAs, ojocuidao'. - Métete de nuevo con Node y Express a tope para aprender de verdad a manejar el backend. Usa PM2 para definir servicios escalables en producción de Node, usa Airflow para aprender a definir jobs que tengan que hacer tareas determinadas cada x tiempo (adiós cronjobs!), y aprende a enlazar distintos procesos de Node. Si tienes que hacer procesado de datos o cálculos complicados, te recomiendo aprender a hacerlo con Python y a conectar estos pequeños procesos con tus API endpoints y jobs de Node (esto es facilico así que no te preocupes).
Con esto no te faltará trabajo ni de puta coña, y podrás producir prácticamente el 95% de software que se fabrica a diario, con un performance tremendo y una buena velocidad de desarrollo.
¡Suerte!
Muchas gracias a todos! Todas las respuestas me han ayudado mucho, ya lo tengo todo mucho mas claro (incluso la diferencia entre Framework y CMS lul)
Con sólo JS puedes jugar con ambas partes de una manera bastante top,
Claro, claro...
Con esto no te faltará trabajo ni de puta coña, y podrás producir prácticamente el 95% de software que se fabrica a diario
Eso es mas que discutible.
con un performance tremendo y una buena velocidad de desarrollo.
Lo de la velocidad no lo voy a discutir, porque el 99% del tiempo es hacer npm install...
Pero la performance ni de coña
Eso es mas que discutible.
Recibo una oferta cada 3-4 días con el LinkedIn cerrado, y 1.5 de media cada día si lo tengo abierto, y no tengo tantos años de experiencia, así que te puedo asegurar que estás hablando sin saber. Y son buenas ofertas. También tengo mucha movida de Java pero estoy dejando claro en mi LinkedIn que a día de hoy mayoritariamente ando con JS/TS, que es a lo que apuntan la mitad de mis ofertas (apróx. el 50% apuntan a Angular o Ionic).
Lo de la velocidad no lo voy a discutir, porque el 99% del tiempo es hacer npm install...
Pero la performance ni de coña
A esto lo llamo yo no saber usar estas herramientas apropiadamente y sólo saber lo básico de lo básico de lo básico. En mi empresa lo usamos (tanto para airflow jobs, como APIs) y estamos lidiando con millones de peticiones diarias en un servidor súper palero que ni siquiera está aprovechando bien el clustering con Node, pero oye, que es una mierda porque lo dicen en MV.
#8 Hombre, o defines bien lo de millones de peticiones diarias o esa referencia no sirve de nada: 1 millón req/hora son 300 por segundo.
#9 Pues eran creo que entre 15 y 40 millones al día, captando en cada req una string que se guarda en una base de datos (trazado de cookies). Es una instancia única de Node que corría sobre la versión 4 (pegó un acelerón de velocidad bastante tocho cuando migramos a Node 9), que ni siquiera corría sobre pm2 ni aprovechaba clustering, y que estaba hospedada en un VPS bastante mierder. Eso sí, no usa Express, lo cual quizá ayude a acelerar las cosas un poco.
Como dato curioso, usamos Node para airflow jobs (una buena cantidad de ellos) y API endpoints con Express, y Python para procesado de datos (ML y cosillas chulas así), y nuestro único problema tecnológico ahora mismo está en el MySQL porque es más lento que el demonio, y la MongoDB que está a full de capacidad y tenemos que estar metiendo instancias nuevas. Cabe destacar también que pegar el salto de Node 4 a 9 ayudó bastante a la estabilidad y performance de las APIs y los jobs, así como que aprendieran bien a gestionar el asincronismo en JS, pues la verdad que mucha idea no tenían y alguna vez tuvieron problemas de async waterfalls y movidas por el estilo, fruto de no saber usar bien el lenguaje.
Ahora todo el backend está migrándose a Typescript y luce mucho mejor que antes, como puede resultar obvio. La adopción de usar las nuevas cositas funcionales de JS (.map, .reduce, .filter...) y async/await también mejoró bastante la calidad del código, especialmente en aquellos jobs que se ocupaban de hacer transformaciones enormes de datos y que cuyos scripts eran más feos que el demonio.
Como siempre digo, creo que la clave con JS es pasarse a TS y aprender un poco bien cómo funciona el lenguaje. Si no se usa bien, es una puta mierda de lenguaje. Si se usa bien, es la puta pana. El eterno problema de JS con respecto a otros lenguajes más "serios" es que "te deja" cagarla al no ser tan verbose.
#10 No quiero entrar en una discusión sobre JS. Lo que me refería es que a hacer 300req/sec no es nada y no hace falta optimizar practicamente nada para conseguir eso, el overhead suele estar en otras partes del código mal hechas.
Sobre Mysql es difícil decir nada que no sea lo típico de utilizar caches a nivel de app y hacer bulks de insert/updates, optimizar queries y olvidarse de orms y demás. Para verlo más en detalle hace falta analizar el problema, ver métricas y ver qué está haciendo la app.
Un server de mysql se come unas cuantas miles de inserciones/updates por segundo a no ser que lo tengas tan petado que debas particionarlo/hacer sharding.
#11 Es lo que tiene tener la DB con poco menos de un petabyte de datos puramente textuales con montones de scripts tirando de ellos constantemente xD. Ya dije hace tiempo en la empresa que quizá tendría sentido pasarse a Oracle DB o contratar a un experto en administración de DBs para particionar mejor la carga, pero la migración sería un dolor de huevos importante. Pero créeme que a estas alturas el problema parece ser propio de MySQL como tal y de hecho por eso hemos tenido que tirar de MongoDB para guardar gran parte de los datos que se requieren a menudo (que no son poca cosa, ya son más de 600 GB), porque si no ya sí que no le daba la olla al MySQL.
#11MTX_Anubis:hacer 300req/sec no es nada y no hace falta optimizar practicamente nada para conseguir eso
Ya, ya, el tema es que el hardware contratado para ese VPS es irrisorio, y vamos, que si intentásemos montar un Java por ejemplo ahí, no le daría la puta olla entre la JVM y demás.