Rush to client-side nello sviluppo web

Questo è vero:

Rush to client-side in web development

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

So che potrebbe essere sorprendente. Per favore, ascoltami.

Why is that so? How could the new and "diffuse" client-side developing in HTML5/JS possibly be superior to big and well thought server-side solutions?

Prima di tutto, entrambi sono ben pensati.

In secondo luogo, perché è meglio.

Buona domanda.

Ma "meglio" è soggettivo, quindi la risposta alla tua domanda è, in particolare, è meglio?

Rivedi di nuovo la domanda:

How could "diffuse" client-side developing in HTML5/JS possibly be superior to big server-side solutions?

Because small is nimble.
And big is clunky.

È flessibilità.

Non sembra un grosso problema. Lo fa? Flessibilità.

However, flexibility underlies everything. One improvement in flexibility - improves everything.

Maintainability. 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, is not a fad and it will not go away. We are only seeing the seeds of a technology that will grow to provide computing content and interaction behavior to tablets. Tablets.

Gli smartphone sono stati la più rapida adozione da parte dei mass media dalla TV negli anni '50. Ora, non solo abbiamo smartphone: abbiamo i tablet.

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

Restano molte soluzioni e innovazioni.

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

Spero che questo aiuti.

Questa storia ha sempre avuto due lati; Sia il lato server che il codice lato client hanno i loro pro e contro.

I vantaggi dello scripting lato client includono:

• Può essere reso più reattivo, sono possibili ampie modifiche 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, specialmente se si utilizza l'autenticazione per richiesta.

Ma lo script sul lato server ha anche molti vantaggi:

• Sei tu a controllare la macchina su cui gira il codice.
• È possibile praticamente qualsiasi cosa - se il tuo server può farlo, lo può anche il tuo script.
• Gli utenti non possono modificare lo script prima di eseguirlo.
• Gli utenti non possono utilizzare i blocchi di script per impedire l'esecuzione dello script.
• Gli utenti non possono vedere ciò che fa lo script, possono solo osservare l'output.
• Il codice funzionerà in modo affidabile con tutti i client che puoi immaginare, tra cui screen reader, browser web testuali, spider dei motori di ricerca, scrapers, accumulatori, robot IRC, macchine super-low-end, browser con script, tu lo chiami.
• I plug-in degli utenti hanno meno probabilità di interruzione.

Per le applicazioni web altamente dinamiche, l'approccio incentrato sul cliente è sempre stato una scelta popolare, perché è l'unico modo per fornire un'esperienza utente reattiva e reattiva sul desktop: senza lo scripting lato client, ognuna delle azioni dell'utente richiede un viaggio di andata e ritorno, che significa almeno mezzo secondo di ritardo, tipicamente di più. Ma per un sito informativo che è fondamentalmente solo un mucchio di pagine statiche servite da un database (ad esempio, wikipedia), il vantaggio è marginale, mentre i vantaggi dello scripting lato server sono ancora schiaccianti.

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

1. HTML5 e la sua corona di tecnologie correlate. Ci è voluto troppo tempo, ma ora abbiamo finalmente uno standard che contiene tutto il necessario per creare applicazioni web dinamiche simili a desktop senza accumulare hack e browser mainstream che li implementano correttamente.
2. Potenza di elaborazione disponibile. I PC desktop commodity di oggi sono potenti quanto 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 il bilanciamento delle prestazioni: ormai le risorse lato client sono più economiche del server risorse.

In realtà, nulla è cambiato in termini di ciò che gli approcci incentrati sul server e centrati sul cliente sono buoni; ciò che è cambiato è che il client-centrico è ora più facile ed economico da fare e ha prestazioni migliori rispetto a pochi anni fa, rendendolo una scelta praticabile per molte più applicazioni di quanto non fosse una volta.

Il lato server sarà sempre intorno. Non puoi sedere sul lato client per tutto. Per esempio,  non vuoi utilizzare un progetto MVC Backbone.js per il tuo microcontrollore che ti invia parametri in tempo reale da una gru a ponte per produzione.

Non credere all'hype.

Ho fatto il passaggio nel 2009 da un framework PHP lato server a una soluzione ExtJS lato client legata ai servizi Web lato server.

I motivi della migrazione per me erano:

1. Maggiore 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 ottiene un controllo più preciso sull'I / O del server. Non esiste un livello dell'interfaccia utente lato server per confondere la tua architettura di sicurezza.
2. Prestazioni migliorate a causa di un minor numero di roundtrips del server
   L'architettura cambia in modo che i recuperi di dati possano accadere meno spesso e i dati possono essere memorizzati nella cache localmente con il rendering dell'interfaccia utente che non richiede affatto un round trip. I viaggi di andata e ritorno sono ciò che uccide il rendimento delle app Web.
3. Prestazioni migliorate grazie alla cache della UI
   Il livello dell'interfaccia utente può essere completamente ospitato su un CDN. Ho persino creato app web offline spostando il codice dell'interfaccia utente nella cache dell'app HTML5.
4. Maggiore fedeltà dell'interfaccia utente (controlli avanzati sul 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. Scoppierà e molte app Web useranno di nuovo un'architettura dell'interfaccia utente lato server.

Un altro fattore che stimola l'entusiasmo per le soluzioni client è la crescita delle app mobili. Se crei un sito web basato principalmente su JavaScript e AJAX sul lato client e crei anche app native per iOS e Android, ci sono buone probabilità che tutti e tre possano utilizzare gli stessi servizi REST per eseguire tutti i loro dati in iting e fro'ing .

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

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

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

Queste due parti di applicazioni non possono esistere separatamente. E Internet non sembra partire da nessuna parte nel prossimo futuro.
Non credo che anche big server-side frameworks possa sparire. Ci saranno sempre aziende che possono permettersele e useranno i loro significativi vantaggi.

Lo sviluppo web lato client è strongmente accoppiato con i browser web e cambia loro nel tempo. La soluzione fornita ora potrebbe non funzionare in 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 risultati attesi.

Ci sono alcune soluzioni che cercano di risolvere questo problema. Ad esempio, se usi jquery, ti assicuri che lo script funzionerà sui browser supportati da questa particolare libreria jQuery. Ma spetta solo agli autori fornire la compatibilità con alcuni / la maggior parte / tutti i browser. La domanda è quale squadra ti sosterrà meglio. Sarà squadra di motool, squadra jquery, altra squadra? Se non forniscono supporto a un particolare browser Web, il tuo 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'è stata una "grande rimonta" di interfacce utente ricche una volta che sono state spedite complesse librerie js, prima con motools, poi con jquery (ho iniziato a usarle in questo ordine). C'era Flex e JavaFX. Ma nessuno di loro può ottenere una grande quota nel mercato. Alcuni richiedono plug-in che nel tempo 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 solitamente scritta solo una volta. Non è necessario preoccuparsi che tutto fallirà e dovrà essere riscritto una volta che il nuovo Firefox / Chrome / IE / Opera verrà spedito. Non devi nemmeno preoccuparti che il cliente proverà a manomettere la tua app e / o a corrompere i dati.

Assolutamente d'accordo con i tuoi sentimenti. Credo anche che al di là di quello che stai dicendo vedremo un drastico calo di REST e un massiccio aumento dei websocket per il modo principale in cui vediamo i siti comunicare ai loro server. Vert.x, Node.js ecc. L'intero lato server, così come lato client, si sta spostando verso la programmazione guidata dagli eventi. Java EE, PHP, Rails, ecc. Hanno tutti bisogno di adattarsi o perderanno molto rapidamente.