Feda /dev/

Traber

#20211

$('[data-autor="umbranoide"]').hide()

Versión userscript:

spoiler
1
eXtreM3

Saludos en telegram Hexan @HeXaN

RaCe

alguno sois proaso de react native?

ya conozco ReactJS y ahora tengo algo de tiempo libre y le quiero meter a ReactNative, he mirado por internet a ver cual es el mejor tutorial/guía, parece q este tiene buena pinta:
https://github.com/react-made-native-easy/book

alguien en la sala q lo corrobore y/o recomiende algo mejor? cualquier otro recurso/tip es bienvenido tb

ty :kissing_heart:

2 respuestas
B

#20223 El problema de react native es que a la hora de la verdad vas a terminar desarrollando un montón de componentes para android/ios y es un handicap muy grande para mi.

Overburden

#20220 libera el código!

r2d2rigo

#20223 primer truqui de React Native:

  • no uses React Native.
3 1 respuesta
Ranthas

Me ha hecho gracia el del Holandés Errante, real como la vida misma.

2
gohrum

porque hablais de curro, hablad de dev.

Zerokkk

#20226 Mira que eres tonto, con acritud. Y te lo dice alguien que no usa React Native ni tiene intenciones de hacerlo próximamente xD.

1 1 respuesta
Ranthas
$.ajax({
   ...,
   success: function(response) {
      alert(response);
   },
   error: function(exception) {
      $("html").html(exception.responseText);
   }
})

Directo al riñón

afhn

Necesito un poco de ayuda gente. Llevo 4 semanas en modo hibernación por el tema de haber estado enfermo y a mi cerebro le está costando despegar. Estoy intentando acabar parte de la documentación pero no consigo hilar y me está constando empezar la segunda etapa, el word está ahora tal que así:

Es que no consigo entender los puntos, al menos me gustaría ir empezando por el primero y seguramente los siguientes caigan del tirón como una fila de domino, pero necesito despegar y no lo consigo, a ver si alguien que entienda de esto se le ocurre a qué se refiere con el primer punto, recordad que es un juego RPG web el que estoy haciendo:

Estoy jodidamente bloqueado y encima tengo que retocar la primera etapa y me queda otra más, y para el viernes todo xd.

Joder, joder, estoy realmente jodido.

Fyn4r

Pero el problema es el estado del arte o los criterios?
Si es lo primero, básicamente tendrás que poner en antecedentes a quien se lea eso. Explicar qué es eso de un juego RPG web, cómo hace eso para dar dinero, qué es lo que puede aportar tu juego a la industria, etc. Vender la moto vamos xD

1 respuesta
afhn

#20232 es que a ver, en el proyecto ahora estoy en la parte de documentación relacionada a la fase de diseño de un proyecto o planificación, la cosa es que en esta parte entra el contenido que hay en la imagen; lo de análisis, recopilación y todo eso, y los criterios que se utilizarán para evaluar dicha fase, el problema viene que no tengo ni puta idea de nada de eso ni sé por dónde empezar.

Y el primer punto esta es la explicación que tenemos para ello: esto es lo mismo que investigación contextualizada en contexto, lugar, competencia, posicionamiento, etc, buscar el apoyo de datos.
Vamos, me deja igual e incluso más dudoso xd.

eondev

#20229 pero para que react native teniendo Xamarin?

1 1 respuesta
Zerokkk

#20234 A ver, es muy sencillo: actualmente, tanto Ionic 4, como React Native, como Nativescript, como Xamarin, como Flutter, te granjearán unos resultados muy buenos sin necesidad de complicarte la vida contratando al doble de programadores y teniendo que mantener dos code bases. Es que sencillamente, a día de hoy tiene absolutamente 0 sentido hacer una app nativa a menos que hablemos de juegos que requieran de mucha máquina, o apps muy, muy, muy, MUY necesitadas de potencia de procesamiento. Esto es así, y los quejicas como el personaje este me tienen bastante harto con sus concepciones atrasadísimas, tratando de convencer al resto de users de qué es bueno y qué no, cuando no tocan otra tecnología que aquella con la que trabajan a diario, desde hace años.

