¿Qué lenguaje escoger para API + Web SSR?

B

[Borrado] #91 Sep '20

Yo me interesaría más por aprender muy bien como funciona el RDBMS/ORDBMS que estemos usando. Me parece la parte crucial saber como optimizar consultas y en caso de no querer usar un ORM, crearte uno propio para evitar llamar a la base de datos todo lo que se pueda y un poquito más.
Que uses PHP, Perl, Python, C++, Rust, Chichinabi... es lo de menos, y cambiará en unos años por algo "más molón"... se tiene que aprender por que algo se tiene que usar, pero la chicha en DBA está, claramente, en la base de datos.
Si eres bueno en eso, podrás construir piezas más precisas con las tecnologías que se te antoje.

No quiero que se me mal entienda, todas las partes son importantes... pero si recoger los productos y pintarlos por pantalla te lleva >6segundos, la culpa no es del lenguaje, ni del framework... es de tus mierda de consultas. O bueno, de algún fallo en la parte de cliente... si.

cabron #92 Sep '20 Judas

#90

que php de asco como lenguaje es otro debate diferente (bueno realmente no hay debate por que diría que casi todo el mundo está de acuerdo).

El debate concreto era si php se está muriendo o no, y la realidad es que si miras datos que se puedan considerar objetivos, como la encuesta que hace stackoverflow actualizada a este año:

https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

Es que sigue siendo un lenguaje muy usado.

Sobre el tipo de trabajos, si solo lo usan en empresas de mierda o no, pues lo mejor es hacer búsquedas de ofertas para hacerse una idea, filtrando por que paguen de 30000 € para arriba y centrándose en España:

https://es.indeed.com/ofertas?q=php+%E2%82%AC30.000

Creo que la cosa no está como para decir "ve olvidándote de php"

B

[Borrado] #93 Sep '20

Javascript os da asco. Php os da asco... No sé cómo puede ser que los lenguajes más usados web den asco y luego os gusten lenguajes como python que no están hechos para web... No sé... demasiado hater de lo famoso creo yo

1 respuesta

B

[Borrado] #94 Sep '20

#93 En mis tiempos las "grandes" pedían Java para todo... Hibernate, Spring, etc... pero hace años que no miro como está el mercado laboral.
Javascript es un dolor de webos, cualquiera que trabaje con el te lo reconocerá... si es cierto que muchos que lo critican vienen arrastrando una opinión generada en los albores de internet, donde usar javascript en tu sitio era poco menos que un sacrilegio.... Mucho ha llovido desde aquellos tiempos y ha día de hoy se hace software muy competente con el. Para muestra tienes todo lo que se hace con Electron (como Visual Code de Microsoft).
Otros han intentado e intentan relevar a Javascript... veremos como transcurre el devenir de los acontecimientos. Lo cierto es que los motores de Javascript como V8, SpiderMonkey, etc... son bien conocidos, y cada vez más depurados... algo a lo que se tendría que enfrentar un posible relevo.

Usa lo que te de la gana... mira ofertas de empleo y lo que piden. Revisa listas de lenguajes más usados... si lo que quieres es algo con salida laboral.
Yo te puedo decir que si aprendes a usar Python, Javascript, SCSS y alguna tontería más encuentras curro... ¿quieres ganar pasta? especializate en mierdas como SAP... xD

1 respuesta

Ranthas #95 Sep '20

#94uchar:
En mis tiempos las "grandes" pedían Java para todo... Hibernate, Spring, etc... pero hace años que no miro como está el mercado laboral.

En tus tiempos y en los míos y en los de todos, por suerte (o desgracia), Java a nivel empresarial está incrustado en todas partes. Esto no sería malo si fuesen actualizandose, lo malo es que encuentras proyectos enormes hechos en Java 6, y claro, a ver quién es el guapo que se mete en esa selva.

#94uchar:
¿quieres ganar pasta? especializate en mierdas como SAP... xD

Esto es cierto hoy y será cierto dentro de 400 años.

1

kidandcat #96 Sep '20 Gato Amable

#88 Sobre todo colas o corutinas ligeras, ya que la mayoría de los servicios tienen la mayor carga en entrada/salida.

Desde más potentes y empresariales como Java, C#, Rust, Go, Erlang, C++ o mas lightweights como Nodejs, ruby, python, etc

Pero todos esos lenguajes tienen formas de manejar una gran carga I/O y soportan muy bien decenas de miles de peticiones concurrentes. PHP se basa al 100% en los threads del SO sobre el que corra, la capacidad del servidor que le da la entrada via fastcgi, plugin o lo que sea (apache, nginx) y lo bien que este configurado.

Que se puede conseguir un rendimiento bestial con PHP? si, por supuesto, ahi tienes a Facebook hackeando el lenguaje con su HHVM, PHP 7 tiene un rendimiento bestial en comparación con PHP5. Pero poca gente tiene los conocimientos necesarios para tunear nginx+php-fpm para soportar más de 10k peticiones por segundo en un servidor potente (pero estandar, sin irnos a burradas).

En cambio, coge C#, Java, Go, Rust o cualquiera similar, monta un servidor http estandar, metelo en la misma máquina, y dime si usa más del 50% de CPU a las 10k/s

JuAn4k4 #97 Sep '20

Desde react hooks, no tiene sentido alguno usar redux. Con context y setState consigues lo mismo. Como hookstate por ejemplo.

Yo no pondría react redux en ningún proyecto, ninguno.

1 respuesta

QuitCat #98 Sep '20 Gafe

#97 Eso se ha discutido ya en el hilo que tenemos de React, pero a modo de resumen en mi opinión decir que no pondrías redux en ningún proyecto es un error:

React Redux, aunque por debajo usa Context, tiene implementado varias optimizaciones que no tendrías usando Context por mismo. Depende de las dimensiones y características del proyecto, te puede penalizar bastante priorizar Context sobre ReactRedux
Hay varias librerías que tienen funcionalidades ya interesantes, middlewares, thunks, sagas, offline, ...

Una cosa es que tenga mucho boilerplate, sea engorroso de usar a veces y que a veces se use sin ser necesario. Otra cosa es decir que no se pondría en ningún proyecto

1 respuesta

B

[Borrado] #99 Sep '20

#98 yo diría que a partir del lanzamiento de hooks y cositas tipo useReducer... Redux es aún más innecesario.

Usuarios habituales

Tags