Under mina collegeår, som programvaruteknikstudent, var Java det nya barnet på blocket. Lyckligtvis hade jag några visionära professorer som var ivriga att tagga C++ som något från det förflutna och gå vidare till den underbara världen av ”kod en gång, distribuera var som helst”. De flesta av uppdragen var i Java, men vi provade även andra tekniker som C, C++, Cobol, OCAML... och JavaScript.
Så fort jag började arbeta med JavaScript fick jag en omedelbar känsla av att det var designat med ett hack & slash-tillvägagångssätt för att få något gjort och inte borde överleva mer än ett par prototyper. Ingen då var villig att satsa gården på JavaScript, men vi kunde inte ha mer fel. Tjugo år senare tillät vår bransch JavaScript att flytta till back-end och nu finns det överallt.
Åren efter min examen spenderades, enligt universitetsprofessorerna, kodning i Java. Jag älskade hur Sun designade språket och Java VM, men jag ifrågasatte alltid deras alltför komplicerade sätt att designa Standard Development Kit (SDK). Det verkade som om de var angelägna om att använda varje mönster i den berömda bok skriven av Gänget av fyra, och den första kontakten med J2EE gav mig intrycket att Martin Fowler erbjöd Sun utkastet till sin ännu inte publicerade bok Företagsdesignmönster, och de gjorde en TODO-lista av det.
Java-ekosystemet var så överkonstruerat att det blev en vanlig praxis att räkna in två veckor i en projektplan bara för att starta en något komplex produkt. För att göra saker värre började hela Java-communityn släppa över konstruerade ramverk, och världen födde fantastiska saker som fjäderben och Eclipse RCP.
Du kan inte föreställa dig hur glad jag var när jag först stötte på Ruby on RailsNågonstans i version 1.x. Det var lätt att förutse att detta skulle bli stort, och därmed anledningen till att vi gick full gas på Rails när vi startade Imaginärt moln.
Jag gillade aldrig skriptspråk eftersom jag uppskattar det arbete som gjorts av en kompilator för att upptäcka skrivfel och datatypsfel, men jag har letat så länge efter ett bra webbramverk att jag helt anammade Ruby on Rails-löftet. Det fanns äntligen något som kunde tillåta ett bra utvecklingsteam att snabbt leverera något mer komplext än en uppsättning statiska webbsidor inbyggda i Dreamweaver.
Ruby on Rails tog ett så störande tillvägagångssätt att samhället exploderade och nästan varje nytt projekt i startvärlden använde det. Några av dessa startups växte ganska snabbt och validerade att Rails var redo för skala. Du kan alltid hitta människor som säger att Ruby är långsam och Rails kräver mycket beräkningsresurser, men då, om du ville komma ut på marknaden snabbt och fortfarande använda samma kodbas medan du genomsöker en hockey-stickformad tillväxt, fler servrar var alltid ett bra svar. Ja, de var dyra, men det här alternativet var fortfarande billigare än att skriva om hela kodbasen. Och man kan alltid omkonstruera de tröga komponenterna i ett system på ett mer presterande språk. Ruby integrerades alltid ganska bra antingen via webb-API eller delat bibliotek.
Trots de stora fördelarna med att använda Rails i ett nytt projekt fanns det ett område där Ruby inte kunde tränga in, och inte ens Rails var en bra ambassadör. Jag pratar om företagsvärlden. Det finns naturligtvis några undantag, och man kan alltid peka på några framgångsrika företagsanvändningsfall där Ruby antogs antingen för nya projekt eller som en omskrivning av befintliga i. Men vi ser fortfarande en massanvändning av tekniken av väletablerade företag. Det finns flera skäl till detta, men denna åsikt utvecklades endast baserat på magkänsla och jag har inga tydliga data för att validera det. Således kommer jag inte att utarbeta orsakerna till att Ruby inte används massivt på företagsmarknaden.
Med tanke på allt tror jag att detta var en missad möjlighet och mjukvaruindustrin erbjuder nu många livskraftiga alternativ till Ruby on Rails. Vissa används i stor utsträckning av startups (dvs. Phoenix), medan andra har viss penetration på företag eftersom de är byggda ovanpå teknik som korps redan använder (ja django, Jag pratar om dig). Men om du vill kunna hjälpa både företag och nystartade företag kan du inte gå fel med JavaScript & Node.js. Jag säger inte att Rails inte är lämpliga för ändamålet.
De flesta gånger är det verkligen lämpligt för ändamålet, men inte lämpligt för sammanhang. Och med sammanhang menar jag vårt sammanhang - det vill säga att kunna arbeta i en miljö där både startups och företag är villiga att satsa sin framtida stack på. Även om detta är sant för det förra, är det inte sant för det senaste. Startups och företag älskar JavaScript. Och enligt min åsikt, JavaScript-ekosystemet är mogen nog att leverera alla bra saker som Ruby och Rails har gett oss, och mycket mer i områden där Ruby och Rails aldrig kunde lysa. Låt oss ta en titt på resultaten.
Vi gjorde en grundlig forskning om ekosystemet Node.js (genom utredning och fältarbete på ett stort antal projekt) för att identifiera komponenterna i vår referensstack. Du kan tänka på att några av dessa resultat fungerar till förmån eller mot Node.js, beroende på dina mål. Din körsträcka kan variera, men vi har kunnat hitta bra lösningar för saker som databasmigreringar, autentiseringsbibliotek, admin/back-office-tillägg, automatiserad testning, objektspottning, etc. Hittills fanns det inget vi kunde göra i Rails som var svårt att uppnå i Node.js. Våra resultat går i den riktning att det finns en ersättning för nästan varje Rails-funktion eller Ruby-pärla.
Till skillnad från Ruby dominerar JavaScript webbens front-end, och med Node.js blev det känt på back-end. Det är lätt att förstå varför JavaScript är mer populärt, men jag tror också att samhället går igenom en ”cool” fas, liknande det som hände med Rails i början. Det pågår mycket markgreppning i samhället, och detta driver mycket innovation. Men jag misstänker också att vi kommer att se en viss konsolidering under de kommande åren med bibliotek och ramverk som lämnas att dö. Ruby on Rails-communityn är också stor och ganska aktiv. Men när Rails mognade förlorade den sin coola faktor och samhället stabiliserades. Detta innebär också att vi bör förvänta oss mindre innovation.
Vi har använt Ruby Motion sedan de första dagarna och publicerade flera appar i App Store. Jag måste säga att detta var en bra ram, utvecklad av mycket ljusa människor. Stödet för automatiserad testning var anmärkningsvärt. Detta var försnabbt och att leverera för iOS i Ruby var mycket trevligare än att använda Objective-C. Men RubyMotion tog en fruktansvärd tid att stödja Android, och löftet ”bygg en gång, distribuera överallt” var inte möjligt när Swift kom ut. Swifts syntax är mycket trevligare än Objective-C, och det var en tillräckligt stark anledning att sluta använda RubyMotion på nya projekt. Du kan fortfarande använda den idag, även om grundarna sålde sin verksamhet och det slutade i tid. Jag misstänker att ramverket inte kunde få tillräckligt med dragkraft för att det skulle kunna hålla koll på innovationen som drivs av Apple och Google på iOS- respektive Android-plattformarna.
Och på JavaScript-hörnet har du React Native. Det låter dig leverera inbyggda appar för iOS och Android. Det är utvecklat av Facebook och stöds starkt av en stor gemenskap. Det är också gratis att använda (RubyMotion är det inte).
När jag går tillbaka till vad jag sa i början av den här artikeln var min satsning att JavaScript skulle få en smärtsam död. Jag kunde inte ha mer fel. Det är anmärkningsvärt hur det lyckades hålla sig relevant alla dessa år, upp till den punkt där någon kunde genomföra sin masterplan och driva den till back-end. Jag tror fortfarande att det finns stora problem med språket, men å andra sidan blev Rails berömd och Ruby lider också av vissa designfel.
Det görs stora ansträngningar för att förbättra språkdesignen med de senaste utgåvorna för ECMA Script. Men vi måste fortfarande vänta på ett stort antagande av de nya utgåvorna för att dra nytta av det. Det finns också möjlighet att använda en transpiler som Babel, för att använda de nya funktionerna som finns tillgängliga i de nya ECMA Script Standards utan att offra bakåtkompatibilitet för äldre webbläsare.
Faktum är att du nu kan släppa ett komplext webb- och mobilprojekt utan att behöva använda flera språk, och detta hjälper till att minska utvecklingskostnaderna och, om du har varit i branschen länge, du måste erkänna det. Detta är en ganska cool prestation.
Med tanke på allt, för oss är JavaScript lämpligt för syfte och sammanhang. Vi har officiellt slutat rekommendera Ruby on Rails för nya projekt och kommer att välja en JavaScript-baserad arkitektur som standard. Ändå kommer vi att stödja befintliga Rails-projekt, eftersom jag tror att tekniken är mogen, redo för produktion och den kommer inte att dö när som helst snart på grund av dess mogna och stabila samhälle.
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
