La krudeco de retaj teknologioj
Ni kreas aferojn por la reto ĉar la reto estas libera. Ni volas, ke niaj aferoj estu alireblaj al ĉiuj. Ni ne volas, ekzemple, ke la polico de Apple diktu ĉu ni povas ĝisdatigi nian aplikaĵon aŭ ne, aŭ kiam, aŭ kiel, aŭ preni grandegan parton de niaj enspezoj.
Sed la defaŭltaj retaj teknologioj ĉiam estis tre malbonaj por krei retajn aplikaĵojn. Ili estis origine inventitaj por hiperteksto, ne por aplikaĵoj. Ili longe "evoluis", sed ĝis hieraŭ, ĝi eĉ ne ofertis indiĝenajn popoverojn, do ĉiu devis krei siajn proprajn. Estas sekure diri, ke popover-komponento devus esti parto de ĉiu baza aplikaĵ-iloaro.
Jen kelkaj manieroj en kiuj retaj teknologioj estas malbonaj:
1. JavaScript
JavaScript estas lingvo kiu igas katidojn plori ĉiutage. Ĝi estis kreita en semajno kaj nun ni devas toleri ĝin eterne!? WAT. La plej bona libro pri ĝi estas titolita "JavaScript - la bonaj partoj"... Ĝi estas la sola lingvo kiun mi konas kun tiom multaj malbonaj partoj, krom INTERCAL.
2. Normoj ŝmnormoj
Retumiloj implementas normojn malsame, kaj programistoj suferas pro retumilsubteno. Ĉi tio neniam pliboniĝos: la nova Popover API, kiun ĉiuj volas uzi, jam estas malsame implementita en ĉiu retumilo. En 2024! Mia Dio, la historio neniam ŝanĝiĝas!!!
Tial via aranĝo rompiĝas sen via kulpo. Ĝi povas funkcii hodiaŭ kaj rompi morgaŭ – ne en teorio, sed en praktiko.
Plue, kiam via reta aplikaĵo funkcias en strangaj retumiloj en strangaj telefonoj, aŭ nur en Safari (kiu ĉiam malfruas kiel Internet Explorer en adopto de retaj normoj), vi daŭre vidas tre strangajn erarmesaĝojn en via Sentry. Malfacilas kredi ke ili estas realaj.
3. CSS
CSS ĉiam estas en fluo. Komence, oni devis lerni kiel skribi semantikan CSS. Poste CSS-kadroj aperis, solvante novajn problemojn kaj kreante novajn. Nun ĉiuj uzas Tailwind, kiu denove estas pli bona, sed denove prezentas la malnovan problemon de kiel bone uzi CSS. Fakte, Tailwind postulas la disvolvon de tre bona gusto pri "kie meti ĉi tiun kodon", ĉar ekzistas 4 malsamaj tavoloj de abstrakto, ĉiuj valoraj:
- tutmonda CSS (kiel temaj variabloj),
- komponentoj (kie Tailwind cedas al Bootstrap-stilo),
- uzo de realaj Tailwind-klasoj (kun la danĝero de troa ripetado), kaj
- enliniaj stiloj, kiuj devus esti tre raraj, sed tamen okazas.
4. Konstrua piplino infero
Typescript kaj Flow estas pli bonaj ol JS, sed ilia uzo postulas kompiladon. Tailwind ankaŭ. Konstruiloj kiel vite estas malfacilaj kompreni kaj agordi, sed foje tiu respondeco falas sur vin. En tiu momento, vi pensos ke vi devintus elekti rektan JS, sen konstrua piplino.
Ekzemple, ĉi tiu artikolo instruas vin kiel havi varman reŝargon se vi uzas Vite en la antaŭa finaĵo kaj Flask en la malantaŭa finaĵo. Ĝi ne mencias, ke vi povas fari la kontraŭon: Vite havas inversan prokurilon. Eble la artikolo estis skribita antaŭ ol Vite aldonis la inversan prokurilon. Tamen, la sekcio nomita "Vorto de atentigo" diras:
En miaj 7 jaroj de konstruado por la reto, mi uzis Grunt, Gulp, Webpack, esbuild, kaj Parcel. Snowpack kaj Rome venis kaj iris antaŭ ol mi iam havis ŝancon provi ilin. Bun konkuras por la loko de La Nova Varmaĵo en pakaĵo, Rome estis forkita en Biome, kaj Vercel konstruas Rust-bazitan Webpack-alternativon.
5. Troaktiva ekosistemo
La supra paragrafo estas nur unu ekzemplo de enorma problemo:
La JavaScript-ekosistemo estas troaktiva, orientita al ekscito, kun multaj pakaĵoj kreiĝantaj la tutan tempon, kaj poste mortantaj en malpli ol 5 jaroj. Fakte, vi havos bibliotekon morti antaŭ ol vi havos ŝancon uzi ĝin. Okazis al li, okazis al mi. Normala programisto bezonas ion daŭran, stabilan. Sed ni ne kapablas diri kiuj iloj estos respondecaj kaj resti prizorgataj. Kaj la konsiderinda forto de la FOMO igas nin provi multajn alternativojn.
6. Malordonaj npm-dependecoj
Kontroli la dependecojn de via projekto povas esti tre malebla. Ĉiu meza projekto dependas de neracia nombro da npm-pakaĵoj, kaj vi kiel aplikaĵprogramisto havas tre malfortan ideon pri kio plej multaj el ili faras. Ĉi tio estas danĝera. Sed ĝi ankaŭ estas sekvo de la troaktiva ekosistemo.
7. Heredata kodo
Ĉar bibliotekoj kaj kadroj estas tiel mallongdaŭraj, ili metas plafonon sur kiom multe programistoj povas atingi antaŭ ol ili devas reimplementi sian propran "heredatan kodon". Atestu Angular 2.0, kiu fifame ne donis ĝisdatigan vojon de AngularJS 1, lasante milojn da projektoj orfaj.
8. Boligitaj ranoj
Ĉar la reto estas necesa, programistoj lernas JavaScript unue kaj specialiĝas en ĝi tro frue. Tiuj nespertaj programistoj facile fariĝas la proverba boligita rano – ili ne havas ideon pri kiel sana medio fakte sentas, des malpli bona programlingvo. Ili pensas, ke tiu mondo estas normala.
Boligitaj ranoj malkonsentos kun tio, kion mi diras. Eble eĉ saltos al la malmultekosta akuzo de "kapabloproblemo".
Subgrupo de la boligitaj ranoj levas ŝultrojn kaj deklaras "Mi faris mian laboron". Ili ĝojas lerni ion novan, ŝanĝi ŝipon, kaj lasi la manon kiu nutris ilin kun heredita kodo kiu estas nur 4 jarojn aĝa. Tio estas ne respondeca kaj nemorala ago. Tiuj homoj ne rajtas plendi pri planita malnoviĝo, aŭ ili estus hipokritoj.
Aliflanke, programistoj kiuj havas ideon povas malesperi antaŭ malfacilaĵoj, foje optimumigante por facileco de efektivigo prefere ol boneco de UI-dezajno. Hodiaŭ multaj programistoj diras, ke ili preferas la malantaŭan finaĵon ol la antaŭan finaĵon.
Se HTML, CSS kaj JS ne estus tiel teruraj, tiam ni ne vidus ĉiun alian lingvon kompili al JS aŭ WebAssembly aŭ ambaŭ. La impeto de WebAssembly estas pruvo ke multaj, multaj homoj konsentas kun tio, kion mi diras ĉi tie.
9. Tro da lernado
Kaj nun la plej malbona parto: la kvanto de lernado kiun programisto devas konstante trapasi. Ĉi tio estas io, kion la boligitaj ranoj ne plu vidas, sed ili estis malŝparantaj siajn vivojn kaj cerbojn pri HTML, CSS kaj JS, por ne mencii JS-kadrojn ĝenerale, precipe React, Vue ktp. kiuj ĉiam trudas novajn konceptojn kaj novajn manierojn.
FOMO igas vin provi novajn kadrojn. Ekzemple, SolidJS subite ofertas multe pli altan rendimenton tra pli inteligenta observebla. Sed nur kiam vi uzas ĝin, vi rimarkas limigojn kiel... SolidJS nur ŝatas tabelojn, vi ne povas uzi Mapojn aŭ Arojn, kiuj cetere estas kolektoj en JS kiuj devus esti multe pli popularaj.
99% de JS-kadroj estas plenaj de truaj abstraktaĵoj kiel tio. Ili ŝajnas solvi problemon sed kreas multajn aliajn per damaĝo al ĉiuj aliaj revoj, kiujn vi havis por via kodo.
Eta historio de la krudeco
En 1995, Netscape mendis al Brendan Eich rapide krei etan lingvon, kiun ili volis aldoni al sia retumilo. Do JavaScript estis kreita en 10 tagoj. Neniu atendis, ke ĝi fariĝos la plej uzata lingvo...
Tra la jardekoj, multaj, multaj alternativoj estis kreitaj, por ke programistoj ne devu suferi la krudan JavaScript. Unu el la plej gravaj estis CoffeeScript (2009). Microsoft dungis la projektiston de Delphi por krei sian propran en 2012: TypeScript, aŭ "C# en la retumilo". TypeScript baze venkis. Tamen, ĉiuj ĉi tiuj lingvoj enkondukas kompiladon, ĉar nur JavaScript ruliĝis en la retumilo. Nun programistoj devas atendi antaŭ ol vidi ŝanĝojn sur la paĝo, kio estas kruda.
La formatiga lingvo, CSS, estis konsiderata kruda, do ili faris la saman aferon: ili inventis CSS-plibonigojn, kiuj bezonis kompiladon al CSS, igante la tutan kompiladon eĉ pli longa kaj pli kruda.
Kun kompilado, sencimigo (senararigado) subite fariĝis kruda, ĉar kiam eraro okazis, la retumilo raportis ke la eraro estis en linio 934 de JavaScript-programo, kiun vi ne skribis kaj aspektis terure. Do Chrome inventis fontmapojn, solvante tiun problemon: Nun la retumilo mapus liniojn de kodo kaj raportus la eraron sur via CoffeeScript-fonto, ne la tradukita JavaScript-fonto. Sed fontmapoj estas peza elŝuto kaj ili prenas eĉ pli da tempo por kompili, igante ilin krudaj. Pro ilia pezo, ili neniam estas uzataj en produktado.
Provante kontroli la problemon de retaj aplikaĵoj esti pli kaj pli pezaj elŝutoj en produktado, ili aldonis "arboŝanĝadon", kio signifas, ke la kompililo estas sufiĉe inteligenta por preterlasi funkciojn, kiuj estis skribitaj, sed ne estas fakte nuntempe uzataj en la aplikaĵo. Sentante sin inteligentaj, ili forgesas, ke ĉi tio estas unu pli komplika afero, kiun ĉiu retprogramisto devas scii ekzistas, kaj prenas pli da kompilado, do kruda.
Por redoni al programistoj la senprokrastecon de ŝparado de kodo kaj vidado de la ŝanĝoj en la retumilo sen devi atendi, sofistikaj konstruiloj kiel gulp, webpack, vite ktp. faras kompleksajn decidojn pri kiuj el tiuj aferoj fari dum evoluo kaj kiuj fari en produktada konstruaĵo. Tio ne estas ĉio, kion ili faras, estas pli komplekse. Tamen, ili fariĝis alia esenca ilo en la iloaro, ili daŭras eĉ pli mallonge ol retaj kadroj, ili estas malfacilaj kompreni, ili havas centojn da agordeblaj opcioj... sed ili solvas la senprokrastecan problemon – denove, en kruda maniero.
Kaj tiel, retprogramado fariĝas ĉiam pli kompleksa, kaj la freneza homamaso daŭre pensas sin inteligentaj post plendo de fundamentaj vundoj kun pli kaj pli da iloj.
La vera solvo ĉiam estis io kiel Dart (2011) aŭ WebAssembly (2017): malmola rompo kun krudaj retaj teknologioj, kondiĉe ke la anstataŭa teknologio estu same malferma kiel la reto, kaj desegnita por aplikaĵoj dekomence. Do kion faris la boligitaj ranoj? Ili baze ignoris ĉi tiujn. La komenca plano por Dart estis inkluzivi ĝin en Chrome kiel la bona frato de JavaScript. Ĉi tio estis kritikata pro fragmentado de la reto, do ili rezignis pri ĉi tiu ideo en 2015.
Anstataŭe, Node.js (2009) alportis JavaScript al la servilo, kaj nun boligitaj ranoj skribas sian malantaŭan kaj antaŭan finaĵon en la sama lingvo: la plej malbona. Iu helpu ilin!
Serĉante solvon
Vi pensis, ke vi disvolvos vian produkton, finos, sidiĝos, lasos la profitojn veni kaj neniam plu laboros. Poste vi lernis la lecionon de Chacon: programo estas tamagotchi. Kiel virtuala dorlotbesto, programo havas siajn proprajn bezonojn, kiuj devas esti prizorgataj, laŭ la tempo, konstante. Tio estas normala en programado. Kio estas nenormala estas la furioza intenseco de la tamagoŝieco se vi uzas retajn teknologiojn: se vi ne ĝisdatigas ĝin, en nur 4 jaroj ĝi estas heredata kodo, kiun neniu volas prizorgi.
Mallonge, vi havis problemon, do vi decidis skribi retan aplikaĵon. Nun vi havas 9 problemojn, kun pli atendi en la estonteco.
Ni volas fari retajn aplikaĵojn, jes. Sed kun decaj iloj!
Tra la jaroj mi provis multajn alternativojn al JS, precipe tiujn kiuj promesis, ke mi povus skribi miajn retajn aplikaĵojn en Python, la plej legebla lingvo. Sed mi neniam sentis, ke ili estis sufiĉe maturaj por fakte uzi. Ili ĉiam venis kun seriozaj malavantaĝoj, kiel pli da malfacileco senararigi, pro traduko al JS.
Ankoraŭ ene de retaj teknologioj: Mithril
La plej bona afero, kion mi povis fari, estis uzi bazan JavaScript kiom eble, evitante kadrojn, kiuj enmiksiĝas en miaj datumoj. Io kiel Mithril.js, reaktiva biblioteko kun limigita amplekso, estas la plej bona, kiun vi povas elekti. Kiam mi uzas Mithril, mia stat-administrada biblioteko estas {}. Ne lasu kadron dikti kiel viaj datumoj devus esti organizitaj!
Vi devas izoli vian komercan logikon de JS-kadroj. Skribu la kernon de via sistemo kun unu principo: importi la JS-kadron ne estas permesata! Konservu la kodon, kiu uzas la kadron, tre maldika. Ĉi tio estas la sola maniero, ke iom de via kodo povas travivi ĉi tiujn kadrojn, kiuj kutime daŭras nur 4 jarojn.
Eviti la situacion en kiu via tuta antaŭa finaĵo subite fariĝas aro de heredata kodo estas tiel grava, ke ĝi superas aliajn konsiderojn, kiel la haveblecon de pretaj "widgets" por via kadro. Estas nur unu aŭ du wiĝetaj bibliotekoj por Mithril tie ekstere. Por eviti reinventi la radon, ni ŝanĝas al retaj komponentoj (tajloritaj elementoj) por tre kompleksaj aferoj kiel redakteblaj sortigeblaj filtreblaj datumaroj.
Preter retaj teknologioj: Flutter
La krudeco de retaj teknologioj estas bona kialo adopti ion kiel Flutter. Ekde 2021, ĝi povas renderi en la reto uzante Kanvason. Kiel ludmotoro, ĝi pentras la ekranon antaŭ ol transdoni la pikselojn al iu stulta surfaco aŭ kanvaso de la platformo sur kiu ĝi nuntempe sidas. Tial, mia aranĝo neniam rompiĝos. Mi ne plu zorgos ĉu retumiloj konsentas pri plej multaj aferoj. Mi ne devos uzi HTML aŭ CSS aŭ retajn kadrojn. La Dart-lingvo ricevis bonegajn trajtojn, kiel nulsekureco (2021). Multaj pli bonaj ol JS kaj tre similaj al TypeScript, do lerni Dart estas facila por plej multaj. Mia Sentry certe enhavos malpli strangajn erarojn de strangaj retumiloj. Kaj neniu bezono iam agordi bundilon.
CSS? Hahahahahaah... CSS... Bona ŝerco!
Flutter estas malfermfonta trans-platforma aplikaĵa evoluiga ilaro kreita de Google. El unu kodbazo ĝi generas la saman aplikaĵon por Android, iOS, reto, Vindozo, OS X kaj Linukso. Unu miliono da aplikaĵoj estis kreitaj kun ĝi.
Flutter havas komencan lernokurbon, certe. Sed longtempe, tio estas multe malpli da peno ol teni sin ĝisdatigita kun krudaj retaj teknologioj!
Kio pri komencaj programistoj? Kion vi pensas estas pli facila, lerni HTML, poste CSS, poste Javascript, poste Typescript, poste Vue, poste vite (kaj alternativoj)... aŭ lerni Dart kaj poste Flutter?
Sed oni devas scii kiam uzi ĉi tiun specon de afero en la reto. Flutter estas por aplikaĵoj, ne por enhavaj retejoj. Aplikaĵo Flutter funkcianta en la reto estas pli peza kaj pli malrapida elŝuto, ne eksponas sian enhavon al serĉiloj, kaj ne facile integriĝas kun la alireblecoj de la retplatformo. Konservu vian blogon en HTML, ĉar HTML estis kreita por hiperteksto. Sed ĝi ne estis kreita por retaj aplikaĵoj! Ni devigis retajn aplikaĵojn sur ĝi dum jaroj, misformante ĝin, transformante ĝin en monstron.
La sola problema estas, ke la rapideco de Flutter estas bona en ĉiu platformo, krome la web, kaj Googlo faras nenion pri tio – ne en 2024, almenaŭ. Aspektas ke la web estas duaklasa platformo por ili.
Konkludo
Kvankam mi nur komencas kun Flutter, estas jam facile vidi kiel programista produktiveco devus esti pli alta uzante ĝin anstataŭ HTML, CSS kaj TypeScript.
Mia intereso ne nepre estas fari iOS aŭ Android-aplikaĵojn, ne. Nur faciligu mian vivon. Faru sangantan aplikaĵon, kiu eĉ funkcios sur la sanganta reto, sen postuli, ke mi uzu krudajn retajn teknologiojn.