¿Cómo crece más allá de los marcos web para crear su propio marco de aplicación?

Question

Los marcos web son geniales. Considero que rodar por cuenta propia sin tener en cuenta las bibliotecas populares de código abierto es un olor de diseño. Entonces, si alguien fuera a iniciar un proyecto web sin utilizar un framework web popular como el servidor, como Rails, y un framework popular como el de jQuery, pensaría que estaban locos, ignorantes o muy especializados.

Dicho esto, hay muchas cosas que los frameworks web no intentan hacer por usted. Los marcos de trabajo en mi humilde opinión como Rails y jQuery han sido exitosos porque tratan de llevarlo al 80% allí, dejando el próximo 20% para que usted haga. Hacer 80% les permite ser lo suficientemente flexibles como para ser ampliamente utilizados sin llegar a ser demasiado constrictivos o incómodos. Entonces la pregunta es, ¿qué haces con ese 20% restante, especialmente a medida que tu aplicación crece?

Hemos desarrollado y mantenido una aplicación Rails/jQuery-UI durante los últimos 1,5 años. Como se dijo, el poder ilimitado de esos marcos resultó ser excelente para acelerarnos rápidamente, mantener nuestra productividad y reforzar el buen diseño. Sin embargo, en los últimos meses, he empezado a pensar que deberíamos poder desarrollar y desplegar nuevas funciones aún más rápido, y comencé a sentir que no hemos construido lo suficiente sobre los rudimentos que dan Rails y jQuery. nos. Al parecer, las nuevas características se han desarrollado a partir de ese punto del 80% cada vez, en lugar de un punto preferible del 90-95%.

¿Por qué son sus estrategias para crecer más allá de los marcos web? ¿Qué técnicas o tecnologías usaste para mover ese punto de inicio del 80% más cerca del 90-95%? ¿Qué obstáculos específicos encuentra o supera la construcción de su propio marco de aplicaciones o conjunto de herramientas? ¿Cuáles fueron los problemas del desarrollo en vanilla Rails y jQuery que lo empujaron a buscar una integración de aplicaciones más estricta?

Answer 1

Realmente no hago mucho con los marcos del lado del servidor porque nuestro back-end ASP.NET ya maneja el 90% y todos los controles personalizados del lado del servidor que todos los demás han tratado con ese último 5%.

En términos del lado del cliente, hay poco que puede hacer aparte de escribir controles genéricos reutilizables. La razón principal por la que uso jQuery es porque abstrae el cumplimiento de varios navegadores. Lo uso como lo haría con JavaScript, excepto que funciona sin esfuerzo en IE.

Construye controles reutilizables en la parte superior de jQuery. Haga un plugin personalizado. Haga que todo el código personalizado que haya escrito sea mucho más genérico para que pueda volver a utilizarlo de un proyecto a otro.

Te recomiendo que eches un vistazo a backbone.js. Es un framework MVC del lado del cliente que realmente te permite personalizar tus aplicaciones web. Construir sobre un marco MVC de este tipo hace que el código sea muy fácil de extender y muy manejable. Lo bueno de esto es que tiene mucho control y puede configurar su propio marco genérico además de que permite su reutilización, reutilización & reutilización.

Una de las cosas importantes para recordar es delegar el cumplimiento de varios navegadores a una biblioteca subyacente como jQuery y luego crear abstracciones en la parte superior.

En mi experiencia personal, el código genérico malo por todas partes nos está arrastrando mucho más que las limitaciones de jQuery. Tal vez si todos escribieran un código excelente, notaríamos las limitaciones de jQuery. Realmente no puedo ver ninguna limitación del marco ASP.NET todavía.

Answer 2

Los marcos y bibliotecas dejan ese "20%" que notas para que puedas construir encima de ellos. Si descubre que todavía está trabajando, barebones, en ese nivel del 80% cada vez que necesita agregar una nueva característica o funcionalidad, entonces no ha hecho nada.

Personalmente, he utilizado muchos frameworks de PHP donde construyo bibliotecas personalizadas y funcionalidades superiores que me ayudan a llevar mis proyectos a ese nivel de 90-95%. Esa diferencia del 15% de tu proyecto es muy importante. Algunos ejemplos de ese código son cosas como: funciones de utilidad, sistemas de permisos, apis internos y administradores de plantillas (que ayudan a representar datos con sus vistas).

En cuanto al lado del cliente, Javascript, bibliotecas (jQuery, Prototype, Dojo, etc.) parece que no ha pensado a largo plazo. Cada vez más personas se dan cuenta de que necesitan comenzar con una estructura de aplicación estrictamente Javascript antes de pensar qué biblioteca usar. Las bibliotecas proporcionan algunas formas estándar para enlazar eventos, seleccionar elementos, etc., pero ninguna parece tener una lógica de aplicación a gran escala incorporada. Necesita construirla usted mismo.

acoplamiento débil (o Pub/Sub - Publicar suscribir) se ha vuelto muy popular y hay algunas grandes bibliotecas que ayudan con MVC y ver su estado como jQuery BBQ y Backbone.js (como sugirió @Raynos). Esta lógica le ayuda a escalar y administrar adecuadamente las nuevas funciones de una manera estándar en su aplicación. Dicho esto, aún debe comprender y comenzar con una estructura de aplicación puramente sin biblioteca que usted comprenda. He escrito una buena publicación acerca de esto aquí (http://darcyclarke.me/development/javascript-applications-101/) y Addy Osmani también ofrece excelentes recursos para esto aquí (http://addyosmani.com/blog/large-scale-jquery/). Un poco diferente del lado del servidor, le sugiero que construya ese 15-20% antes de sumergirse en la decisión de qué biblioteca usar. Después de todo, tienen muchas de las mismas características y no se deben confiar únicamente para construir su aplicación de cliente.

Todavía creo que es mejor tener estas herramientas en su lugar, en lugar de construirlas desde cero, pero creo que debe comenzar a construir su propio conjunto de herramientas encima de ellas.