Le escuezca a quien le escuezca, esta es la realidad, y por eso las últimas versiones de las tecnologías top en desarrollo híbrido son el state-of-art de la industria y por eso ésta está empezando a usarlas a cascoporro desde hace relativamente poco tiempo.

PD: y lo que quería decir con esto es que todas estas tecnologías tienen rendimientos no tan diferentes entre sí, y yo creo que a día de hoy depende más del gusto que tengas por una u otra, que otra cosa.

2 respuestas
HeXaN

Menos mal que la realidad no es así.

3
Lecherito

Eso diselo a la bateria de los moviles a ver si las tecnologias no se diferencian.

1 respuesta
GlitterSpark

#20235 incluso en facebook reescribieron la aplicacion en objective-c dejando atras html5. Ellos mismos lo dijeron la razon principal fue por perfomance.

1 respuesta
Zerokkk

#20238 Sí, ya, ¿eso hace cuántos años? Yo hablo del estado actual, pero actual actual. Mismamente hace 2 años la situación ya hubiese legitimado esa decisión, hace un año quizá hasta podriamos haber encontrado intrincadas razones para ello, pero a día de hoy es absurdo.

#20237 eso díselo a las views precompiladas del nuevo Ionic o a la transpilación completa que Flutter y demás hacen xD. La diferencia con respecto a una app full native es marginal. Desde un punto de vista de negocios, veo muy pocas situaciones a día de hoy en las que salga más rentable y efectivo hacer apps de forma nativa.

Y eh, alguno se pensará que lo digo porque no me conozco las tecnologás nativas, pero yo programé Android y hasta me gustaba, eh. Con Kotlin debe molar mazo, de hecho. Pero las cosas son como son.

3 respuestas
Lecherito

#20239 Desde el punto de vista de negocios como poco te quitas a todos los artisans del palo. Con eso simplemente sobra.

2
eZpit

#20239

Especializado en Java y JavaScript

Zerokkk
1
r2d2rigo

#20235 mas harto me tiene a mi tu hipsterismo de shippear proyectos en tecnologias que no estan ni en alpha, y encima ofenderte cuando alguien te lleva la contraria.

Puede que haya tocado mas frameworks moviles de los que te crees, despues de todo me gano la vida con ello:

  • Xamarin: su toolset lo mata, cada vez menos pero puede que te toque wrappear una libreria cabrona.
  • Nativo: perfecto si quieres un look nativo en ambas plataformas y te puedes permitir las paladas de dinero que cuesta tender devs dedicados.
  • Flutter: basado en un lenguaje que ni esta maduro ni se le espera, cuando Google se canse de quemar dinero ya lo matara.
  • React Native: como Flutter pero con el a;adido de depender de Facebook. Bueno, eso y quien en su sano juicio shippearia cosas mission critical en JS.
  • Ionic: HtMl tAmBiEn Es PrOgRaMaR.

No existe la bala de plata, pero subirse al carro de JS everywhere es de tener las miras cortas nivel los que dicen que Java tiene los dias contados.

1 respuesta
Zerokkk

#20242

Puede que haya tocado mas frameworks moviles de los que te crees, despues de todo me gano la vida con ello

Joder chico, que los hayas tocado no significa que sepas usarlos bien. Ningún lenguaje o framework se aprende a usar del todo bien hasta que no llevas un buen tiempo con ello y shippeas proyectos en ello, y a juzgar por lo que dices, no creo que jamás hayas tratado siquiera de tratar de entender bien JS y su environment, del cual por cierto, dependen gran parte de las tecnologías que tanto criticas.

Xamarin: su toolset lo mata, cada vez menos pero puede que te toque wrappear una libreria cabrona.

¿No crees que esta frase es aplicable prácticamente a cualquier lenguaje o tecnología? :thinking:

Nativo: perfecto si quieres un look nativo en ambas plataformas y te puedes permitir las paladas de dinero que cuesta tender devs dedicados.

