Existe una verdad publicada, y existe una vida real. La verdad publicada está siempre en la cresta de la ola, convirtiendo en el non plus ultra a la última invención presentada. Y esto es especialmente, fundamentalemente válido en el universo de la tecnología. Se afirma que una tecnología determinada debe ser adoptada ya, porque tiene un efecto x, y soluciona un problema z "como nunca hasta ahora". Sucede como las invitaciones de todos los proveedores de servicio de Internet y telefonía: si le hiciéramos caso a todos, deberíamos reemplazar nuestro contrato de servicio una o dos veces por semana. Por eso aprecio las reflexiones de un veterano en el desarrollo de aplicaciones. A veces, el rey está desnudo.
Las recomendaciones de Beau Beauchamp se dirigen a quienes desarrollan en la categoría de Javascript, pero se pueden extender, cambiando algunos nombres, a otras categorías.
En primer lugar, su presentación:
I’ve been a web application developer for over 20 years. I’ve seen all kinds of UI libraries come and I’ve seen them go. I’ve been in the industry long enough to know that just because a framework is new and cool and “OMG! Everyone cool is using it!”, doesn’t mean you should use it too.
Speaking from a purely enterprise perspective, which is probably the same perspective you should be looking at if you plan on building the next great SaaS app, you should be thinking long and hard about incorporating any kind of library or UI framework into your app.
Right now you’re small, nimble, you code things in record time and push to production with a minimal number of steps. You’re probably not writing tests, or very few, and all of your builds are done automagically locally.
But if you get successful, really successful, like with hundreds of developers working on your app kind of successful, all of that is going to change. You are going to become an enterprise; and in the enterprise, we do things very differently in the “real world” than you do in the “startup world”.
Su lista de recomendaciones se hacen dialogando contra lo que se pudiera practicar en una pequeña "startup". Cambie el destinatario por otros. Hay muchos candidatos.
La primera recomendación:
Cualquier cambio es costoso
Every step you add into the deployment process costs you time and money in ways you cannot see when you’re a small startup.
If you unwisely choose the technology stack for your app, especially the UI, it’s going to take a tremendous amount of resources to rip it out and update it
Evite tecnologías de moda que se actualizan demasiado rapidamente, o que vienen y van
UI is notorious for flavor-of-the-day UI libraries and frameworks. Handlebars, React, Vue, AngularJS, Angular 2, 4, 5, 6, 7, and now fucking 8. All in the span of what—6 years? I’m sure there are bunch of others I’ve not even heard of yet.
“Angular is not a fad, Beau.” Sorry, it is. In the enterprise you cannot be changing out libraries and updating shit this fast. You won’t have the budget or the resources (“resources” is enterprise-speak for the people who will now hate you).
Each time some library or framework “updates” or changes versions, it costs you money.
Costo versus reales beneficios
Think about which UI framework you’re thinking of using in your project or next project. What is the framework really doing for you? Is it saving you time or just giving your application some cool “whiz-bang” features?
“It gives us model and DOM binding! A huge time saver.” Fine, you can do that with a jQuery plugin that you don’t have to compile. Next?
“It gives us an MVC on the front end with model-bound templates for a SPA (single-page application).” Fine, but this is not saving you time; in fact, it’s costing you more time in building pages, compiling, and SPA’s are terrible if you need real SEO and accurate analytics.
At the end of the day, by the time you are done installing all of the crap that you need to actually run the super-really-cool fad-tech UI framework, it’s not easier at all, and all you have done is saddled your enterprise team with hours and hours of frustrating local setup and configuration and IDE integration. It’s nonsense.
Yea, we do it; but it’s NOT easier. I’ve seen enterprise devs saddled with setting up the new wiz-bang technology spend literally weeks working out the bugs in their development environments because someone decided to install a new “framework”.
And at the end of the day, the UI framework, much more of a pain in the ass, much more difficult to debug, than it was helpful in achieving a good clean easy-to-mange front-end.
Diga no a compiladores de UI. Mantengo este punto porque está en su lista, y tiene importancia en este caso. Aquí, la generalización está en qué línea de desarrollo recomienda:
I once interviewed with a really big video game company. You know what their development policy was changing to? Plain ECMA (JavaScript) and CSS. No compilers. No CoffeeScript. No TypeScript. They even ripped out jQuery. I was impressed.
Now why were they doing this? Because they needed to save time and money. Over the years developers had come into their teams, added in all kinds of wiz-bang fad tech into their UI, and then left. Now their teams were saddled with all of the UI garbage that was costing the company millions in developer hours each time Angular or whatever SPA library had an update or an upgrade. We’re talking about touching literally millions of lines of code and tens of thousands of files across the enterprise.
The reason these fad-tech UI libraries even exist is because of bored engineers working at big tech, like Google, Facebook, Twitter, etc. But at the end of the day nothing works better and is easier to debug and maintain than just pain JS and native CSS.
No hay comentarios.:
Publicar un comentario