JavaScript Framework - Of toch blijven bij wat bekend is?

[HollowGamer]

Een hele tijd is er een enorme hype geweest om node.js, het zou alle grote frameworks en componenten eromheen vervangen.

Nu geloof ik hier opzicht best in:
- NPM is super eenvoudig in gebruik en bijna elk pakket is beschikbaar
- Doordat de validatie, verwerking, etc. plaatsvind op de achterkant, hoef je op de voorkant 'alleen' maar verbinding te maken met de backend d.m.v. API. Ook kunnen views in zijn geheel worden gestuurd naar de frontend volgens de frameworks.
- ORM ondersteuning
- asynchroon
- Flexibel en heel erg lightweight
- node.js server
- cross-platform
- Laravel is vrij groot en log, terwijl de JS-frameworks erg klein en snel lijken

Nu zie ik ook wel de nadelen:
- Totaal niet bekend zijn met de taal (op jQuery na)
- Enorme wildgroei aan frameworks (ExpressJS, Sail.js, etc.) - welke is nu de standaard?
- PHP is nog enorm in de lift en lijkt met Laravel & Vue nog iets nieuws in handen te hebben
- Het is nog volop in ontwikkeling, al lijken veel bedrijven het te gebruiken als Google, eBay en PayPal

Nu ben ik al een beetje aan het spelen met Sail.js en dat lijkt erg goed en mooi te werken.
Express.js is ook interessant, maar hier lijkt niet echt een 'standaard afspraak' te zijn voor routes, modellen, etc.

Ik vroeg mij af wat jullie ervaringen zijn? Is het overdreven de hype of zijn jullie als developer ook al aan het overstappen of dit aan plannen?

[mrBako]

Ik gebruik Vue eigenlijk vanaf de release en heb eventjes ook gewerkt met React en Angular. Ik vind Vue qua instapcurve wel het meest simpele en de community is groot en groeit alleen maar verder. Verder vind ik Javascript zonder jQuery een fijnere manier van werken. Als je jQuery onder de knie heb is Javascript zeker geen probleem om aan te leren(soms mis je wat, maar het is zo veel fijner hoe het onder de $. werkt) probeer anders de pagina youmightnotneedjquery

Wat ik heb gedaan bij de keuze welke framework handig was: even een simpele project pakken en omzetten naar een JS framework. Zo weeg ik de voor- en nadelen tegenelkaar af en kies ik vaak wat mij het beste lijkt.

Overstappen? Als je al een API hebt vind ik het handig om een framework te gebruiken.

[Ofyles2]

Voorlopig zou ik nog zweren bij PHP-, Python-, en C#-frameworks. Ik zie JavaScript nog als een must voor client-side oplossingen, maar niet voor fullstack-projecten.

[q-enf0rcer.1]

Ofyles2 schreef op maandag 1 mei 2017 @ 22:39:
Voorlopig zou ik nog zweren bij PHP-, Python-, en C#-frameworks. Ik zie JavaScript nog als een must voor client-side oplossingen, maar niet voor fullstack-projecten.

Ik ben wel benieuwd waarom je dit vindt. De mogelijkheid om in zowel de front-end als back-end dezelfde code te kunnen gebruiken (Isomorphic JavaScript) is naar mijn mening echt een ontzettend grote plus. Daarnaast zit je niet de hele tijd met syntax te klooien, omdat je altijd dezelfde syntax gebruikt.

[Ofyles2]

Eerlijk gezegd niet om feitelijke redenen. Eigenlijk meer om "idiot proof"-redenen.

[DJMaze]

q-enf0rcer.1 schreef op dinsdag 2 mei 2017 @ 12:33:
Ik ben wel benieuwd waarom je dit vindt. De mogelijkheid om in zowel de front-end als back-end dezelfde code te kunnen gebruiken (Isomorphic JavaScript) is naar mijn mening echt een ontzettend grote plus.

Dat kan ik ook in andere talen

q-enf0rcer.1 schreef op dinsdag 2 mei 2017 @ 12:33:
Daarnaast zit je niet de hele tijd met syntax te klooien, omdat je altijd dezelfde syntax gebruikt.

Heeft node.js dan:

code:

(static)? class Name extends ParentClass
{
    (virtual)? (public|private|protected) (static)? (function|property);
}

