Olen veebirakendusi arendanud juba pikka aega. Kaua aega tagasi. Teie esimesed veebirakendused keskkonnas Lootos doomino Ma lõin neil päevil, mil sõna "google" ei olnud veel tegusõna ja Internetist teabe otsimiseks kasutasid inimesed Yahoo! ja Rambler. Ma kasutasin seda Infootsing'om - neil oli kitsenev otsing ja mitte nii kole ülekoormatud liides nagu Yahoo!

Rakenduste arendamine, kõik rakendused, mitte ainult veebi jaoks, on loominguline töö. On ebatõenäoline, et keegi selle väitega vaidleks. Ja ilu loovuses on nagu praktika teaduslikes teadmistes – tõe kriteerium. Aga kui teaduspraktika on objektiivne ja põhineb mõõtmistel, siis ilu on subjektiivne teema, olenevalt sellest, kes vaatab. Seega küsisin endalt, mis on minu jaoks isiklikult ilus veebirakendus?

(KDPV puhul ei ole silm minu, see on naise silm, kuid IMHO, naise silm KDPV suhtes on sobivam kui mehe oma, sest see on KDPV!)

Lõike all on minu enda kriteeriumid, millist veebirakendust võib praegu ilusaks pidada. Minu isikliku kogemuse põhjal väga subjektiivne väide. Võib-olla tunduvad minu ilu kriteeriumid mõnele inetuse kriteeriumina. Ärge üllatuge, teil on lihtsalt teistsugune kogemus.

Ja kuna olete juba lõikes osalenud, olge oma kommentaarides ettevaatlik. Lõppude lõpuks, kui saate artikli lugemise lõpetada kohe, kui selles väljaöeldu tundub teile inetu või isegi inetu, siis olen autorina sunnitud kõik kommentaarid läbi lugema.

Elupaik

Protokollid

Ma isegi ei tea, kas tasub seda kriteeriumi eraldi teha. Veebirakendused elavad veebis ja on sunnitud järgima veebiseadusi (protokolle). Peamised Interneti-protokollid on järgmised: TCP и IP. Nendel põhinevad paljud teised protokollid, kuid veebirakenduste puhul pean kõige olulisemaks HTTP (või õigemini selle laiendus HTTPS alusel TLS). See tähendab, et ilus veebirakendus on saadaval HTTPS/TLS-i kaudu (valikuliselt - HTTP kaudu) ja muud protokollid (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, ...) muudavad selle iga täiendavalt toetatavaga vähem ilusaks. protokolli. Rakendus ise saab neid lisaprotokolle kasutades kasutada väliseid ressursse.

suhtes WebSocket, siis pole mul selle protokolli veebirakendustega piisavalt kogemusi. See näeb ilus ja paljutõotav välja, kuid ma ei oska öelda, kui stabiilne ja praktiline see on.

Brauserid

Veebirakendusel on ainult üks jalg serveri poolel, teine ​​​​kliendi poolel. Kliendipool on brauser. Kaasaegne brauser pakub Palju asju, mida kaasaegne veebirakendus saab ja peaks enda huvides ära kasutama. Kaunis veebirakendus kasutab kaasaegseid brauseri võimalusi ja ei pea töötama brauserites, mis ei paku kaasaegseid võimalusi. Ma saan aru, et polütäidised - see on vajalik meede, kuid see on kole. Lõpuks ei pea moodsate tehnoloogiatega sammu pidama ainult arendajad, see kehtib ka kasutajate ja ettevõtete kohta.

JP

Programmeerimiskeeltega, mida veebirakenduste loomiseks kasutatakse, on kõik väga segane. Veebirakenduste kliendipoole jaoks on palju tehnoloogiaid, mis võimaldavad arendajal hõlbustada HTML/CSS/JS triaadi loomist (millest saavad aru kõik kaasaegsed brauserid). Kuid omal ajal puutusin tihedalt kokku G.W.T. ja minu arvates on ilus, kui arendaja näeb brauseris algset koodi, mitte kompileerimise või ülekandmise tulemust. Seetõttu kasutage veebipakk'ja sarnased tooted kliendikoodi IMHO genereerimiseks on inetud. Mida sarnasem on brauseris töötav kood arendaja loodud lähtekoodiga, seda parem. Ei usu mind? Proovige siluda GWT tootmisprotsessis loodud koodi.

