Corri verso il lato client nello sviluppo web

Negli ultimi mesi ho riconosciuto una grande eccitazione per lo scripting lato client nello sviluppo web. Ma mentre le tecnologie lato server sono mature, stabili e ben accettate dagli sviluppatori back-end, le tecnologie lato client sono immature (vale a dire rispetto al grande framework lato server) e non apprezzate da molti sviluppatori di lunga data. Tuttavia, al giorno d'oggi tutti stanno facendo uno sviluppo lato client. Personalmente mi aspetto che questi grandi framework lato server scompaiano in circa 2-5 anni, osservando l'attuale tendenza.

Perchè è così? In che modo il nuovo e "diffuso" lato client in via di sviluppo in HTML5 / JS potrebbe essere superiore alle soluzioni lato server grandi e ben congegnate?

Questo è vero:

Corri verso il lato client nello sviluppo web

Ma non è limitato al lato client, è un movimento full stack.

So che potrebbe essere sorprendente. Per favore, ascoltami.

Perchè è così? In che modo il nuovo e "diffuso" lato client in via di sviluppo in HTML5 / JS potrebbe essere superiore alle soluzioni lato server grandi e ben congegnate?

Prima di tutto, entrambi sono ben ponderati.

In secondo luogo, perché è meglio.

Buona domanda.

Ma "meglio" è soggettivo, quindi la risposta alla tua domanda è: cosa è specificamente migliore?

Rivivi la domanda:

In che modo lo sviluppo "diffuso" lato client in HTML5 / JS potrebbe essere superiore alle grandi soluzioni lato server?

Because small is nimble.
And big is clunky.

È flessibilità.

Non sembra un grosso problema. Vero? Flessibilità.

Tuttavia, la flessibilità è alla base di tutto. Un miglioramento della flessibilità: migliora tutto.

Manutenibilità. Estensibilità. Scalabilità. Modularità. Usabilità. UX.

Ed è più veloce da implementare. Questa è la realtà Più veloce e migliore.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, non è una moda passeggera e non andrà via. Stiamo vedendo solo i semi di una tecnologia che crescerà per fornire contenuti informatici e comportamento di interazione ai tablet. Compresse.

Gli smartphone sono stati l'adozione dei mass media più veloce dalla TV negli anni '50. Ora non abbiamo solo smartphone, ma anche tablet.

Già in sviluppo su Mozilla e Windows il sistema operativo che verrà eseguito su dispositivi futuri nei loro mercati -> HTML / JS.

Rimangono molte soluzioni e innovazioni.

Sta emergendo uno stack completo di JS, basato sulla flessibilità.

Spero che aiuti.

Questa storia ha sempre avuto due facce; entrambi i codici lato server e lato client hanno i loro pro e contro.

I vantaggi dello scripting lato client includono:

• Può essere reso più reattivo, sono possibili modifiche estese senza round-trip del server.
• Il codice viene eseguito sul client, riducendo l'utilizzo delle risorse sul server.
• La separazione tra logica e presentazione diventa fisica.
• A volte è più facile bilanciare il carico, soprattutto se si utilizza l'autenticazione per richiesta.

Ma lo script lato server presenta anche molti vantaggi:

• Controlli la macchina su cui viene eseguito il codice.
• Praticamente tutto è possibile - se il tuo server può farlo, così può fare il tuo script.
• Gli utenti non possono modificare lo script prima di eseguirlo.
• Gli utenti non possono utilizzare gli script blocker per impedire l'esecuzione dello script.
• Gli utenti non possono vedere cosa fa il tuo script, possono solo osservare l'output.
• Il codice funzionerà in modo affidabile con tutti i client che puoi immaginare, inclusi screen reader, browser Web testuali, spider dei motori di ricerca, raschiatori, accumulatori, robot IRC, macchine di fascia bassa, browser bloccati da script, lo chiami.
• È meno probabile che i plug-in dell'utente si rompano.

Per le applicazioni Web altamente dinamiche, l'approccio incentrato sul cliente è sempre stata una scelta popolare, perché è l'unico modo per fornire un'esperienza utente decente come un desktop reattivo: senza script sul lato client, ognuna delle azioni dell'utente richiede un round- viaggio, che significa almeno mezzo secondo di ritardo, in genere più. Ma per un sito informativo che è fondamentalmente solo un mucchio di pagine statiche servite da un database (diciamo, Wikipedia), il vantaggio è marginale, mentre i vantaggi dello scripting lato server sono ancora schiaccianti.

L'hype osservato deriva da una combinazione di due recenti sviluppi:

1. HTML5 e la sua corona di tecnologie correlate. Ci è voluto troppo tempo, ma ora abbiamo finalmente uno standard che contiene tutto ciò di cui hai bisogno per creare quelle applicazioni web dinamiche simili a desktop senza accumulare hack e browser mainstream che le implementano correttamente.
2. Potenza di elaborazione disponibile. I PC desktop di oggi sono altrettanto potenti di un server Web entry-level, i cellulari di livello cliente sono praticamente i computer desktop del 2005 e le moderne implementazioni javascript sono abbastanza efficienti da inclinare l'equilibrio delle prestazioni: ormai, le risorse lato client sono più economiche del server risorse.

In effetti, nulla è cambiato in termini di capacità di approccio incentrate sul server e sul client; ciò che è cambiato è che il client-centric è ora più facile ed economico da fare e offre prestazioni migliori rispetto a qualche anno fa, rendendolo una scelta praticabile per molte più applicazioni di quanto non fosse in passato.

Il lato server sarà sempre presente. Non puoi sederti sul lato client per tutto. Ad esempio, non si desidera utilizzare un design MVC Backbone.js per il microcontrollore che invia parametri in tempo reale da una gru a ponte del piano di produzione.