Hombre, el look puede hacerse prácticamente igual a nativo al menos en Ionic, no te sé decir ya en el resto si hay tanta manga ancha... pero por supuesto nadie te va a negar que si te sale el dinero de las orejas, mantener dos apps nativas no es mala idea si necesitas un rendimiento perfecto.

Flutter: basado en un lenguaje que ni esta maduro ni se le espera, cuando Google se canse de quemar dinero ya lo matara.

Justifique su respuesta.

React Native: como Flutter pero con el a;adido de depender de Facebook. Bueno, eso y quien en su sano juicio shippearia cosas mission critical en JS.

A ver, francamente, siempre vi React más como algo genial para cosas pequeñas pero que puede fallar para temas más grandes, así que en ese sentido te entiendo, pero es que directamente el tema de las apps "mission critical" requiere más bien de testing intensivo que otra cosa. Lo suyo es usar Clojure/Haskell/Scala, pero desconozco hasta qué punto puedes hacer apps nativas usando un lenguaje 100% funcional, sin tener que tirar de workarounds [i}javeros[/i] y así. No veo qué podría tener de malo hacer una app mission critical mismamente en TS full funcional con el testing suficiente, aunque... te admito perfectamente que no me fiaría tanto de ello como de los lenguajes anteriormente mencionados. No programaría un reactor nuclear en Javascript, vaya xD.

Ionic: HtMl tAmBiEn Es PrOgRaMaR.

Ole tus huevos con tus reducciones al absurdo. ¿Tú has comprobado cómo funciona Ionic ahora, con su último launch? Esa herramienta desde las versiones 2 avanzadas es una maravilla, y el hecho de que su codebase te sirva de PWA, es una ventaja de la que no puedes simplemente pasar. Puedes hacer apps súper personalizables, bonitas, con buen rendimiento y extrapolarlas a una web, ¿qué más quieres? xD.

#20242r2d2rigo:

No existe la bala de plata, pero subirse al carro de JS everywhere es de tener las miras cortas nivel los que dicen que Java tiene los dias contados.

Defiendo que se puede aplicar la filosofía de "JS everywhere" precisamente porque veo en mi día a día que es posible, aunque yo lógicamente admito que no siempre es la mejor solución. ¿Que necesito programar algo que NO puede fallar? Scala y testing intensivo. ¿Necesito una app que tiene que estar abierta en una tablet 24/7 y tiene que aguantar la batería al máximo y gestionar muchos datos? Hago una app nativa en Java y otra en Swift. ¿Necesito un backend corporativo absurdamente gigantesco y que requerirá del curro de muchos programadores a la vez? Probablemente escogería Java o C# (.NET), aunque ojo porque cada vez veo más posibilidades de enfrentar hasta las apps más grandes con Node y Typescript. ¿Necesito hacer un programa que sea increíblemente eficiente y que obtenga el mejor rendimiento posible? Uso C++.

Pero eso no quita que para el 90% de las situaciones, donde las condiciones no son tan extrañas ni los requerimientos tan bestiales, el mundillo de JS/TS me sigue pareciendo lo mejor que aplicar a ellos. Por si a alguien no le había quedado clara mi postura con el tema.

1 respuesta
eZpit

A ver, francamente, siempre vi React más como algo genial para cosas pequeñas pero que puede fallar para temas más grandes, así que en ese sentido te entiendo, pero es que directamente el tema de las apps "mission critical" requiere más bien de testing intensivo que otra cosa. Lo suyo es usar Clojure/Haskell/Scala, pero desconozco hasta qué punto puedes hacer apps nativas usando un lenguaje 100% funcional, sin tener que tirar de workarounds [i}javeros[/i] y así. No veo qué podría tener de malo hacer una app mission critical mismamente en TS full funcional con el testing suficiente, aunque... te admito perfectamente que no me fiaría tanto de ello como de los lenguajes anteriormente mencionados. No programaría un reactor nuclear en Javascript, vaya xD.

Zerokkk

Lo he leído incontables veces y sigo sin enteder ninguna de sus 4 frases.

