Jag har lĂ€nge arbetat med utveckling av webbapplikationer. Mycket lĂ€nge. Mina första webbapplikationer i miljön skapade jag nĂ€r ordet «google» Ă€nnu inte var ett verb, och för att söka information pĂ„ internet anvĂ€nde folk Yahoo! och Rambler. Jag anvĂ€nde â de hade en mer avgrĂ€nsad sökfunktion och ett mycket mindre överbelastat grĂ€nssnitt Ă€n Yahoo!
Utveckling av applikationer, alla typer av applikationer, inte bara för webben â det Ă€r ett kreativt arbete. Ingen kan nog argumentera emot detta pĂ„stĂ„ende. Och skönhet i skapande Ă€r, precis som praktik inom vetenskaplig kunskap â sanningens kriterium. Men medan vetenskaplig praktik Ă€r objektiv och baserad pĂ„ mĂ€tningar, Ă€r skönhet ett subjektivt Ă€mne som beror pĂ„ vem som betraktar. DĂ€rför stĂ€llde jag mig frĂ„gan, vad anser jag personligen Ă€r en vacker webbapplikation?
(med KDPV, min blick Ă€r en kvinnas, men, IMHO, kvinnans blick pĂ„ KDPV Ă€r mer lĂ€mplig Ă€n mĂ€nnens, eftersom detta Ă€r â !)
Nedanför listar jag mina egna kriterier för vad en webbapplikation för tillfÀllet kan betraktas som vacker. Mycket subjektiv framstÀllning, prÀglad av min personliga erfarenhet. Kanske kommer mina kriterier för det vackra att verka som kriterier för det fula för nÄgon annan. Bli inte förvÄnad, bara för att du har en annan erfarenhet.
Och eftersom du har kommit till nedanstÄende del, var vÀnlig att vara försiktig med kommentarer. Om du kan avbryta lÀsningen av artikeln sÄ snart som det som presenteras dÀr verkar fult eller till och med styggt för dig, sÄ Àr jag, som författare, tvungen att lÀsa alla kommentarer.
Livsmiljö
Protokoll
Jag vet inte ens om det Ă€r vĂ€rt att sĂ€rskilt framhĂ€va detta kriterium. Webbapplikationer lever pĂ„ nĂ€tet och mĂ„ste följa nĂ€tets lagar (protokoll). Huvudprotokollen pĂ„ nĂ€tet Ă€r och . MĂ„nga andra protokoll bygger pĂ„ dem, men för webbapplikationer anser jag att det viktigaste Ă€r (eller snarare, dess utvidgning baserad pĂ„ ). D.v.s., en vacker webbapplikation Ă€r tillgĂ€nglig via HTTPS/TLS (eller alternativt â via HTTP), och andra protokoll (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, ...) gör den mindre vacker för varje ytterligare protokoll som stöds. SjĂ€lva applikationen kan med hjĂ€lp av dessa extra protokoll anvĂ€nda externa resurser.
NĂ€r det gĂ€ller , sĂ„ har jag inte tillrĂ€cklig erfarenhet av att anvĂ€nda detta protokoll med webbapplikationer. Det ser vackert och lovande ut, men hur stabilt och praktiskt det Ă€r â kan jag inte sĂ€ga.
WebblÀsare
Web-applikationen stÄr bara med ena benet pÄ serversidan, det andra benet Àr pÄ klientsidan. Klientsidan Àr webblÀsaren. En modern webblÀsare erbjuder , som ett modernt web-applikation kan och bör anvÀnda till sin fördel. En vacker web-applikation anvÀnder moderna webblÀsarfunktioner och behöver inte fungera i de webblÀsare som inte erbjuder dessa moderna funktioner. Jag förstÄr att Àr en nödbroms, men det Àr inte snyggt. Slutligen, det Àr inte bara utvecklarna som mÄste hÀnga med i moderna teknologier, det gÀller ocksÄ anvÀndare och företag.
ProgrammeringssprÄk
Resan med programmeringssprÄk som anvÀnds för att skapa web-applikationer Àr vÀldigt förvirrande. För klientsidan av web-applikationer finns det massor av teknologier som gör det enklare för utvecklaren att skapa triaden HTML/CSS/JS (det som alla moderna webblÀsare förstÄr). Men jag kom pÄ min tid nÀra i kontakt med och jag tycker att det Àr vackert nÀr utvecklaren kan se den ursprungliga koden i webblÀsaren istÀllet för resultatet av kompilering eller transpiling. DÀrför tycker jag att anvÀndningen av och liknande produkter för att generera klientkod Àr, IMHO, inte snyggt. Ju mer den körbara koden i webblÀsaren liknar den ursprungliga koden som skapats av utvecklaren, desto bÀttre. Tror du inte pÄ det? Försök att debugga koden frÄn GWT i produktion.
PĂ„ serversidan finns det större frihet (Java, PHP, perl, python, C#, Ruby, âŠ), men jag tycker att det Ă€r vackert nĂ€r samma programmeringssprĂ„k â JavaScript â anvĂ€nds bĂ„de pĂ„ serversidan och i webblĂ€saren. Trots allt , och team av likasinnade Ă€r mer produktiva.
MĂ€nsklighet
En vacker web-applikation bör vara anvÀndbar. AnvÀndbar, frÀmst för mÀnniskan som slutlig anvÀndare. DÀrför kan jag inte kalla webtjÀnster för en vacker web-applikation. För en vanlig person (som inte Àr webbutvecklare) Àr de svÄra att hantera. WebtjÀnster Àr vackra pÄ sitt sÀtt,
En vacker web-applikation bör ha ett intuitivt anvĂ€ndargrĂ€nssnitt. Man kan diskutera om Ă€r en ganska subjektiv sak. Men med Ă€r det mycket enklare om anvĂ€ndaren inte kan anvĂ€nda applikationen utan den eftertraktade â dĂ„lig UX, ful web-applikation. De vackraste web-applikationerna i detta avseende kan enkelt anvĂ€ndas av barn som Ă€nnu inte kan lĂ€sa.
Ă terkopplingsskala
För lÀnge sedan kunde program överföras pÄ diskett, nu pÄ USB-minnen eller laddas ner direkt frÄn nÀtet. Att kopiera en vanlig applikation och köra den pÄ en annan maskin Àr en trivial uppgift. Web-applikationer Àr dock nÄgot annorlunda. NÀtverket Àr en global miljö dÀr det inte finns nÄgot behov av att ha kloner av samma web-applikation. Det rÀcker med en Facebook, Twitter, Instagram, Mail.ru eller Yandex. Man kan ha olika web-applikationer inom samma tematiska nisch, men med olika mÄlgrupper (som Facebook och Vkontakte, Mail.ru och Gmail, Google Maps och Azure Maps). De hÄrdvaruresurser som krÀvs för att sÀkerstÀlla global tillgÄng till sÄdana web-applikationer behövs, kan man sÀga, .
Jag har aldrig arbetat med web-applikationer av den hÀr nivÄn som utvecklare och har ingen aning om hur de fungerar dÀr inne. För att sÀkerstÀlla att sÄdana web-applikationer fungerar krÀvs team av relevanta specialister och separata datacenter. Jag beundrar mÀnniskors förmÄga till samarbete i sÄdana skala och skapandet av sÄdana produkter, men min skönhetsideal Àr en web-applikation som kan köras pÄ en separat laptop.
En vacker web-applikation skalar inte bara uppÄt och utÄt (för anvÀndare), utan ocksÄ nedÄt och inÄt (för utvecklare).
Amfibiskhet
För att fÄ tillgÄng till moderna web-applikationer anvÀnds enheter av tvÄ typer:
- datorer (bÀrbara datorer, stationÀra datorer);
- mobila enheter (smartphones och surfplattor);
NÄgonstans i horisonten skymtar ocksÄ "", men tills vidare sÄ.
Datorer skiljer sig frĂ„n mobila enheter lika mycket som landlevande varelser skiljer sig frĂ„n vattenlevande. Det Ă€r olika miljöer och de stĂ€ller olika krav pĂ„ de varelser som lever i dem (program). Vackra web-applikationer Ă€r inte de som liknar , utan de som i vatten â som fiskar, pĂ„ land â som djur, och i luften () â som fĂ„glar.
Jag anser att "" Ă€r oestetiskt, det Ă€r som att försöka sitta pĂ„ tvĂ„ (med SEO â tre) stolar. BĂ€ttre att vara som Fiona frĂ„n Shrek â ensam pĂ„ dagen, men en annan pĂ„ natten. Ja, dyrare. Men bĂ€ttre.
Cross-sharing
Jag har redan nÀmnt i avsnittet "à terkommande Skalbarhet" att nÀtverkets globalitet ger möjligheten att ha en web-applikation pÄ hela planeten. DÀrför mÄste varje web-applikation skilja sig pÄ nÄgot sÀtt frÄn andra för att sÀkerstÀlla sin överlevnad. Trots detta har min mÄngÄriga erfarenhet med (ramverk för att bygga e-handelsbutiker) visat att mellan separata web-applikationer kan det finnas fler likheter Àn skillnader. En vacker web-applikation bör inte bara vara modulÀr, den bör ocksÄ dela sina moduler med andra web-applikationer. PÄ nÄgot sÀtt Äterspeglas denna idé i JSR 168 och JSR 286 samt sÄdana ramverk som , och samma Magento. Ju fler moduler av web-applikationen som anvÀnds av andra web-applikationer, desto vackrare Àr den i min mening. Cross-sharing möjliggör skapandet av mer kvalitativa moduler och, som en följd, mer stabila web-applikationer.
Med moduler menar jag inte bibliotek sĂ„som jQuery eller RequireJS â utan snarare större enheter, som plugins i och . Men för bibliotek gĂ€ller ocksĂ„ tesen att bred spridning av biblioteket gör det mer kvalitativt och stabilt.
Harvardarkitektur
, till skillnad frĂ„n den nuvarande dominanta , innebĂ€r separation av kod och data. Arkitekturen tog aldrig fart, men sjĂ€lva idĂ©n verkar vacker för mig, sĂ€rskilt för web-applikationer. All statisk information (HTML/CSS/JS/BilderâŠ) Ă€r kod. Den kan och bör cachas, antingen pĂ„ serversidan eller klientens sida. Och data Ă€r / (vackert) eller / (lite mindre vackert). Eller WebSockets/JSON (kan vara det bĂ€sta alternativet, men jag har inte provat).
Lokalisering
Det finns tvĂ„ saker som sĂ€rskilt oroar mig vid utveckling av web-applikationer â det Ă€r flersprĂ„kigt grĂ€nssnitt och tidszoner. Jag kommer sjĂ€lv frĂ„n Lettland, dĂ€r vi har tre sprĂ„k i bruk: LV, RU, EN. En vacker web-applikation bör kunna erbjuda möjligheten att anvĂ€nda flera sprĂ„k i sjĂ€lva applikationen, men ocksĂ„ tillĂ„ta utökning av antalet sprĂ„k med hjĂ€lp av externa resurser, sĂ„som . Detta gĂ€ller ocksĂ„ för modulerna som en web-applikation byggs av.
Med tidszoner Ă€r det enkelt, i alla fall nĂ€r det Ă€r oklart hur man ska hantera datum och tid: allt som ligger pĂ„ servern gĂ„r till servern och kommer frĂ„n servern â UTC, allt som visas för klienten â enligt tidszonen i anvĂ€ndarprofilen. Det Ă€r vackert.
Smidesverk istÀllet för "DödsstjÀrnor"
För lÀnge sedan hade varje mer eller mindre stor stad sitt eget smedja. Kanske till och med flera. Vissa bÀttre, andra sÀmre. Det fanns smeder som var kÀnda över hela vÀrlden, och sÄ fanns det sÄdana man gick till av brist pÄ alternativ. Krig, epidemier och naturkatastrofer hÀrjade. Vissa stÀder försvann tillsammans med sin befolkning. Men smideskonsten fortsatte att leva. IstÀllet för de försvunna stÀderna byggdes nya, och i dem dök det ocksÄ upp smeder.
Och nu, titta pÄ en sÄdan tjÀnst som . NÀr rotservrarna gÄr ner, .
Enligt min mening kan en vacker webbtjĂ€nst inte vara av samma storlek som Facebook eller Mail.ru. Det ligger nĂ€rmare "" bĂ„de nĂ€r det gĂ€ller resurser som behövs för byggande och resurser som behövs för att upprĂ€tthĂ„lla funktionalitet. Ja, om Facebook skulle försvinna skulle mĂ€nskligheten inte försvinna, dess funktioner skulle snabbt övertas av andra applikationer (samma i Ryssland och angrĂ€nsande omrĂ„den, Instagram, Twitter, âŠ). ĂndĂ„ Ă€r det oetiskt att lĂ„sa en betydande del av planetens befolkning till en applikation â det Ă€r fult. SĂ€rskilt med mer robusta alternativ som finns (till exempel, ).
Sammanfattning
Om du har lĂ€st till slutet och kĂ€nner förundran â "vad var det hĂ€r?", sĂ„ uttrycker jag mitt uppriktiga deltagande. Jag tvingade dig inte att lĂ€sa detta. Jag försökte bara sĂ€tta mina tankar i ord för att hitta de som tĂ€nker likadant. Kanske kan jag diskutera vissa aspekter av att skapa vackra webbtjĂ€nster och fĂ„ svar pĂ„ mina frĂ„gor. Och jag har mĂ„nga sĂ„dana.
Tack för att du lÀste.
KĂ€lla: habr.com