Oftewel het is prototypal language en niet een class-based language.
Daarnaast is elke variabele (net als in PHP) een soort van "typeless". Je moet dus altijd controleren wat er in zit (number, string, function, class, etc.).
Zou leuk zijn als JavaScript type casting heeft, toch?

[q-enf0rcer.1]

DJMaze schreef op dinsdag 2 mei 2017 @ 13:53:
[...]

Dat kan ik ook in andere talen


[...]

Heeft node.js dan:

code:

(static)? class Name extends ParentClass
{
    (virtual)? (public|private|protected) (static)? (function|property);
}

Oftewel het is prototypal language en niet een class-based language.
Daarnaast is elke variabele (net als in PHP) een soort van "typeless". Je moet dus altijd controleren wat er in zit (number, string, function, class, etc.).
Zou leuk zijn als JavaScript type casting heeft, toch?

Ik ben wel benieuwd welke talen je dan bedoelt. Naar mijn weten is JavaScript de enige scripttaal die werkt op de front-end van het web.

Wat jij wellicht bedoelt is dat je code kunt compileren naar JavaScript.

Voor je vragen: kijk eens naar https://www.typescriptlang.org/

[Hydra]

q-enf0rcer.1 schreef op dinsdag 2 mei 2017 @ 12:33:
Ik ben wel benieuwd waarom je dit vindt. De mogelijkheid om in zowel de front-end als back-end dezelfde code te kunnen gebruiken (Isomorphic JavaScript) is naar mijn mening echt een ontzettend grote plus.

In de praktijk is de overlap tussen front-end en back-end over het algemeen nihil. Dus dat is nauwelijks een voordeel. In de praktijk is het bouwen van een back-end in JavaScript gewoon een nadeel; want JavaScript. Complexe spullen bouwen in een yolo-typed language als JavaScript moet je niet willen.

[q-enf0rcer.1]

Hydra schreef op dinsdag 2 mei 2017 @ 14:41:
[...]


In de praktijk is de overlap tussen front-end en back-end over het algemeen nihil. Dus dat is nauwelijks een voordeel. In de praktijk is het bouwen van een back-end in JavaScript gewoon een nadeel; want JavaScript. Complexe spullen bouwen in een yolo-typed language als JavaScript moet je niet willen.

Dat hangt natuurlijk van het type applicatie af. Ik maak veel real-time applicaties, dan merk je toch dat je heel vaak je data al op de client wilt valideren zodat je niet eerst op de server hoeft te wachten. Dat is een praktijkvoorbeeld waarin isomorphic JavaScript heel handig is. Maak je een website waarbij er per page alleen wat data moet worden ingeladen dan is een simpele REST-API natuurlijk voldoende.

[_Erikje_]

Wij gebruiken Java op de backend en we zijn nu aan het overstappen op Vue.js op de frontend. Hierdoor hebben wij een puur JS frontend en is de backend alleen nog een API. De licenties voor de backend zijn vrij prijzig waardoor het voor onze klanten ook interessant is.

De trend van de afgelopen jaren, eigenlijk na AngularJS etc, is om Javascript op de frontend te draaien. je kunt zelf kiezen of je node.js, ruby on rails, Laravel of whatever op de backend draai. De expertise van je team moet gewoon aansluiten op je stack.

Over validatie: altijd valideren op de frontend én de backend. De frontend validatie kan uitgezet worden maar heeft wel het voordeel dat je niet op de backend hoeft te wachten (page refresh?) en de backend validatie voorkomt troep in je database.

[Hydra]

q-enf0rcer.1 schreef op dinsdag 2 mei 2017 @ 15:02:
Dat hangt natuurlijk van het type applicatie af. Ik maak veel real-time applicaties, dan merk je toch dat je heel vaak je data al op de client wilt valideren zodat je niet eerst op de server hoeft te wachten.

