Den explosiva tillväxten i mobilutrymmet har påskyndat sökandet efter en robust och lönsam plattformslösning. Under 2008, strax efter introduktionen av iPhone SDK och efter att ha fiska med Kakao och Objective-C, bestämde Brian LeRoux och hans kollegor på Nitobi att deras tid var bättre tillbringade att bygga en plattformslösning än att bygga inbyggda mobila applikationer.
Idag har PhoneGap tiotusentals mobilapplikationer. För Brian och hans lag har mycket förändrats sedan starten av PhoneGap. Under 2011 förvärvade Adobe Nitobi och källan till PhoneGap donerades till Apache Software Foundation som Cordova.
I dagens spotlight pratar jag med Brian om de första dagarna i PhoneGap, mobilens framtid, och varför PhoneGaps förstörelse är en bra sak.
PhoneGap har funnits sedan starten av mobilrevolutionen och är välkänd bland utvecklare. För dem som inte Brian LeRoux eller PhoneGap kan du berätta om dig själv och hur du är involverad i projektet?
PhoneGap skapades av en liten grupp människor, varav de flesta arbetade på Nitobi, i Kanada vid den tiden.
Den första begår var landad av Brock Whitten och Rob Ellis för iOS. IOS är idag domänen för den produktiva Shazron Abdulla. Joe Bowser hackade ut mycket tidigt Android och fortsätter att behålla det till denna dag.
Dave Johnson lade till olika BlackBerry-bitar, som nu i stort sett underhålls av BlackBerry själva med hjälp av Lorin Beer. Jesse Macfadyen skär Windows Incarnations som arbetar nära Microsoft.
Michael Brooks rockade ut dokumentationen och mycket av CLI (Command Line Interface) och testverktyg med Fil Maj. Anis Kadri har lett mycket av pluginsverktyget och upptäckten. Steve Gill har ansvarat för utgåvor och bidragit mycket av det relaterade verktyget.
Herm Wong startade Firefox OS och nu vårt nya GUI-projekt. Brandidentiteten började med Yohei Shimomae och har sedan tagits upp av Joni Rustulka. Google och IBM har också en hel del bidragsgivare.
En städande skapningshistoria med en enda hackare i källaren är en slags fantasi som vår bransch älskar, men är sällan fallet. Programvara är alltid en kollektiv insats och alla som bidrar förtjänar erkännande. Jag saknar en kanadensisk metriska ton bidragsgivare här, men du får idén.
För mig själv arbetade jag på Nitobi, bidragit mycket kod till olika områden i PhoneGap från inkarnation, men mitt huvudfokus var att bygga den tidiga projektkulturen, filosofin och målen - de saker som är avgörande för kommunikationsriktning och galvanisering av samhället.
Testning, verktyg och ombordstigning var andra viktiga problem för mig. Så småningom flyttade mitt fokus mer till att växa kommittörskapet bortom Nitobi, vilket kulminerade i källdonationen till Apache som Cordova.
Med PhoneGap som är nära sex år har de flesta åtminstone hört talas om det. För dem som inte är bekanta med PhoneGap, kan du berätta vilket problem PhoneGap försöker lösa?
PhoneGap är för att bygga mobilappar med HTML, CSS och JavaScript. Vi stöder alla större mobila operativsystem för att bygga och distribuera till inhemska appbutiker. Men vi är främst webbutvecklare och PhoneGap har för avsikt att visa webben som en förstklassig utvecklingsplattform. Vi vill bygga webbapps, inte proprietära fällor.
I slutändan ger PhoneGap dig en fina helskärms webbläsare och en extensibility-modell för åtkomst till inbyggd plattformsfunktion genom ett enkelt plugin-gränssnitt. Pluggmodellen gör det trivialt enkelt att exponera någonting på operativsystemet till webbvyn. På så sätt kan downstreams snabbt prototyper nya webbfunktioner och applikationsutvecklare begränsas inte av den traditionella webbutsikten.
Under de senaste åren har huvuddelen av ansträngningen gjorts för att skapa verktyg som abstrakt vanliga inbyggda mobila utvecklings arbetsflöden. Kompilera, emulera, logga, installera plugins och den typen av saker.
Vad såg de första dagarna av PhoneGap? När visste du att PhoneGap var en lösning på ett problem som många företag och utvecklare stod inför?
De tidiga dagarna var löjliga och roliga. PhoneGap var ett sidoprojekt, och de tidiga kärnutvecklarena hackades och filosoferades ofta på Alibi Room, en berömd ölbalk i Vancouver, efter timmar.
Långsamt, som mobil började sin meteoriska uppgång, kom många andra utvecklare till bråk, lockade av de filosofiska förståelserna vi delade.
Det var, och fortfarande, en grupp trött på proprietära plattformar, förändrade operativsystem och låst i utvecklarekosystem. Träffad av mjukvaruplattformar som hävdar "ett sant sätt", bara för att uppdatera "på det sättet" var sjätte månad och senare avskriva det - om inte försvinner helt.
Under hela år med detta missbruk förbättrades webbplattformen långsamt och appar som riktade sig fortfarande sprang. Vi faller inte längre för det glänsande marknadsmaterialet som kallar sig "riktlinjer för mänskliga gränssnittsdesign".
Webben har aldrig lidit något hot, men vi hittade ett hack som skulle kunna leda till kampen mot själva plattformarna som hotar det. Projektet var alltid öppen källkod, respekterade webben först och utformad för att visa egenskaper vi kände att plattformen behövde förbli konkurrenskraftig mot proprietära alternativ. Det har alltid varit en skrämmande grupp hackare, men vi är noga med att inte ta oss själva för allvarligt.
För några år sedan sa du att PhoneGap "inte är en gyllene hammare" och att PhoneGap inte är lösningen för alla mobila applikationer. Är det fortfarande sant eller kommer vi närmare en mobilweb som är lika kraftfull som den inhemska upplevelsen?
Spektrumet av potentiella appar växer alltid bredare som webbläsare, och de enheter som de körs på förbättras. Jag skulle aldrig förespråka PhoneGap som de ultimata lösningen. Det finns tekniska överväganden som inbyggda plattformskonsulter och det finns mjuka problem som företagsledare, anställda färdigheter, befintlig innehållsinvestering, licensiering, tillit till leverantörer av tredjepartsplattformar och till och med partnerrelationer.
Tekniska val ger alltid avvägningar och investeringar i webbteknik som PhoneGap är inte annorlunda.
Den verkliga utmaningen som utvecklarna står inför, och särskilt i företaget, är att mobilutveckling är precis som vanlig mjukvaruutveckling. Detta är inte bara någon tidpunkt marknadsföring spike. Det finns en hel livscykel att överväga; design, utveckling, testning, analys och övervakning.
Mobil utveckling kräver löpande underhåll och resurser. Engång av ett konsultföretag behöver uppdateras när en ny version av IOS eller Android skickas. Marknadsavdelningen behöver förstå vad innehållet utför och ha möjlighet att snabbt publicera ändringar i innehåll som inte fungerar. IT-avdelningen behöver rapportering om kraschhantering och tillgång till push-meddelandeinfrastruktur.
Det längre spelet som kräver avsiktlig strategisk resurs kommer bara att erkännas, eftersom många organisationer nu bara upptäcker att de, åtminstone delvis, blir mjukvaruföretag själva. En strategisk investering i teknik som bygger på ett tredjeparts proprietärt ekosystem är en affärsrisk. PhoneGap kan hjälpa till att mildra den risken. I slutändan kommer du aldrig att förlora en insats på nätet.
Förvärvet av Nitobi av Adobe var en viktig milstolpe för PhoneGap, men Apache Cordova var förmodligen ännu viktigare. Hur har Apache Cordova ändrat plattformen?
Förvärvet av Adobe Adobe var absolut viktigt. Vi blev befriade från galet konsultarbete för att fokusera enbart på PhoneGap och det är ingen tvekan om att plattformen gynnades enormt. Donationen av PhoneGap-källan till Apache som Cordova är lika stor i en längre vy.
Arbeta med Apache tog en helt ny disciplin i projektet. Vår releaseprocess är mycket mer formaliserad och det har varit utmanande att behålla vår kadens, vår gemenskap vinner den lagliga säkra grunden att Apache är känd för.
Detta neutrala territorium är en bra miljö för individer anställda av olika organisationer att samarbeta utan oro. Sedan vi började med Apache har vi välkomnat kommittéer från IBM, BlackBerry, Microsoft, Google, Intel, HP, LG, Samsung och mer.
Som ett resultat av detta har vi sett många nya downstream-distributioner av Cordova. Min bias är för Adobe PhoneGap, men utvecklare kan välja att rikta in BlackBerry Webworks, IBM Worklight, SAP SDK, Telerik, Intel XDK eller Google Mobile Chrome Apps.
Vissa människor använder bara vanilj Apache Cordova och skapar egna nedströms. Jag älskar denna mångfald. Allt detta pekar på ett pulserande och hälsosamt ekosystem som vår utvecklingssamhälle kan räkna med. Vi repeterar snabbt, adresserar buggar snabbt, lägger till nya funktioner på en vanlig kadens och har en mycket väl förstådd bidragsprocess vem som helst kan delta i.
Apache har ett välförtjänt rykte för politik och byråkrati, men att förbättra det är också en del av vårt jobb och att arbeta med ASF (Apache Software Foundation) har i sista hand varit den rätta vägen för vårt långsiktiga samhälle. Jag är väldigt stolt över vad vi har åstadkommit med ASF.
PhoneGap är en bra plattform för utveckling av mobila applikationer. Utbyggnaden förblir besvärlig på många plattformar, men du har försökt lösa detta med PhoneGap / Build. PhoneGap / Build låter som en gyllene hammare för utvecklare som letar efter en plattformslösning. Kan du berätta vad tjänsten gör och vilket problem det löser?
PhoneGap Build är en kompilator värd i Adobe Creative Cloud. Med hjälp av PhoneGap / Build kan du rikta dig mot alla mobila operativsystem vi stöder från vilken webbläsare som helst. Du kan bygga en iOS-app från en netbook eller till och med din egen telefon (meta).
Ursprungligen trodde vi att det kan vara till hjälp för kontinuerlig integration och teständamål. Det har blivit ett allroundverktyg för den mycket diskreta processen att kompilera en app och ge den resulterande artefakten en URL. Det gör bara det där och det gör det ganska bra. Vi har sett många människor använder PhoneGap / Build som ett API eller som deras kompilator.
Du sa en gång att du tror att PhoneGaps framtid ligger i sin egen förstörelse. Kan du förklara vad du menar med det?
Ja, det slutgiltiga målet med PhoneGap är att upphöra att existera. Vi vill inte skriva inhemska appar. Vi har varit på vägen för proprietär kundutveckling och vet att det leder till riskabelt ekosystemlåsning.
Vi vill bygga webbapps och PhoneGap har alltid varit en stopgap-lösning tills webbläsare, eller kanske installerbara webbapplikationer, är kapabla alternativ. Jag tror att vi är mycket nära den verkligheten idag. För många applikationer är webben först absolut lämplig.
För att mobila webbapps ska lyckas med den ubiquity vi ser på skrivbordet, är det bra att visa de områden som webben behöver förbättra. PhoneGap-pluginarkitekturen är en riktigt smidig yta för att skapa diskreta prototyper för att exponera nya funktioner för den traditionella webbytan. Denna subtila filosofi bidrog till att lätta de rätta riktningarna för oss, genom att implementera standarder, pollyfills, samarbeta med W3C på API-designen och ge bekymmer till webbläsarens försäljare som leder till nya plattformsfunktioner.
Öppen bekräftelse på slutgiltig nedgång kan antingen vara en tragisk händelse i tid eller strategisk förståelse att planera mot. För att bevittna vår egen ångra behöver PhoneGap göra allt för att se att webbplattformen kan vinna.
Vad är några av de smärtpunkter som vi fortfarande behöver lösa på webben? Med andra ord, hur nära är vi från en mobil webb som erbjuder en upplevelse som rivaler det för inhemska applikationer?
25 år på, det är svårt att kritisera webbplattformen. Men bashing på webben, är en tid ära tradition av webmaster craft.
Kategori 1 inkomstgenererande kategori i App Store är spel. Så låt oss tänka på vad som krävs för att vara ett bra spel. Ljud övergripande är rörigt, men Web Audio API är galen fantastisk. WebRTC, eller vad vi äntligen kallar det, har ett stort löfte om att göra realtidsapplikationer mer verkliga.
Sedan finns det en massa VVS som inte helt landat allmänt, som Full Screen och Game Controller. När alla dessa saker är allmänt tillgängliga kommer det att skaka upp spel. Dataintensiva API: er som Web Audio, WebRTC och WebGL kommer att hjälpa oss att hitta kanterna på JavaScript-exekveringsprestanda och alla tidiga indikationer är extremt positiva.
Layouten blir ganska bra. Flexbox är bra och jag har stora förhoppningar för CSS Grids. Den senaste versionen av Firefox (28) åtgärdar de senaste buggarna med Flexbox. Jag har ingen aning om CSS Grids land, men jag är tålamod. Mediafrågor, ibland känd som Responsive Web Design, är användbara. Jag vill ha en mer robust kapacitetsmodell som gör det möjligt för oss att göra optimala gränssnitt optimalt.
Den största möjligheten är verkligen att knäcka offline-berättelsen, förmodligen bättre benämnd "ibland kopplad". Installerade webbapplikationer, som PhoneGap-appar, är egentligen offline, men en fullständig tillståndsmodell återstår att definiera. Mozilla, Google och W3C arbetar med det.
Många av våra läsare har ambitionen att utveckla för mobil. Om du började idag, var skulle du börja? Vilket råd skulle du ge dig själv?
Mobil är inte mycket annorlunda än vanlig kundprogrammering. Det klassiska rådet är att testa på riktiga enheter och jag uppmuntrar människor att lära sig de inbyggda plattformarna, men att inte växa för kopplade till dem. Ett bra exempel är uppdateringen av iOS 6 till iOS 7. En välbyggd och designad PhoneGap eller vanlig webapp var inte ömtålig för den uppdateringen.
Annars gäller all den vanliga programmerarens visdom. Var ambitiös inom ditt område men diskret i dina implementeringar. Skapa många grenar och var beredd att kasta det mesta av ditt arbete borta. Du är inte din kod, så refactor hänsynslöst och söka kritisk feedback.
Små moduler och prototyper är enklare att motivera, kurskorrigera, testa och validera. Bli inte upptagen i ram- och biblioteksmodell. Fokusera på problemutrymmet du har och iterera furiously och dispassionately. Skriv test och gör det dött enkelt för någon ny till codebase att köra testen själva.
Slutligen, vara super utmärkt för dina kollegor. Webben har ett långt minne, den här industrin är mindre än den först kan visas och ingen vill arbeta med ett rävhål. Ingen har någonsin funnit att en oförskämd person var smart. Flaming är bara osäkert beteende och professionellt omogna. Programmeringen är svår nog, vi kan alla lära oss något från varandra och välja en trevlig upplevelse därmed.
Jag vill tacka Brian för sin tid och för att dela med sig av hans idéer och insikter med Tuts +. Du kan höra Brian tala vid Future Insights Live 2014 i Las Vegas i juni. Konferensen har en imponerande lista över högtalare som täcker det bästa inom webbdesign, utveckling och mobil. Använd kupongkoden TUTS för 15% rabatt.