Ik ben al geruime tijd bezig met de ontwikkeling van webapplicaties. Heel lang. Mijn eerste webapplicaties heb ik gemaakt in de omgeving van toen het woord Ā«googleĀ» nog geen werkwoord was, en mensen voor het zoeken van informatie op het internet Yahoo! en Rambler gebruikten. Ik zelf gebruikte ā zij hadden een verfijnde zoekfunctie en niet zo'n rommelige, overbeladen interface als Yahoo!
De ontwikkeling van applicaties, ongeacht welke, niet alleen voor het web ā is een creatieve taak. Weinig mensen zullen het hier oneens mee zijn. En schoonheid in creativiteit is net als praktijk in wetenschappelijk onderzoek ā de maatstaf voor waarheid. Maar terwijl wetenschappelijke praktijk objectief is en gebaseerd op metingen, is schoonheid een subjectief onderwerp, afhankelijk van wie kijkt. Dus vroeg ik mezelf af, wat voor mij persoonlijk een mooi webapplicatie maakt?
(met de KDPV, mijn oog is een vrouwelijk oog, maar IMHO is een vrouwelijk oog op de KDPV veel passender dan een mannelijk, want dit is ā !)
Onder de kat mijn eigen criteria voor wat momenteel als een mooi webapplicatie kan worden beschouwd. Een zeer subjectieve uiteenzetting, bepaald door mijn persoonlijke ervaring. Misschien zullen mijn criteria voor schoonheid voor iemand anders als criteria voor lelijkheid worden beschouwd. Verwacht niets minder, je hebt gewoon een andere ervaring.
En aangezien je onder de kat bent gekomen, wees voorzichtig in de reacties, alsjeblieft. Want als je kunt stoppen met het lezen van het artikel zodra het je onesthetisch of zelfs lelijk lijkt, dan ben ik als auteur verplicht om alle reacties te lezen.
Leefomgeving
Protocollen
Ik weet eigenlijk niet of ik dit criterium apart moet vermelden. Webapplicaties leven in het Net en moeten voldoen aan de wetten van het Net (protocollen). De belangrijkste protocollen op het Net zijn en . Vele andere protocollen zijn daarop gebaseerd, maar voor webapplicaties beschouw ik het belangrijkste (eerder, zijn uitbreiding gebaseerd op ). Dat wil zeggen, een mooi webapplicatie is toegankelijk via HTTPS/TLS (als alternatief ā via HTTP), en andere protocollen (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, ā¦) maken het minder mooi met elk extra ondersteund protocol. De applicatie zelf kan met behulp van deze extra protocollen externe bronnen gebruiken.
Wat betreft , heb ik onvoldoende ervaring met het gebruik van dit protocol in webapplicaties. Het ziet er mooi en veelbelovend uit, maar hoe stabiel en praktisch het is ā daar kan ik niets over zeggen.
Browsers
Een webapplicatie staat met ƩƩn voet aan de serverzijde en met de andere voet aan de clientzijde. De clientzijde is de browser. Moderne browsers bieden , die een moderne webapplicatie kan en moet benutten. Een mooi webapplicatie gebruikt de moderne mogelijkheden van browsers en hoeft niet te functioneren in browsers die deze moderne mogelijkheden niet bieden. Ik begrijp dat een noodzakelijke maatregel zijn, maar het is niet fraai. Uiteindelijk moeten niet alleen ontwikkelaars gelijke tred houden met moderne technologieƫn; dit geldt ook voor gebruikers en bedrijven.
programmeertalen
Het is een complexe situatie met de programmeertalen die worden gebruikt voor het creƫren van webapplicaties. Voor de clientzijde van webapplicaties zijn er veel technologieƫn die het voor ontwikkelaars gemakkelijker maken om de triade HTML/CSS/JS te maken (wat alle moderne browsers begrijpen). Maar ik heb in mijn tijd nauw samengewerkt met en ik vind het mooi wanneer een ontwikkelaar de originele code in de browser ziet en niet het resultaat van compilatie of transpilatie. Daarom vind ik het gebruik van en soortgelijke producten voor het genereren van clientcode, IMHO, niet mooi. Hoe meer de code die in de browser wordt uitgevoerd lijkt op de originele code die door de ontwikkelaar is geschreven, hoe beter. Geloof je het niet? Probeer de in productie gemaakte code, vervaardigd met GWT, te debuggen.
Aan de serverzijde is er meer vrijheid (Java, PHP, Perl, Python, C#, Ruby, ā¦), maar ik vind het mooi wanneer aan zowel de serverzijde als in de browser dezelfde programmeertaal wordt gebruikt ā JavaScript. Uiteindelijk , en teams van gelijkgestemden zijn productiever.
Menselijkheid
Een mooi webapplicatie moet nuttig zijn. Nuttig, in de eerste plaats, voor de mens, als eindgebruiker. Daarom kan ik een mooi webapplicatie niet noemen. Voor een gewone persoon (geen webontwikkelaar) zijn ze lastig. Webdiensten zijn op hun eigen manier mooi,
Een mooi webapplicatie moet een intuĆÆtieve interface hebben. Er kan over worden gediscussieerd of dit onderwerp redelijk subjectief is. Maar met is het veel eenvoudiger; als een gebruiker de applicatie niet kan gebruiken zonder de vereiste dingen, is dat slecht UX, een lelijk webapplicatie. De mooiste webapplicaties volgens dit criterium kunnen gemakkelijk door kinderen worden gebruikt die nog niet leren lezen.
Terugschaling
Lang geleden konden programma's worden overgebracht op diskettes, nu - op flash drives of direct gedownload uit het netwerk. Het kopiƫren van een gewone applicatie en deze op een andere machine uitvoeren is een triviale taak. De situatie met webapplicaties is echter iets anders. Het netwerk is een globale omgeving waarin het niet nodig is om klonen van dezelfde webapplicatie te hebben. EƩn Facebook, Twitter, Instagram, Mail.ru of Yandex is voldoende. Er kunnen verschillende webapplicaties in dezelfde thematische niche bestaan, maar met verschillende doelgroepen (zoals Facebook en Vkontakte, Mail.ru en Gmail, Google Maps en Azure Maps). De hardwarebronnen om de wereldwijde beschikbaarheid van zulke webapplicaties te waarborgen zijn, laten we zeggen, .
Ik heb nooit met webapplicaties van dat niveau gewerkt als ontwikkelaar en weet niet hoe ze van binnen zijn opgebouwd. Om de werking van zulke webapplicaties te waarborgen, zijn teams van gespecialiseerde professionals en aparte datacenters nodig. Ik ben onder de indruk van het vermogen van mensen om samen te werken op zulke schaal en om dergelijke producten te creƫren, maar mijn maatstaf voor schoonheid is een webapplicatie die op een aparte laptop kan draaien.
Een mooie webapplicatie schaalt niet alleen omhoog en breed (voor gebruikers), maar ook omlaag en naar binnen (voor ontwikkelaars).
Amfibieƫ
Voor toegang tot moderne webapplicaties worden apparaten van twee types gebruikt:
- computers (laptops, desktops);
- mobiele apparaten (smartphones en tablets);
Iets in de verte flikkert nog de "", maar voorlopig zo.
Computers verschillen van mobiele apparaten zo sterk als landdieren verschillen van watervogels. Dit zijn verschillende omgevingen en ze stellen verschillende eisen aan de wezens (programma's) die daarin leven. Mooie webapplicaties zijn niet diegene die op , maar diegene die in het water lijken - als vissen, op het land - als zoogdieren, en in de lucht () - als vogels.
Ik beschouw "" als lelijk, dat is als proberen om op twee (met SEO - drie) stoelen te zitten. Liever zoals Fiona uit Shrek - overdag Ć©Ć©n, 's nachts een andere. Ja, duurder. Maar beter.
Cross-sharing
Ik heb al opgemerkt in het punt 'Terugwaartse Schaalbaarheid' dat de globaliteit van het netwerk de mogelijkheid biedt om ƩƩn webapplicatie voor de hele planeet te hebben. Daarom moet elke webapplicatie op de een of andere manier verschillen van andere, om zichzelf te kunnen behouden. Niettemin zegt mijn jarenlange ervaring met (een kader voor het bouwen van e-commerce winkels) dat er meer overeenkomsten dan verschillen kunnen zijn tussen afzonderlijke webapplicaties. Een mooie webapplicatie moet niet alleen modulair zijn, maar ook haar modules delen met andere webapplicaties. In zekere zin is dit idee weerspiegeld in JSR 168 en JSR 286 en frameworks zoals , en hetzelfde Magento. Hoe groter het aantal modules van een webapplicatie dat door andere webapplicaties wordt gebruikt, hoe mooier het volgens mij is. Cross-sharing stelt ons in staat om hoogwaardige modules te creƫren en daarmee meer stabiele webapplicaties.
Met een module bedoel ik geen bibliotheken zoals jQuery of RequireJS ā eerder grotere entiteiten, zoals plugins in en . Maar hetzelfde geldt voor bibliotheken: hoe breder de verspreiding van een bibliotheek, hoe kwalitatief beter en robuuster deze wordt.
De Harvard-architectuur
, in tegenstelling tot de momenteel heersende , impliceert de scheiding van code en gegevens. De architectuur heeft geen succesvolle vlucht genomen, maar de idee zelf lijkt me mooi. Bijzonder voor webapplicaties. Elke statische inhoud (HTML/CSS/JS/Afbeeldingen/ā¦) is code. Deze kan en moet zowel aan de serverzijde als aan de klantzijde worden gecached. En gegevens zijn / (mooi) of / (iets minder mooi). Of WebSockets/JSON (misschien de beste keuze, maar ik heb het niet geprobeerd).
Lokalisatie
Er zijn twee dingen die me vooral bezighouden bij de ontwikkeling van webapplicaties: een meertalige interface en tijdzones. Ik kom zelf uit Letland, waar drie talen in gebruik zijn: LV, RU, EN. Een mooie webapplicatie moet niet alleen meerdere talen binnen de applicatie ondersteunen, maar ook de mogelijkheid bieden om het aantal te gebruiken talen uit te breiden via externe bronnen, zoals . Dit geldt ook voor de modules waaruit de webapplicatie is opgebouwd.
Met tijdzones is het eenvoudig: in alle gevallen waarin onduidelijk is hoe met datum en tijd om te gaan, doe je dit: alles wat op de server ligt, naar de server gaat en van de server komt, is UTC, alles wat op de cliƫnt wordt weergegeven, is volgens de tijdzone in het gebruikersprofiel. Dat is mooi.
Smeden in plaats van 'Doodssterren'
Lang geleden had elke meer of minder grote stad zijn eigen smederij. Misschien zelfs meer dan ƩƩn. Sommige beter, sommige slechter. Er waren smidmeesters die wereldwijd bekend waren, en er waren er ook die men uit gebrek aan alternatieven bezocht. Oorlogen, epidemieƫn en natuurrampen trokken voorbij. Sommige stadjes verdwenen samen met de bevolking. Maar het smidsambacht bleef leven. In plaats van verdwenen steden werden nieuwe gebouwd, en ook daar ontstonden smederijen.
En kijk nu eens naar een dienst zoals . Wanneer de rootservers uitvallen, .
Naar mijn mening kan een mooi webapplicatie niet zo groot zijn als Facebook of Mail.ru. Dat is al meer in de richting van '' zowel qua middelen die nodig zijn voor de bouw als voor het onderhouden van de functionaliteit. Ja, als Facebook zou worden vernietigd, zou de mensheid niet verdwijnen, zijn functies zouden snel door andere applicaties worden overgenomen (dezelfde op het grondgebied van Rusland en omliggende gebieden, Instagram, Twitter, ...). Toch is het het afsluiten van een aanzienlijk deel van de bevolking van de Planeet op Ć©Ć©n applicatie lelijk. Zeker met veel stabielere alternatieven beschikbaar (bijvoorbeeld, ).
Samenvatting
Als je dit tot het einde hebt gelezen en je bent in de war - 'wat was dat?', dan bied ik je mijn oprechte medeleven aan. Ik heb je niet gedwongen dit te lezen. Ik heb gewoon geprobeerd mijn gedachten in woorden te gieten, om degenen te vinden die hetzelfde denken. Misschien kan ik met hen enkele aspecten van het maken van mooie webapplicaties bespreken en antwoorden vinden op mijn vragen. En die heb ik veel.
Dank voor het lezen.
Bron: habr.com