Serveri poolel on rohkem vabadust (Java, PHP, perl, python, C#, Ruby, ...), kuid mulle tundub, et see on ilus, kui sama programmeerimiskeelt kasutatakse nii serveri poolel kui ka brauser – JavaScript. Ikkagi keel määrab mõtlemise, ja sarnaselt mõtlevate inimeste meeskonnad on produktiivsemad.

Inimlikkus

Ilus veebirakendus peaks kasuks tulema. Kasulik ennekõike inimestele kui lõpptarbijale. Seetõttu ei saa ma seda ilusaks veebirakenduseks nimetada veebiteenused. Tavainimesel (mitte veebiarendajal) on nendega raske töötada. Veebiteenused on omal moel ilusad,

Ilusal veebirakendusel peaks olema intuitiivne liides. Selle üle võib vaielda UISee on üsna subjektiivne asi. Nina UX kõik on palju lihtsam, kui kasutaja ei saa rakendust ilma väärtusliketa kasutada RTFM - halb UX, kole veebirakendus. Selle kriteeriumi kõige ilusamaid veebirakendusi saavad hõlpsasti kasutada lapsed, kes veel lugeda ei oska.

Pöördmastaapsus

Kunagi sai programme üle kanda diskettidele, nüüd - mälupulkadele või kohe Internetist alla laadida. Tavalise rakenduse kopeerimine ja selle teises masinas käivitamine on tühine ülesanne. Mõnevõrra eriline on olukord veebirakendustega. Võrk on globaalne keskkond, milles ei ole vaja sama veebirakenduse kloone. Internetis piisab ühest Facebookist, Twitterist, Instagramist, Mail.ru-st või Yandexist. Samas temaatilises nišis võivad olla erinevad veebirakendused, kuid erineva sihtrühmaga (nt Facebook ja Vkontakte, Mail.ru ja Gmail, Google Maps ja Azure Maps). Selliste veebirakenduste ülemaailmse kättesaadavuse tagamiseks on vaja riistvararessursse. mittetriviaalne.

Ma pole kunagi arendajana sellisel tasemel veebirakendustega töötanud ja mul pole õrna aimugi, kuidas need sees töötavad. Selliste veebirakenduste funktsionaalsuse tagamiseks on vaja vastavate spetsialistide meeskondi ja eraldi andmekeskusi. Imetlen inimeste võimet sellises mahus koostööd teha ja selliseid tooteid luua, kuid minu ilustandardiks on veebirakendus, mida saab käivitada eraldi sülearvutis.

Kaunis veebirakendus ei skaala mitte ainult üles ja väljapoole (kasutajate jaoks), vaid ka alla ja sissepoole (arendajate jaoks).

"amfiibsus"

Kaasaegsetele veebirakendustele juurdepääsuks kasutatakse kahte tüüpi seadmeid:

• arvutid (sülearvutid, lauaarvutid);
• mobiilseadmed (nutitelefonid ja tahvelarvutid);

Kusagil silmapiiril paistab rohkem "asjade internet"Aga see selleks korraks.

Arvutid erinevad mobiilseadmetest sama palju kui maismaaloomad veelindudest. Need on erinevad keskkonnad ja seavad neis elavatele olenditele (programmidele) erinevad nõudmised. Ilusad veebirakendused ei ole need, mis välja näevad kahepaiksedja need, kes on vees, on nagu kalad, maal nagu loomad ja õhus (SEO) – nagu linnud.

Ma arvan, et see on kole"amfiibsus“, see on nagu proovimine istuda kahel (SEO-ga – kolmel) toolil. Parem nagu Fiona Shrekist – üks päeval ja teine ​​öösel. Jah, kallim. Aga parem.

Ristjagamine

Märkasin juba lõigus “Reverse Scalability”, et võrgu globaalsus võimaldab ühe veebirakenduse olemasolu planeedi kohta. Seetõttu peab iga veebirakendus oma püsimajäämise tagamiseks teistest vähemalt mõnevõrra erinema. Küll aga minu aastatepikkune kogemus Magento (e-poe poodide ehitamise raamistik) ütleb, et üksikute veebirakenduste vahel võib olla rohkem sarnasusi kui erinevusi. Suurepärane veebirakendus ei peaks olema mitte ainult modulaarne, vaid ka jagama oma mooduleid teiste veebirakendustega. Mingil määral kajastub see idee spetsifikatsioonid JSR 168 ja JSR 286 ning raamistikud nagu WordPress, Django ja sama MagentoMinu arvates on veebirakenduse moodulite rohkus seda ilusam. Ristjagamine võimaldab luua kvaliteetsemaid mooduleid ja selle tulemusel stabiilsemaid veebirakendusi.

Mooduli all ei pea ma silmas selliseid teeke nagu jQuery või RequireJS – pigem suuremaid üksusi, näiteks pluginaid WordPress и Django. Kuid raamatukogude puhul kehtib ka väitekiri, et raamatukogu laialdane levik võimaldab seda paremaks ja jätkusuutlikumaks muuta.

Harvardi arhitektuur

Harvardi arhitektuur, erinevalt praegu valitsevast pallist Princeton, tähendab koodi ja andmete eraldamist. Arhitektuur ei tõusnud, aga idee ise tundub mulle isiklikult ilus. Eriti veebirakenduste jaoks. Igasugune staatiline (HTML/CSS/JS/Images/…) on kood. Seda saab ja tuleks vahemällu salvestada kas serveri või kliendi poolel. Ja andmed on REST/JSON (ilus) või SOAP/XML (veidi vähem ilus). Või WebSockets/JSON (võib olla parim valik, aga ma pole seda proovinud).

Lokaliseerimine

Veebirakenduste arendamisel puudutavad mind eriti kaks asja – mitmekeelne liides ja ajavööndid. Olen pärit Lätist, meil on kasutusel kolm keelt: LV, RU, EN. Ilus veebirakendus ei peaks mitte ainult võimaldama teil rakenduses endas kasutada mitut keelt, vaid võimaldama teil ka laiendada kasutatavate keelte arvu väliste ressursside, näiteks tunglemine. Sama kehtib ka moodulite kohta, millest veebirakendus kokku pannakse.

Ajavööndite puhul on kõik lihtne, kõigil juhtudel, kui pole selge, kuidas kuupäeva ja kellaaega töödelda, tehke nii: kõik, mis on serveris, läheb serverisse ja pärineb serverist - UTC, kõik, mida kliendil kuvatakse - vastavalt ajavööndile kasutajaprofiilist. See on ilus.

Surmatähtede asemel sepised

Ammu oli igal enam-vähem suurel linnal oma sepikoda. Võib-olla mitte üksi. Mõned on paremad, mõned on halvemad. Seppasid tunti üle maailma ja oli ka neid, kelle juurde nad tulid, sest alternatiivi polnud. Oli sõdu, epideemiaid ja looduskatastroofe. Mõned linnad kadusid koos elanikkonnaga. Kuid sepatöö jäi elama. Kadunud linnade asemele ehitati uued ja neisse tekkisid ka sepikojad.

Nüüd vaadake sellist teenust nagu DNS. Kui juurserverid kaovad, kogu maailm on palavikus.

Minu arvates ei saa ilus veebirakendus olla nii suur kui Facebook või Mail.ru. See on juba lähemal "Surmatäht"nii ehitamiseks vajalike ressursside kui ka töövõime säilitamiseks vajalike ressursside osas. Jah, kui Facebook hävitatakse, siis inimkond ei kao, selle funktsioonid võtavad kiiresti üle teised rakendused (sama VC Vene Föderatsiooni territooriumil ja seda ümbritsevatel aladel, Instagram, Twitter, ...). Märkimisväärse osa planeedi elanikkonnast ühe rakendusega lukustamine pole aga ilus. Lisaks, arvestades palju säästvamate alternatiivide (nt. torrentit).

Kokkuvõte

Kui olete lõpuni lugenud ja olete segaduses - "Mis see oli?"Seejärel avaldan teile siirast kaastunnet. Ma ei sundinud sind seda lugema. Üritasin lihtsalt oma mõtteid sõnadesse panna, et leida teisi, kes samamoodi mõtlevad. Võib-olla saan nendega arutada ilusate veebirakenduste loomise aspekte ja leida vastused oma küsimustele. Ja mul on neid palju.

Täname lugemast.

Allikas: www.habr.com