Input validatie op de front-end heeft een heel ander doel (sturen van users) dan validatie op de back-end. Daarbij zitten daar vaak mechanismen ingebakken in de front-end frameworks die uberhaupt niet in de back-end gebruikt worden (je gaat in je Node.js back-end geen AngularJS validatie gebruiken). Dit wordt vaak als voordeel aangehaald maar in de praktijk (en ik heb genoeg AngularJS apps gemaakt voor m'n werk, hoewel ik primair back-end dev ben) is het echt nihil. Het weegt absoluut niet op in de rommel die je krijgt (dat je verplicht bent een JS linter te gebruiken zegt al genoeg) met JS / NPM meuk op je back-end.

[Bosmonster]

Er worden een hoop zaken door elkaar geroepen. Een gemiddelde webapplicatie bestaat uit 3 lagen (geen compleet technisch verantwoorde uiteenzetting, maar voor het doel van deze uitleg afdoende):

- Data/Service laag. In veel gevallen wil je hier tegenwoordig een losse data-API voor opzetten, bijvoorbeeld REST. Dit kan in bijna elke taal/technologie wel, maar je ziet dat Node.js hier terrein aan het winnen is ivm de async capaciteiten out of the box.

- Backend/View-laag. Hier is het veel om te doen tegenwoordig. Simpelweg templates uitrenderen en naar de client sturen is behoorlijk gedateerd. Je kunt, in het geval van een SPA ook nog simpelweg helemaal niks uitrenderen aan de backend (white page of death), maar dit heeft serieuze gevolgen voor SEO en performance. Aangezien je deze views in het geval van een SPA MVVM bijvoorbeeld wil kunnen hergebruiken in de frontend, maakt het ook wel sense om hier een technologie voor te gebruiken die dit mogelijk maakt. JavaScript is dan je enige optie en React een veel gebruikte view library. In dit geval hebben we het over isomorphic/universal.

- Frontend-laag. Je kunt simpelweg je html uit de backend tonen en daar wat JavaScript overheen gieten, maar er is een duidelijke trend gaande richting meer JavaScript, meer interactie en meer "zwaardere", simpelweg API-consumerende clients. Of dit nu Angular, Vue, React of wat anders is, doet er eigenlijk niet eens zo toe.

Hier zie je eigenlijk al wat er gebeurt: Voor al deze lagen is JavaScript geschikt (of zelfs benodigd, zoals de frontend of shared views). Als je frontend in JavaScript is, je services waarschijnlijk in Node.js, en je je views vanuit de backend ook wilt delen met je frontend-app, hou je nog maar 1 taal over: JavaScript.

Een andere verklaring voor de opbloeiende populariteit van JavaScript is de groeiende populariteit van functional programming. In JavaScript zijn functies first-class citizens en dit maakt de taal uitermate geschikt voor functioneel programmeren.

Dus dat er een soort homogenisering richting JavaScript/Node.js plaatsvindt, is eigenlijk niet zo heel raar.

[ Voor 14% gewijzigd door Bosmonster op 02-05-2017 22:42 ]

[Creepy]

Sorry, maar webapplicatie en SEO? Website en SEO snap ik. Maar de webapps die ik maak, daar loggen mensen op in, dus is SEO absoluut niet van toepassing daar. De views tussen backend en frontend delen ook niet. Dus de noodzaak die je ziet voor Javascript op de backend is er bij ons dan ook totaal niet. De backend is dan ook direct de "data/service" laag zoals je die noemt. Die View-laag is er dan bij ons ook helemaal niet, althans niet op de manier die je nu beschrijft.

[ Voor 5% gewijzigd door Creepy op 02-05-2017 22:42 ]

[Bosmonster]

Creepy schreef op dinsdag 2 mei 2017 @ 22:41:
Sorry, maar webapplicatie en SEO? Website en SEO snap ik. Maar de webapps die ik maak, daar loggen mensen op in, dus is SEO absoluut niet van toepassing daar. De views tussen backend en frontend delen ook niet. Dus de noodzaak die je ziet voor Javascript op de backend is er bij ons dan ook totaal niet. De backend is dan ook direct de "data/service" laag zoals je die noemt. Die View-laag is er dan bij ons ook helemaal niet, althans niet op de manier die je nu beschrijft.

Je kunt dezelfde technologie ook gebruiken voor websites en dan is SEO wel belangrijk. Neem mobile.twitter.com bijvoorbeeld. Een universal, high performance React app. Of meer lokaal: blendle.com.

Je gaat deze technologie steeds vaker ook voor websites zien, omdat SEO en performance er door deze methodes dus niet meer onder hoeft te lijden.

Voor interne webapplicaties is het inderdaad nog grotendeels overkill en het staat nog wel in de kinderschoenen.

[ Voor 14% gewijzigd door Bosmonster op 02-05-2017 22:48 ]