Non credere all'hype.

Nel 2009 ho effettuato il passaggio da un framework PHP lato server a una soluzione ExtJS lato client legata ai servizi Web lato server.

I motivi della migrazione per me sono stati:

1. Migliore sicurezza riducendo la quantità di endpoint e codice sul server.
   Passando ai servizi Web, si convalida l'input al limite del servizio Web e si ha un controllo più preciso sull'I / O del server. Non esiste un livello UI sul lato server per confondere l'architettura di sicurezza.
2. Prestazioni migliorate a causa di un minor numero di round trip del server
   L'architettura cambia in modo che i recuperi di dati possano avvenire meno frequentemente e che i dati possano essere memorizzati nella cache locale con il rendering dell'interfaccia utente che non richiede affatto un roundtrip. I viaggi di andata e ritorno sono ciò che uccide le prestazioni delle app Web.
3. Prestazioni migliorate grazie alla cache dell'interfaccia utente
   Il livello dell'interfaccia utente può essere completamente ospitato su una rete CDN. Ho persino creato app Web offline inserendo il codice dell'interfaccia utente nella cache dell'app HTML5.
4. Maggiore fedeltà dell'interfaccia utente (controlli avanzati lato client)
5. Gli sviluppatori di terze parti possono utilizzare la stessa API utilizzata dal mio front-end e posso riutilizzare facilmente le API tra i moduli se condividono le funzionalità.
   Ciò significa meno sviluppo, QA, documentazione, ...
6. Mi piace programmare in JavaScript meglio di PHP, Python o Java

Ma non commettere errori, ciò che sta accadendo ora è un clamore. Si spegnerà e molte app Web useranno di nuovo un'architettura UI lato server.

Un altro fattore che sta guidando l'entusiasmo per le soluzioni lato client è la crescita delle app mobili. Se crei un sito Web fortemente basato su JavaScript e AJAX sul lato client e crei anche app iOS e Android native, c'è una buona probabilità che tutti e tre possano utilizzare gli stessi servizi REST per eseguire tutti i loro dati su "avanti e indietro" .

Prima di tutto, l'utente non vede (e talvolta non si preoccupa nemmeno) di cosa non sia il server. Non importa quanto bene sia scritto il codice lato server, gli utenti non apprezzeranno l'applicazione se la parte client non viene eseguita bene. A volte anche la bella interfaccia utente è più importante della funzionalità.

Un server di hosting grande e potente è piuttosto costoso. È molto più economico implementare parte della logica (tranne la convalida) sul lato client. Quindi potresti usare un server più piccolo (quindi, più economico) di hosting, dal momento che non sarebbe caricato così tanto.

Questi sono i motivi per cui, nonostante l'instabilità, le tecnologie lato client stanno guadagnando più popolarità. Inoltre, JS e HTML / CSS sono supportati da (quasi) tutti i browser moderni.

Queste due parti delle applicazioni non possono esistere separatamente. E Internet non sembra andarsene da nessuna parte nel prossimo futuro.
Non credo che big server-side frameworksprobabilmente spariranno neanche. Ci saranno sempre aziende che possono permettersele e useranno i loro vantaggi significativi.

Lo sviluppo Web sul lato client è fortemente associato ai browser Web e alle loro modifiche nel tempo. La soluzione che fornisci ora potrebbe non funzionare entro un paio di mesi a causa di cambiamenti significativi nei motori di rendering delle pagine dei browser web. Alcuni browser sono / erano incompatibili con gli standard e quindi richiedevano uno sforzo ancora maggiore da parte degli sviluppatori solo per ottenere il risultato atteso.

Esistono alcune soluzioni che tentano di risolvere questo problema. Ad esempio, se usi jquery hai la certezza che il tuo script funzionerà sui browser supportati da questa particolare libreria jquery. Ma spetta solo ai suoi autori fornire la compatibilità con alcuni / la maggior parte / tutti i browser. La domanda è: quale squadra ti supporterà meglio. Sarà squadra di motools, squadra jquery, altra squadra? Se non forniscono supporto per un determinato browser Web, il progetto potrebbe non funzionare in quel browser.

L'eccitazione che sembri avere è in circolazione da molto tempo. L'ho visto quando Shockwave e il suo successore Flash sono stati introdotti, c'è stato un "grande ritorno" di interfacce utente ricche una volta che sono state spedite librerie js complesse, prima con motools, poi con jquery (ho iniziato a usarle in questo ordine). C'erano Flex e JavaFX. Ma nessuno di loro può ottenere una grande quota sul mercato. Alcuni richiedono plug-in che spesso espongono l'utente finale a vulnerabilità della sicurezza, altri potrebbero non funzionare sul lato client a causa di alcune impostazioni personalizzate (ad esempio JavaScript disabilitato nel browser dei client).

Dall'altro lato, la soluzione lato server viene in genere scritta una sola volta. Non devi preoccuparti che tutto fallirà e dovrà essere riscritto una volta spedito il nuovo Firefox / Chrome / IE / Opera. Non devi inoltre preoccuparti che il client tenterà di manomettere la tua app e / o corrompere i dati.

Assolutamente d'accordo con i tuoi sentimenti. Credo anche che, al di là di ciò che stai dicendo, vedremo un drastico calo del REST e una forte impennata nei websocket per il modo principale in cui i siti comunicano con i loro server. Vert.x, Node.js ecc. L'intero lato server, così come il lato client, sta passando alla programmazione guidata dagli eventi. Java EE, PHP, Rails, ecc. Devono tutti adattarsi o perderanno molto rapidamente.