Come si cresce oltre i framework Web per creare il proprio framework applicativo?

Question

Le strutture Web sono fantastiche. Considero il rolling-your-own senza considerare le popolari librerie open source è un odore di design. Quindi, se qualcuno stava per avviare un progetto web senza usare un popolare framework web lato server come Rails e un popolare framework lato client come jQuery, penserei che fossero pazzi, ignoranti o molto di nicchia.

Detto questo, ci sono molte cose che i framework web non cercano di fare per voi. I framework IMHO come Rails e jQuery hanno avuto successo perché cercano di portarti all'80% là, lasciando il prossimo 20% da fare. Fare l'80% permette loro di essere abbastanza flessibili da essere ampiamente usati senza diventare troppo costrittivi o imbarazzanti. Quindi la domanda diventa, cosa fai con quel 20% rimanente, specialmente se la tua applicazione cresce più grande?

Abbiamo sviluppato e mantenuto un'applicazione di Rails/jQuery-UI negli ultimi 1,5 anni. Come affermato, la potenza non dimostrata di queste strutture si è dimostrata ottima per consentirci di velocizzare rapidamente, mantenere la nostra produttività e rafforzare il buon design. Tuttavia, negli ultimi mesi, ho iniziato a pensare che dovremmo essere in grado di sviluppare e distribuire nuove funzionalità ancora più velocemente, e ho iniziato a pensare che non abbiamo costruito abbastanza in cima ai rudimenti che Rails e jQuery danno noi. Le nuove funzionalità apparentemente devono essere sviluppate da quel punto dell'80% ogni volta, invece di un punto preferibile del 90-95%.

Perché le tue strategie per crescere oltre i framework web? Quali tecniche o tecnologie hai utilizzato per spostare il punto di partenza dell'80% più vicino al 90-95%? Quali ostacoli specifici incontrano o superano la creazione del proprio framework o toolkit applicativo? Quali sono stati gli sviluppi dello sviluppo su vanilla Rails e jQuery che ti hanno spinto a cercare un'integrazione più stretta delle applicazioni?

Answer 1

Realmente non faccio molto con i framework lato server perché il nostro backend ASP.NET gestisce già il 90% e tutti i controlli personalizzati lato server tutti gli altri hanno scritto accordi con quell'ultimo 5%.

A termine del lato client c'è poco che si può fare a parte scrivere controlli generici riutilizzabili. Il motivo principale per cui utilizzo jQuery è perché astrae la conformità cross-browser. Lo uso come farei con JavaScript eccetto che funziona senza sforzo in IE.

Crea controlli riutilizzabili su jQuery. Crea plug-in personalizzati. Crea tutto il codice personalizzato che hai scritto molto più generico in modo da poterlo riutilizzare da un progetto all'altro.

Vi consiglio di dare un'occhiata a backbone.js. È un framework MVC lato client che ti consente di personalizzare le tue applicazioni web. Costruire sulla base di tale framework MVC rende il codice molto facile da estendere e molto gestibile. La cosa bella di questo è che hai molto controllo e puoi configurare il tuo framework generico in cima a quello che consente il riutilizzo, riutilizzare il riutilizzo &.

Una delle cose importanti da ricordare è delegare la conformità tra browser a una libreria sottostante come jQuery e quindi creare astrazioni su di essa.

Nella mia esperienza personale, il codice generico che giace in giro ovunque ci sta trascinando molto più dei limiti di jQuery. Forse se tutti scrivessero un grande codice noteremmo limitazioni di jQuery. Non riesco ancora a vedere alcuna limitazione del framework ASP.NET.

Answer 2

I quadri e le biblioteche lasciano che "il 20%" si noti in modo da poterli costruire sopra. Se stai scoprendo che stai ancora lavorando, barebone, a quell'80% di livello ogni volta che devi aggiungere una nuova funzionalità o funzionalità, allora non hai fatto nulla.

Personalmente, ho utilizzato molti framework PHP in cui costruisco librerie e funzionalità personalizzate in cima che aiutano a portare i miei progetti a quel livello del 90-95%. Quella differenza del 15% del tuo progetto è molto importante. Alcuni esempi di quel codice sono cose come: funzioni di utilità, sistemi di autorizzazione, apis interni e gestori di template (che aiutano a rendere i dati con le viste).

Per quanto riguarda lato client, Javascript, librerie (jQuery, Prototype, Dojo ecc.) Sembra che non abbiate pensato a lungo termine. Sempre più persone si stanno rendendo conto che hanno bisogno di iniziare con una struttura applicativa rigorosamente Javascript prima di pensare a quale libreria usare. Le librerie forniscono alcuni metodi standard per associare eventi, selezionare elementi, ecc., Ma nessuno sembra avere realmente una logica applicativa su larga scala integrata. È necessario crearla da sola.

Accoppiamento lasco (o Pub/Sub - Pubblica Sottoscrivi) è diventato molto popolare e ci sono alcuni grandi librerie che aiutano con MVC e lo stato di visualizzazione come jQuery BBQ e Backbone.js (come @Raynos suggerito). Questa logica ti aiuta a ridimensionare e gestire correttamente le nuove funzionalità in modo standard nella tua app. Detto questo, dovresti ancora capire e iniziare con una struttura applicativa priva di biblioteche che capisci. Ho scritto un buon post su questo qui (http://darcyclarke.me/development/javascript-applications-101/) e Addy Osmani offre anche grandi risorse per questo qui (http://addyosmani.com/blog/large-scale-jquery/). Un po 'diverso dal lato server, ti suggerisco di costruire quel 15-20% prima di immergerti nella decisione di quale libreria usare. Dopotutto, hanno molte delle stesse funzionalità e non dovrebbero essere invocati esclusivamente per creare la tua app lato client.

Continuo a pensare che sia meglio avere questi strumenti in atto, piuttosto che crearne di nuovi da zero, ma penso che sia necessario iniziare a costruire il proprio set di strumenti su di essi.