1 1 respuesta
HeXaN
#20243Zerokkk:

Lo suyo es usar Clojure/Haskell/Scala,

¿Por qué? xD

1 respuesta
GlitterSpark

#20239 creo que se reescribio alrededor del 2014/2015. Pero vamos, que ahi siguen, desarrollando en objective-c y objective-c++ como lenguajes principales a dia de hoy

1 respuesta
Zerokkk

#20245 No es necesario pero lenguajes funcionales como éstos son lo mejorcito para apps mission critical, aunque otros lenguajes puedan perfectamente desempeñar esa función.

#20246 Normal hombre... en 2014-2015 no estaban tan avanzados estos stacks híbridos como lo están ahora en 2018. Creo que sería interesante que revisáseis la evolución de stacks como Ionic, sus mejoras en rendimiento, y cómo poco a poco lo están "solidificando" para que haya versiones LTS (que comenzarán desde ahora, con la 4, que salió hace nadísima). Lógicamente sin una versión LTS, hay que andarse con cuidado a la hora de usar estas movidas.

#20244 ¿Qué es lo que no entiendes?

1 respuesta
eZpit

#20247

A ver, francamente, siempre vi React más como algo genial para cosas pequeñas pero que puede fallar para temas más grandes, así que en ese sentido te entiendo, pero es que directamente el tema de las apps "mission critical" requiere más bien de testing intensivo que otra cosa.

1º Ves React para cosas pequeñas pero "que puede fallar para temas mas grandes", que es una frase completamente absurda. La utilidad de React para un proyecto depende de las especificaciones y necesidades del proyecto, no de su tamaño.

2º Crees que un lenguaje o framework (y sus bugs) no son problemas mientras hagas un "testing intensivo". Everything is gonna be alright.

3º Estamos hablando de desarrollo móvil y mencionas "apps mission critical" que ya me darás un ejemplo, porque lo único que se me ocurre "critical" en mobile es la seguridad y es algo que no tiene una mierda que ver con un lenguaje de programación o programación funcional.

Lo suyo es usar Clojure/Haskell/Scala, pero desconozco hasta qué punto puedes hacer apps nativas usando un lenguaje 100% funcional, sin tener que tirar de workarounds [i}javeros[/i] y así.

4º Pones ejemplos de lenguajes funcionales random que no tienes pinta ni de conocer, que no tienen nada que ver con el desarrollo de apps y que ni cuentan con tooling para mobile y te quedas tan ancho.

5º Dices "workarounds javeros" que no significa nada.

No veo qué podría tener de malo hacer una app mission critical mismamente en TS full funcional con el testing suficiente, aunque... te admito perfectamente que no me fiaría tanto de ello como de los lenguajes anteriormente mencionados. No programaría un reactor nuclear en Javascript, vaya xD.

6º Dices "app mission critical" y sigues con "TS full funcional". Como ves que no es creible, luego añades "con el testing suficiente" para que parezca que eres un profesional que sabe lo que hace. Justo después de defender JS & TS, como no te has convencido ni a ti mismo, aclaras que todo lo que has dicho es un non-sense y que te fiarías más de otros lenguages.

No programaría un reactor nuclear en Javascript, vaya xD.

7º Nos aclaras que no construirías un reactor nuclear en Javascript, cuando estábamos hablando de mobile.

2 2 respuestas
Zerokkk

#20248 No soy yo precisamente quien ha sacado la soplapollez de apps mission critical en el ámbito de las app mobile. Con workarounds javeros me refiero a intentar emular el paradigma funcional con Java (cosa que más o menos es posible a día de hoy); sé perfectamente que esos lenguajes que nombré no tienen tooling para mobile apps.

Vamos, que has entendido mi mensaje como te dio la puta gana, sin entender el contexto, y sólo buscando la crítica fácil. Bien hilado, eh.

1 respuesta
eZpit

#20249 Te invito a que rebatas todas mis criticas, especialmente las que te dejan más en evidencia, no solo las 2 más obvias para ti.

1 1 respuesta
Tema cerrado