Share
Webtoepassingen voor één pagina - of SPA's, zoals ze vaak worden genoemd - zijn in snel tempo de de facto standaard voor de ontwikkeling van webapps. Het feit dat een groot deel van de app binnen één webpagina draait, maakt het erg interessant en aantrekkelijk, en de versnelde groei van browserfunctionaliteit duwt ons dichterbij de dag, wanneer alle apps volledig in de browser worden uitgevoerd.
Technisch gezien zijn de meeste webpagina's al SPA's; het is de complexiteit van een pagina die a onderscheidt webpagina van een web applicatie. Naar mijn mening wordt een pagina een app wanneer u workflows, CRUD-bewerkingen en statusbeheer opneemt rond bepaalde taken. Je werkt met een SPA wanneer elk van deze taken op dezelfde pagina plaatsvindt (uiteraard met AJAX voor client / server-communicatie).
Laten we beginnen met dit gemeenschappelijke begrip, en een duik nemen in enkele van de belangrijkere dingen waarmee rekening moet worden gehouden bij het bouwen van SPA's.
Er zijn veel punten die u moet overwegen voordat u een nieuwe app gaat bouwen; Om de zaak nog erger te maken, kan het uitgestrekte webontwikkelingslandschap vanaf het begin intimiderend zijn. Ik ben in die verontrustende schoenen geweest, maar gelukkig hebben de afgelopen jaren consensus bereikt over de tools en technieken die de applicatieontwikkelervaring zo aangenaam en productief mogelijk maken.
De meeste apps bestaan uit zowel client- als serverzijde-onderdelen; hoewel dit artikel zich vooral richt op het gedeelte aan de clientzijde van een app, geef ik aan het einde van dit artikel enkele server-side pointers.
Er is een kleurrijke mix van technologieën aan de clientzijde, evenals verschillende bibliotheken en werkwijzen die een productieve app-ontwikkelingservaring mogelijk maken. Dit kan worden samengevat met behulp van de volgende woordwolk.
Ik zal in de volgende paragrafen verder gaan met elk van de bovenstaande punten.
Er is een overvloed aan raamwerken om uit te kiezen. Hier is slechts een handvol van de meest populaire:
Het kiezen van een framework is gemakkelijk een van de belangrijkste keuzes die je voor je app maakt. Zeker, u zult het beste raamwerk voor uw team en app willen kiezen. Elk van de bovenstaande raamwerken incorporeren het MVC-ontwerppatroon (in een of andere vorm). Als zodanig is het vrij gebruikelijk om naar hen te verwijzen als MVC-raamwerken. Als we deze kaders moesten bestellen op een schaal van complexiteit, leercurve en functieset, van links naar rechts, het kan er als volgt uitzien:
Hoewel ongelijksoortig in hun implementatie en niveau van verfijning, bieden alle bovengenoemde raamwerken enkele algemene abstracties, zoals:
Alleen al kijkend naar de afgelopen vijf jaar is er een explosieve groei in bibliotheken, tools en praktijken.
Meer geavanceerde frameworks, zoals CanJS, BatmanJS, EmberJS en AngularJS, breiden deze basisfuncties uit door ondersteuning te bieden voor automatische databinding en client-side templates. De sjablonen zijn gegevens gebonden en houden de weergave gesynchroniseerd met eventuele wijzigingen in het model. Als u besluit een geavanceerd kader te kiezen, krijgt u zeker veel out-of-the-box-functies, maar het verwacht ook dat u uw app op een bepaalde manier bouwt.
Van alle eerder genoemde frameworks is Meteor het enige full-stack framework. Het biedt niet alleen tools voor client-side ontwikkeling, maar het biedt ook een server-side stuk, via NodeJS, en end-to-end modelsynchronisatie, via MongoDB. Dit betekent dat wanneer u een model opslaat op de client, het automatisch blijft bestaan in MongoDB. Dit is een fantastische optie als u een Node-back-end uitvoert en MongoDB gebruikt voor persistentie.
Op basis van de complexiteit van uw app, moet u het framework kiezen dat u het meest productief maakt. Er zal zeker een leercurve zijn, maar dat is een eenmalige tol die u betaalt voor express-lane-ontwikkeling. Zorg ervoor dat u wat tijd vrijmaakt om deze frameworks te evalueren op basis van een representatieve use-case.
Notitie: Als je meer wilt weten over deze frameworks van hun makers, luister dan naar deze video's van ThroneJS.
De meest populaire JavaScript-gebaseerde templatiesystemen zijn Underscore-sjablonen en Stuur.
Sommige van de geavanceerde frameworks uit de vorige sectie bieden ingebouwde template-systemen.
EmberJS heeft bijvoorbeeld ingebouwde ondersteuning voor het stuur. Je moet echter wel een templating-engine overwegen als je besluit om een lean-framework te gebruiken, zoals Backbone. Een onderstrepingsteken is een uitstekend startpunt als u beperkte sjabloonvereisten heeft. Anders werkt Handlebars uitstekend voor meer geavanceerde projecten. Het biedt ook veel ingebouwde functies voor meer expressieve sjablonen.
Als u merkt dat u een groot aantal sjablonen voor de client nodig hebt, kunt u wat rekentijd besparen door de sjablonen vooraf op de server te compileren. Pre-compilatie geeft u duidelijke JavaScript-functies die u aanroept om de laadtijd van de pagina te verbeteren. Stuur ondersteunt pre-compilatie, waardoor het de moeite en tijd kost om volledig te verkennen.
ExpressJS-gebruikers kunnen zelfs dezelfde templating-engine op de client gebruiken als op de server, zodat u uw sjablonen kunt delen tussen zowel de client als de server.
Het gebruik van een preprocessor vereist een extra stap in uw bouwproces.
JavaScript-code wordt traditioneel toegevoegd aan de pagina, via de >
Accentsconagua