I mine collegeår, som softwareteknikstuderende, var Java det nye barn på blokken. Heldigvis havde jeg et par visionære professorer, der var ivrige efter at tagge C ++ som noget fra fortiden og gå videre til den vidunderlige verden af „kode en gang, anvend hvor som helst“. De fleste opgaver var i Java, men vi prøvede også andre teknologier som C, C++, Cobol, OCAML... og JavaScript.
Så snart jeg begyndte at arbejde med JavaScript, fik jeg den øjeblikkelige fornemmelse af, at det var designet med en hack & slash-tilgang for at få noget gjort og ikke skulle overleve mere end et par prototyper. Ingen dengang var villige til at satse gården på JavaScript, men vi kunne ikke tage mere fejl. Tyve år senere tillod vores branche JavaScript at flytte til back-end, og nu er det overalt.
Årene efter min eksamen blev, som forudset af universitetsprofessorerne, brugt på kodning i Java. Jeg elskede, hvordan Sun designede sproget og Java VM, men jeg satte altid spørgsmålstegn ved deres overkomplicerede måde at designe Standard Development Kit (SDK) på. Det virkede som om de var ivrige efter at bruge hvert mønster i den berømte bog skrevet af Bande af fire, og den første kontakt med J2EE gav mig det indtryk, at Martin Fowler tilbød Sun udkastet til sin endnu ikke udgivne bog Virksomhedsdesignmønstre, og de lavede en TODO-liste ud af det.
Java-økosystemet var så overkonstrueret, at det blev en almindelig praksis at medregne to uger i en projektplan bare for at bootstrap et lidt komplekst produkt. For at gøre tingene værre begyndte hele Java-samfundet at frigive over konstruerede rammer, og verden fødte fantastiske ting som Stivere og Eclipse RCP.
Du kan ikke forestille dig, hvor glad jeg var, da jeg først stødte på Ruby on RailsEt eller andet sted på version 1.x. Det var let at forudse, at dette ville blive stort, og dermed grunden til, at vi gik fuld gas på Rails, når vi startede Imaginær sky.
Jeg kunne aldrig lide scriptede sprog, da jeg sætter stor pris på det arbejde, en kompilator har udført for at opdage skrivefejl og datatypefejl, men jeg har ledt så længe efter en god webramme, at jeg fuldt ud omfavnede Ruby on Rails-løftet. Der var endelig noget, der kunne give et godt udviklerteam mulighed for hurtigt at levere noget mere komplekst end et sæt statiske websider bygget i Dreamweaver.
Ruby on Rails tog en så forstyrrende tilgang, at samfundet eksploderede, og næsten hvert nyt projekt i opstartsverdenen brugte det. Nogle af disse startups voksede ret hurtigt og validerede, at Rails var klar til skalering. Du kan altid finde folk, der siger, at Ruby er langsom, og Rails kræver en masse beregningsressourcer, men på det tidspunkt, hvis du ville komme hurtigt på markedet og stadig bruge den samme kodebase, mens du gennemsøger en hockey-stick-formet vækst, var flere servere altid et godt svar. Ja, de var dyre, men denne mulighed var stadig billigere end at omskrive hele kodebasen. Og man kunne altid omkonstruere de træge komponenter i et system på et mere ydende sprog. Ruby integrerede altid ret godt enten via web API eller delt bibliotek.
På trods af de store fordele ved at bruge Rails i et nyt projekt var der et område, hvor Ruby ikke var i stand til at trænge ind, og ikke engang Rails var en god ambassadør. Jeg taler om erhvervslivet. Der er selvfølgelig nogle undtagelser, og man kan altid pege på nogle vellykkede virksomhedsbrugssager, hvor Ruby blev vedtaget enten til nye projekter eller som en omskrivning af eksisterende i. Men vi ser stadig en masseindførelse af teknologien af veletablerede virksomheder. Der er flere grunde til dette, men denne udtalelse blev udviklet kun baseret på mavefornemmelse, og jeg har ingen klare data til at validere den. Således vil jeg ikke uddybe grundene til, at Ruby ikke bruges massivt på virksomhedsmarkedet.
Alt i alt tror jeg, at dette var en forpasset mulighed, og softwareindustrien tilbyder nu mange levedygtige muligheder for Ruby on Rails. Nogle bruges i vid udstrækning af startups (dvs. Phoenix), mens andre har en vis penetration på virksomheder, fordi de er bygget oven på teknologier, som korpset allerede bruger (ja Django, Jeg taler om dig). Men hvis du vil være i stand til at hjælpe både virksomheder og startups, kan du ikke gå galt med JavaScript & Node.js. Jeg siger ikke, at Rails ikke er egnet til formålet.
De fleste gange er det faktisk egnet til formålet, men ikke egnet til kontekst. Og med kontekst mener jeg vores kontekst - dvs. at kunne arbejde i et miljø, hvor både startups og virksomheder er villige til at satse deres fremtidige stack på. Selvom dette er sandt for førstnævnte, er det ikke sandt for det seneste. Startups og virksomheder elsker JavaScript. Og efter min mening, JavaScript-økosystemet er moden nok til at levere alle de gode ting, som Ruby og Rails har bragt os, og meget mere i områder, hvor Ruby og Rails aldrig var i stand til at skinne. Lad os se på resultaterne.
Vi foretog en grundig undersøgelse af Node.js -økosystemet (gennem undersøgelse og feltarbejde på et stort antal projekter) for at identificere komponenterne i vores referencestak. Du kan overveje, at nogle af disse fund fungerer til fordel eller imod Node.js, afhængigt af dine mål. Din kilometertal kan variere, men vi har været i stand til at finde gode løsninger til ting som databasemigreringer, godkendelsesbiblioteker, admin/back-office-udvidelser, automatiseret test, objektspotning osv. Indtil videre var der intet, vi var i stand til at gøre i Rails, som var svært at opnå i Node.js. Vores resultater går i den retning, at der er en erstatning for næsten alle Rails-funktioner eller Ruby-perle.
I modsætning til Ruby dominerer JavaScript webfrontenden, og med Node.js blev det berømt på back-end. Det er let at forstå, hvorfor JavaScript er mere populært, men jeg tror også, at samfundet gennemgår en „cool“ fase, svarende til hvad der skete med Rails i de tidlige dage. Der foregår en masse jordbeslaglæggelse i samfundet, og dette driver en masse innovation. Men jeg formoder også, at vi vil se en vis konsolidering i de kommende år med biblioteker og rammer, der efterlades til at dø. Ruby on Rails-samfundet er også stort og temmelig aktivt. Men efterhånden som Rails modnede, mistede den sin seje faktor, og samfundet stabiliserede sig. Det betyder også, at vi skal forvente mindre innovation.
Vi har brugt Ruby Motion siden de tidlige dage og offentliggjorde flere apps i App Store. Jeg må sige, at dette var en fantastisk ramme, udviklet af meget lyse mennesker. Støtten til automatiseret test var bemærkelsesværdig. Dette var før-hurtigt, og levering til iOS i Ruby var meget pænere end at bruge Objective-C. Men RubyMotion tog en forfærdelig mængde tid at understøtte Android, og løftet „byg en gang, rul overalt“ var ikke muligt, da Swift kom ud. Swifts syntaks er meget pænere end Objective-C, og det var en stærk nok grund til at stoppe med at bruge RubyMotion på nye projekter. Du kan stadig bruge det i dag, selvom grundlæggerne solgte deres forretning, og det stoppede lidt i tide. Jeg formoder, at rammen ikke var i stand til at få nok trækkraft til at gøre det muligt for den at holde styr på den innovation, der blev skubbet af Apple og Google på henholdsvis iOS- og Android-platformene.
Og på JavaScript-hjørnet har du React Native. Det giver dig mulighed for at levere native apps til iOS og Android. Det er udviklet af Facebook og stærkt understøttet af et stort samfund. Det er også gratis at bruge (RubyMotion er det ikke).
Når jeg går tilbage til det, jeg sagde i begyndelsen af denne artikel, var mit væddemål, at JavaScript ville have en smertefuld død. Jeg kunne ikke tage mere fejl. Det er bemærkelsesværdigt, hvordan det formåede at forblive relevant i alle disse år, op til det punkt, hvor nogen var i stand til at udføre deres masterplan og skubbe den til bagsiden. Jeg synes stadig, at der er store problemer med sproget, men så blev Rails berømt, og Ruby lider også af nogle designfejl.
Der gøres en betydelig indsats for at forbedre sprogdesignet med de nyeste udgivelser til ECMA Script. Men vi er stadig nødt til at vente på en stor vedtagelse af de nye udgivelser for at drage fordel af det. Der er også mulighed for at bruge en transpiler som Babel, til at bruge de nye funktioner, der er tilgængelige i de nye ECMA Script Standards uden at ofre bagudkompatibilitet for ældre browsere.
Faktum er, at du nu kan frigive et komplekst web- og mobilprojekt uden at skulle bruge flere sprog, og det hjælper med at reducere udviklingsomkostningerne, og hvis du har været i branchen længe, skal du indrømme det. Dette er en ret cool præstation.
Alt taget i betragtning, for os er JavaScript egnet til formål og kontekst. Vi er officielt stoppet med at anbefale Ruby on Rails til nye projekter og vælger som standard en JavaScript-baseret arkitektur. Ikke desto mindre vil vi støtte eksisterende Rails-projekter, da jeg tror, at teknologien er moden, klar til produktion, og den vil ikke dø snart på grund af dets modne og stabile samfund.
CEO @ Imaginary Cloud og medforfatter af bogen Product Design Process. Jeg nyder mad, vin og Krav Maga (ikke nødvendigvis i denne rækkefølge).
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
