Node.js, Vertx, volwassenheid en type safety

donderdag 24 april 2014 16:25

Topicstarter

Iets als JSHint zal denk ik een hoop helpen. Ik zal eens zoeken naar een goede IDE waarbij alles geintegreerd is.

Levert dat gebrek aan type-safety geen problemen op bij de verwerking van datums en informatie over prijzen?
Java is geen topper op het gebied van datumverwerking (getters die interne variabelen aanpassen enzo, daarom gebruik ik vaak joda time), maar met variabelen die zowel als string/getal of als datum geinterpreteerd kunnen worden, lijkt het me lastig om het geheel robuust te houden, zonder verkeerde afrondingen of ongewenste conversies.

Ik zal me er nog wat verder in verdiepen, aangezien ik op internet ook zeer weinig bezwaren tegenkom tegen deze consequentie voor Node.js.

Acties:

Pizzalucht

Snotneus.

Ik schrijf mijn Node.js gewoon in PHPStorm, die heeft ingebakken support voor Node.js/js (kan zijn dat dit met een plugin moet), daar zitten een aantal handige features in zoals code completion, validation en andere dingen die je code beter/schoner maken.

Waarschijnlijk is dit ook zo voor de andere IDEA editors.

donderdag 24 april 2014 16:46

Acties:

donderdag 24 april 2014 16:59

IntelliJ IDEA en Webstorm ondersteunen voor zover ik weet inderdaad gewoon node.js native. Anders krijg je editors zoals Brackets (Adobe) of Atom (GitHub) die zelf ook in node.js draaien.

Wat betreft de tijdproblemen op Java, Joda-time is tegenwoordig de standaard datum/tijd bibliotheek in Java 8, dus dat zou ook verleden tijd moeten zijn. Wel moet je voor Java 7 of lager gewoon Joda-time nog gebruiken.

Om verder op je vraag in te haken. Zelf vind ik node.js een mooie, elegante oplossing voor een bepaald probleem; namelijk dat je een webapplicatie wilt bouwen zonder veel configuratie of vervelende programmeertalen. Voor grotere enterprise-achtige applicaties zie ik het niet zo snel gebruikt worden, maar daar is denk ik node.js ook niet echt voor bedoeld.

Zelf ben ik daarom nog niet overtuigd van node.js, maar ben ik wel aan het kijken voor alternatieven op Tomcat + JSP en Apache + PHP.

Acties:

Creepy

Tactical Espionage Splatterer

Wat voor logheid bedoel je eigenlijk? Alleen het moeten deployen in een container? Want al die overkill in Java EE die je blijkbaar ziet, lijkt me prima op te lossen. Ook in Java kan je "lightweight" web apps maken. En bijv Jetty kan je ook embedden zodat je geen container meer nodig hebt

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

donderdag 24 april 2014 17:25

Acties:

vrijdag 25 april 2014 09:17

Rantmeister!

Wij hebben hier een aantal node apps draaien en hebben behoorlijk wat trucs uit moeten halen om het zaakje enigszins geschaald te krijgen. Ik ben geen node expert, maar het kwam er op neer dat 6 van de 7 cores idle waren.

Als je java/spring/tomcat etc zat bent kijk dan eens naar het play framework. Het zal ongetwijfeld beter aansluiten bij je achtergrond en je bent van alle container onzin af, ik werk er nu ongeveer een jaar mee en ga nooit meer terug

Acties:

vrijdag 25 april 2014 12:46

Topicstarter

Creepy schreef op donderdag 24 april 2014 @ 16:59:
Wat voor logheid bedoel je eigenlijk? Alleen het moeten deployen in een container? Want al die overkill in Java EE die je blijkbaar ziet, lijkt me prima op te lossen. Ook in Java kan je "lightweight" web apps maken. En bijv Jetty kan je ook embedden zodat je geen container meer nodig hebt

Ik vind het puur persoonlijk prettiger om met niets te beginnen en alles toe te voegen wat ik nodig heb, dan te beginnen met teveel en dingen weglaten. Het Web Profile gedeelte van Java EE is wel lichter, maar voor hobbymatig gebruik alsnog veel te zwaar. Verdere lompheid zit hem in de glassfish/tomcat server die veel tijd vraagt bij een redeploy/ serieuze codewijziging.

@Kettrick: Ik heb me wat verdiept in Node.js qua gebruik van cores, dat lijkt inderdaad maar erg beperkt.
Ik zal eens serieus kijken naar het Play Framework, veel Node.js pluspunten komen hierin terug. Aangezien je er specifiek over begon, het gebruik van meerdere cores, werkt dit wel prettig bij het Play Framework?

Edit: Bij nader inzien lijkt het erop dat het Play Framework in versie 2 developers steeds meer in de richting van Scala drukt en minder focus heeft op Java. Typische Play applicaties worden in Java erg onhandig te schrijven, omdat er wordt geredeneerd vanuit Scala. Het lijkt daardoor wat minder interessant te worden, ik heb geen behoefte aan het leren van een nieuwe taal.

[ Voor 14% gewijzigd door Fawn op 25-04-2014 09:52 ]

Acties:

Verwijderd

Ja Node.js is "single threaded". Dit betekend echter niet dat je jezelf niet kan forken. Dit in combinatie met iets als ØMQ voor IPC en iets als Redis voor sessie maakt het ongelooflijk eenvoudig om je web app te scalen naar meerdere cores, ja zelfs meerdere machines.

JavaScript is een taal van extremen. De taal is een mix van enerzijds ongelooflijk veel goeds maar anderzijds ook ongelooflijk veel slechts. Het mooie is echter dat je al het slechte praktisch compleet kan negeren maar het vergt jammer genoeg enige discipline van jouw kant.

Maak gebruik van een linter. Zelf gaat mijn voorkeur uit naar JSLint. JSLint is een stuk stricter dan JSHint in zijn default configuratie maar dat is net een goed iets. De IDE's van Jetbrains hebben dit ingebouwd net zoals zo veel andere bijzonder handige features.

Schrijf geen JavaScript zoals je Java schrijft. Naar mijn mening is strong typing overrated. Begrijp me niet verkeerd, ik ben een voorstander van de voordelen die strong typing zou moeten bieden. Echter, in de realiteit zijn de huidige type systems ofwel flawed ofwel oeverloos complex. Laat je niet wijs maken dat het verschil tussen loose- en strong-typing het verschil is tussen var number en int number. Omarm het concept van classless OO. Je zal zien dat "het verkeerde type vast hebben" geen issue is.

vrijdag 25 april 2014 13:30

Acties:

vrijdag 25 april 2014 14:23

Topicstarter

Aangezien ik geen rekening hoef te houden met strenge eisen of verantwoordelijkheden vanuit een bedrijf, denk ik dat ik maar begin met Node.js. (in de Mean stack)
Deze lijkt het breedste draagvlak te hebben en het best gedocumenteerd te zijn, waarmee dit het makkelijkst op te pakken valt. Verder lijkt Javascript van nature wat geschikter voor non-blocking systemen, aangezien de syntax het beter toelaat dan die van Java en de libraries niet, zoals in Java, voor een groot deel 'blocking' zijn.

Als ik de principes goed begrijp en besluit dat ik graag op deze manier verder wil werken, kijk ik tegen die tijd of de projecten Vertx en Play Framework bruikbaarder en beter gedocumenteerd zijn.
Bedankt voor jullie hulp!

Acties:

vrijdag 25 april 2014 14:45

Rantmeister!

Fawn schreef op vrijdag 25 april 2014 @ 09:17:
[...]

Ik vind het puur persoonlijk prettiger om met niets te beginnen en alles toe te voegen wat ik nodig heb, dan te beginnen met teveel en dingen weglaten. Het Web Profile gedeelte van Java EE is wel lichter, maar voor hobbymatig gebruik alsnog veel te zwaar. Verdere lompheid zit hem in de glassfish/tomcat server die veel tijd vraagt bij een redeploy/ serieuze codewijziging.

@Kettrick: Ik heb me wat verdiept in Node.js qua gebruik van cores, dat lijkt inderdaad maar erg beperkt.
Ik zal eens serieus kijken naar het Play Framework, veel Node.js pluspunten komen hierin terug. Aangezien je er specifiek over begon, het gebruik van meerdere cores, werkt dit wel prettig bij het Play Framework?

Zoals je later zelf al uitgevonden hebt, play hangt enorm op scala en akka, deze twee maken het gebruik van meerdere cores kinderlijk eenvoudig. Vrijwel alle code die ik schrijf tegenwoordig in asynchroon en gebaseerd op futures waardoor je het gebruik van meerdere cores cadeau krijgt

.

Edit: Bij nader inzien lijkt het erop dat het Play Framework in versie 2 developers steeds meer in de richting van Scala drukt en minder focus heeft op Java. Typische Play applicaties worden in Java erg onhandig te schrijven, omdat er wordt geredeneerd vanuit Scala. Het lijkt daardoor wat minder interessant te worden, ik heb geen behoefte aan het leren van een nieuwe taal.

Ik heb play nooit met java gebruikt en ben dus ook niet bekend met de api, maar de eenvoud waarmee ik in scala nieuwe functionaliteit schrijf heb ik in nog geen andere taal gezien. Persoonlijk zie ik scala als een aanvulling op mijn java kennis, en het leren van een nieuwe JVM taal is waarschijnlijk een stuk eenvoudiger dan het oplossen van problemen in javascript

.

De documentatie van Play is wat mij betreft ook redelijk ok, alle onderdelen waar je mee te maken krijgt zal goed gedocumenteerd, misschien is het gebrek aan duizenden pagina's documentatie bewijs van de eenvoud van het framework

Acties:

vrijdag 25 april 2014 14:54

Topicstarter

@Kettrick:
Volgens mij is specifiek de Java kant van de documentatie wat minder goed belicht, wat zou volgen uit de focus op Scala.

Hoe ervaar jij de snelheid van het gebruik van het Play Framework met Scala. Volgens de (inmiddels vrij oude) informatie die ik kon vinden over het framework, zorgt het compileren van Scala voor vrij veel vertraging (15 seconden bij het wijzigen van een template)
Heb je inmiddels het gevoel dat een wijziging direct doorgevoerd is en het een kwestie is van een directe refresh in de browser?

Acties:

vrijdag 25 april 2014 15:04

Rantmeister!

Fawn schreef op vrijdag 25 april 2014 @ 14:45:
@Kettrick:
Volgens mij is specifiek de Java kant van de documentatie wat minder goed belicht, wat zou volgen uit de focus op Scala.

Dat zou kunnen idd, ik heb alleen maar de scala api's gebruikt.

Hoe ervaar jij de snelheid van het gebruik van het Play Framework met Scala. Volgens de (inmiddels vrij oude) informatie die ik kon vinden over het framework, zorgt het compileren van Scala voor vrij veel vertraging (15 seconden bij het wijzigen van een template)
Heb je inmiddels het gevoel dat een wijziging direct doorgevoerd is en het een kwestie is van een directe refresh in de browser?

De scala compiler zelf wordt steeds sneller, maar het is inderdaad niet "instant'. Compile tijd zal afhangen van je machine, op mijn mac ( late 2013 i7, 16GB met SSD ) is het echter een kwestie van seconden.

Het grote voordeel is echter dat je dezelfde functionaliteit hebt op al je code, dust niet alleen templates. Wijzigingen in achterliggende lagen gaan even snel en je hoeft dus niet je app opnieuw op starten om je spring context opnieuw op te bouwen, OOM errors als gevolg etc, mooi was die tijd

Ik heb geen hands-on ervaring met node, maar we hebben een aantal node componenten in ons team en de trucks die ze uit moeten halen om performance problemen op te lossen zijn hilarisch.

Acties:

Anima-t3d

Als je strong typing en classes in JavaScript wilt, kan je altijd TypeScript gebruiken.
Check http://www.typescriptlang.org/ (kijk playground -> select walkthrough classes)
Wikipedia: TypeScript
http://www.nczonline.net/...4/thoughts-on-typescript/
Is ontwikkelt door Microsoft en integratie met VS2013

Node.js is gebruikt door IBM en vergeleken met JAVA: http://www.ibm.com/develo...-nodejs-java-1/index.html

vrijdag 25 april 2014 15:20

Acties:

vrijdag 25 april 2014 15:55

Rantmeister!

Anima-t3d schreef op vrijdag 25 april 2014 @ 15:04:
Node.js is gebruikt door IBM en vergeleken met JAVA: http://www.ibm.com/develo...-nodejs-java-1/index.html

Niet vergeleken met Java, maar met tomcat. Tomcat zit vast aan de 20 jaar oude servlet spec met alle ellende van dien, het is algemeen bekend dat applicaties gebaseerd op tomcat een zeer beperkte schaalbaarheid hebben.

Maar verwar dit niet met een beperking van de JVM

Acties:

vrijdag 25 april 2014 16:34

Daarnaast heb ik net even gekeken naar TypeScript en alhoewel het er weer eens heel mooi en gelikt uitziet van Microsoft denk ik toch dat ik het momenteel niet ga gebruiken. Het grote probleem voor mij zit het vooral in het steeds moeten compileren van TypeScript. Ik ben bang dat ik dat op den duur bloed irritant ga vinden.

Acties:

Anima-t3d

alex3305 schreef op vrijdag 25 april 2014 @ 15:55:
...Het grote probleem voor mij zit het vooral in het steeds moeten compileren van TypeScript. ...

Misschien dit: http://jessefreeman.com/d...ript-with-node-and-grunt/ Als je toch Node.js aan het gebruiken bent, gewoon een grunt erop en klaar!

vrijdag 25 april 2014 16:51

Acties:

vrijdag 25 april 2014 17:13

Topicstarter

TypeScript klinkt als een oplossing voor de bezwaren die ik nog zou hebben tegen het gebruik van Javascript.

Ik vind het alleen niet prettig om me daarmee te binden aan Microsoft, wanneer Node.js juist op een Google Javascript Engine zou moeten draaien in een (in mijn geval) linux omgeving. Ik verwacht dat ik daarmee ergens mijn hoofd ga stoten qua compatibiliteit of algemene ondersteuning.

Acties:

Anima-t3d

Fawn schreef op vrijdag 25 april 2014 @ 16:51:
... Ik verwacht dat ik daarmee ergens mijn hoofd ga stoten qua compatibiliteit of algemene ondersteuning.

Het is alleen zo dat TypeScript heel erg goed ondersteund wordt in VS2013, er zullen ook wel plug-ins zijn voor andere IDE's. Je hebt geen windows nodig voor het gebruik van TypeScript aangezien het een alt-JS is die verwisselbaar is met vanilla JS, alleen even compilen voor gebruik

zaterdag 26 april 2014 16:36

Acties:

Creepy

Tactical Espionage Splatterer

Kettrick schreef op vrijdag 25 april 2014 @ 15:20:
[...]

Niet vergeleken met Java, maar met tomcat. Tomcat zit vast aan de 20 jaar oude servlet spec met alle ellende van dien, het is algemeen bekend dat applicaties gebaseerd op tomcat een zeer beperkte schaalbaarheid hebben.

Maar verwar dit niet met een beperking van de JVM

En ook nog een andere database

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

maandag 28 april 2014 11:01

Acties:

maandag 28 april 2014 11:40

Anima-t3d schreef op vrijdag 25 april 2014 @ 16:34:
[...]

Misschien dit: http://jessefreeman.com/d...ript-with-node-and-grunt/ Als je toch Node.js aan het gebruiken bent, gewoon een grunt erop en klaar!

Ziet er redelijk uit inderdaad. Maar nogmaals, de brede ondersteuning mis ik gewoon, het liefste wil ik on-the-fly TypeScript > JavaScript wanneer ik bezig ben, maar goed dat is denk ik voorlopig nog dromen

Acties:

RayNbow

Kirika <3

Verwijderd schreef op vrijdag 25 april 2014 @ 12:46:
Naar mijn mening is strong typing overrated. Begrijp me niet verkeerd, ik ben een voorstander van de voordelen die strong typing zou moeten bieden. Echter, in de realiteit zijn de huidige type systems ofwel flawed ofwel oeverloos complex.

In welk opzicht zouden de type systems oeverloos complex zijn?

(Dat er type systems zijn die flawed zijn ben ik met je eens. Wie kwam er ooit met het briljante idee om arrays covariant te maken in Java en .NET?

)

Laat je niet wijs maken dat het verschil tussen loose- en strong-typing het verschil is tussen var number en int number.

Dat verschil dat je aankaart (var vs. int) is dynamic vs. static typing. In bijv. Python heb je geen type annotations op je variabelen, maar dat maakt Python niet meteen een loosely-typed programmeertaal.

Omarm het concept van classless OO. Je zal zien dat "het verkeerde type vast hebben" geen issue is.

Dit is natuurlijk een beetje te kort door de bocht.

Als je een object in een functie propt en die functie verwacht dat het object een .foo() methode heeft met een bepaald gedrag, dan heb je echt wel een probleem als het object van het verkeerde type is.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

maandag 28 april 2014 21:18

Acties:

Verwijderd

RayNbow schreef op maandag 28 april 2014 @ 11:40:
In welk opzicht zouden de type systems oeverloos complex zijn?

In de context van strongly typed languages uiteraard? Een orgie aan types en complexe hiërarchieën tussen deze types.

RayNbow schreef op maandag 28 april 2014 @ 11:40:
Dat verschil dat je aankaart (var vs. int) is dynamic vs. static typing. In bijv. Python heb je geen type annotations op je variabelen, maar dat maakt Python niet meteen een loosely-typed programmeertaal.

int zegt iets over het type. Het zegt niets over wanneer gecontroleerd wordt, of wat aan int toegekend wordt, van het type int is. Ja, type annotaties zijn niet altijd noodzakelijk voor strongly typed languages. Echter, deze discussie is hier op dit forum al vaker gevoerd en daarin werd het wel vaak zo verkondigd. Vandaar en ik quote mijzelf: "Laat je niet wijs maken...". Ik ben hier pro-actief.

RayNbow schreef op maandag 28 april 2014 @ 11:40:
Dit is natuurlijk een beetje te kort door de bocht. Als je een object in een functie propt en die functie verwacht dat het object een .foo() methode heeft met een bepaald gedrag, dan heb je echt wel een probleem als het object van het verkeerde type is.

Ja, zoals in elke taal overigens? De vraag is echter, wanneer krijg je deze error? At compile-time of at run-time? Dit heeft niets te maken met strong- of loose-typing. Dit is waar een degelijke IDE het verschil maakt. Niet waterdicht, ik weet het. Wat echter duizend maal meer fouten zal vinden dan type checking, dit geld overigens voor zowel strong- als loosly-typed languages, is het schrijven van unit test met een degelijke coverage.

Nogmaals, ik ben voorstander van strong typing, echter heeft loose typing ook zo zijn voordelen. Ja, ik ben kort door de bocht

. Wat ik wil is dat de topic starter het gewoon eens probeert en hopelijk zal merken dat het echt niet zo'n veel voorkomend probleem is als waarvoor hij/zij vreest.

maandag 28 april 2014 21:59

Acties:

maandag 28 april 2014 22:20

CMD+Z

Ik zou gewoon lekker met Python gaan werken. Volwassen taal, volwassen frameworks. Wel de leuke dingen van JS niet de onzin. Verder beschrijf je wat generieke kenmerken van talen en frameworks zijn, maar met welk concreet probleem je kampt is mij niet geheel duidelijk. Ik kan wel Node.js + Mongo gaan roepen maar je ben me niet dankbaar als je achteraf ontdekt dat PK's en FK's in een DB toch niet echt tot de Enterprise overhead behoorden waar je op doelde.

Ik kan me wel herkennen in het feit dat je af en toe de neiging hebt om zo hard mogelijk weg te rennen van de stroperige lagen Enterprise meuk die je veel tegen komt in Java en C# projecten. Maar net zoals ik al zei je kunt helemaal doorslaan en naar Node.js + Mongo gaan of iets conservatiever en Python + PostgreSQL doen.

iOS developer

Acties:

HMS

Waarom niet iets als Scala i.c.m. het Play framework? Dan hoef je niet al je Java kennis weg te doen.

edit: Wel lichtelijk offtopic, excuus daarvoor.

[ Voor 20% gewijzigd door HMS op 28-04-2014 22:22 ]

maandag 28 april 2014 22:48

Acties:

dinsdag 29 april 2014 00:55

Omdat je een paar posts boven je even moet lezen

.

Daarnaast heb ik even naar Scala gekeken en ik krijg er nu al de kriebels van. Geen puntkomma's verplicht; wel Singleton klassen ipv Static, maar ook gewone klassen, iets waar ik totaal het nut niet van inzie; een compleet andere Syntax dan Java, JavaScript of voor mijn part TypeScript.

Persoonlijk ben ik niet zo van al die nieuwe expressieve talen zoals Scale of Python. De ideeën zijn vast allemaal heel goed en zo, maar ik wil gewoon lekker kunnen proggen zoals ik doe in C# of Java, zonder de nadelen van PHP (zoals inconsistentie), maar met de voordelen van een gemakkelijke webtaal. Nodejs lijkt daar vooralsnog het dichts bij in de buurt te komen, maar goed dat is het misschien ook weer nèt niet.

Acties:

dinsdag 29 april 2014 00:59

CMD+Z

alex3305 schreef op maandag 28 april 2014 @ 22:48:

Persoonlijk ben ik niet zo van al die nieuwe expressieve talen zoals Scale of Python. De ideeën zijn vast allemaal heel goed en zo, maar ik wil gewoon lekker kunnen proggen zoals ik doe in C# of Java, zonder de nadelen van PHP (zoals inconsistentie), maar met de voordelen van een gemakkelijke webtaal. Nodejs lijkt daar vooralsnog het dichts bij in de buurt te komen, maar goed dat is het misschien ook weer nèt niet.

Nieuw? Python is vier jaar ouder dan Java!

Python is qua consistentie net zo goed als C#, je kunt zo de code van een andere programmeur oppakken zonder jeuk te krijgen van stijlafwijkingen, PyCharm pakt ook gewoon PEP-8 mee in de warnings dus eigenlijk nog een tandje beter. Ik hou van talen die een duidelijke standaardstijl hebben waar zo goed als iedereen zich aan houdt.

Dat je graag semicolons aan het einde van een regel wil is slechts ingesleten gewenning, bij Python is je indentatie altijd gelijk aan je semicolons en je accolades omdat je voor dat soort dingen altijd alleen maar indentatie gebruikt. Inspringing is flow, precies zoals je het toch al doet als je netjes codeert.

Expressie in Python is ook niks anders dan een soort LINQ.

iOS developer

Acties:

R4gnax

RayNbow schreef op maandag 28 april 2014 @ 11:40:
Dat verschil dat je aankaart (var vs. int) is dynamic vs. static typing.

Nee. Dat hoeft helemaal niet. Het kan ook zo zijn dat het implicit/inferred typing vs. explicit typing is.

Bij implicit typing is het zo dat een type compile-time bepaald wordt a.d.h.v. context v/d code en het tijdens runtime vast staat. Bij dynamic typing is het zo dat het type tijdens runtime niet vast staat en nog kan wijzigen, zowel doordat de variable van een ander type wordt gemaakt als wel doordat het type van de variable zelf gewijzigd wordt (bijv. door properties op het type extra aan te maken of juist weg te halen).

Hangt een beetje van de rest van de taal af.

[ Voor 6% gewijzigd door R4gnax op 29-04-2014 01:00 ]

dinsdag 29 april 2014 07:49

Acties:

RayNbow

Kirika <3

R4gnax schreef op dinsdag 29 april 2014 @ 00:59:
[...]

Nee. Dat hoeft helemaal niet. Het kan ook zo zijn dat het implicit/inferred typing vs. explicit typing is.

Maar type inference is ook static typing?

In de oorspronkelijke post werd loose tegenover strong typing geplaatst en werden de keywords var en int eraan gekoppeld. Gezien loose/strong vaak verward wordt met dynamic/static ging ik hierop in.

Je hebt wel gelijk dat als je bijv. naar C# kijkt dat var/int dan gaat over type inference versus handmatig expliciete type annotations.

Bij implicit typing is het zo dat een type compile-time bepaald wordt a.d.h.v. context v/d code en het tijdens runtime vast staat.

Helaas is de context zeer beperkt in de mainstream talen...

Maar ja, dat krijg je als je je laat verwennen door talen als Haskell.

Zo was ik ooit onder de veronderstelling dat de compiler zou uitvogelen dat x een double zou zijn in onderstaande code:

C#:

double foo()
{
    var x = 0;
    /* ... */
    return x;
}

Ik kwam er snel achter dat C# slechts aan simpele type inference doet.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

dinsdag 6 mei 2014 09:47

Acties:

Martinspire

Awesomeness

Sinds een tijdje ben ik ook de kant van Javascript ingedoken voor implementeren van logica binnen diverse toepassingen. Daarvoor was het vooral DOM manipulatie wat ik ermee deed. Maar sinds ik met Angular ben begonnen moet ik zeggen dat het best leuk is om mee te werken.

Wat ik echter wel jammer vind is dat er een ongelofelijk oerwoud aan oplossingen is, maar er weinig richting in zit. jQuery, NodeJS en Angular lijken momenteel wel blijvertjes, maar ook die veranderen dikwijls grote zaken waardoor je toch niet makkelijk kunt blijven werken. jQuery kwam met 2.0 en hoewel ik het fijn vind dat ze langzaamaan support droppen, is het toch wel een kleine shift geweest in wat je nou precies moet gaan gebruiken. Ook Angular lijkt met 2.0 weer een grote verandering te maken waardoor je daarbij weer aardig wat werk moet verrichten, wil je meegaan naar de laatste versie. NodeJS is momenteel nog vrij gelijk, maar heeft ook last van het feit dat dependancies ineens niet meer werken zoals voorheen of dat bepaalde installaties gewoon niet meer lukken. Wel is het enorm verbeterd qua gebruiksvriendelijkheid. Het installeren en gebruiken is nu op zowel OSX als Windows prima te doen.

Een ander punt wat me stoort is dat het deployen van je app niet zo gemakkelijk gaat als met een PHP/MySQL site. Er zijn ongelofelijk veel simpele hostingpakketten te gebruiken om een PHP site te deployen. Even met ftp erheen. PHPMyAdmin opstarten en je site draait. Helemaal zijn er veel complete pakketten zoals Wordpress, Joomla en Drupal te gebruiken. Dit geld ook toch wel voor Java, al is daarbij het aanbod wel lager (voor zover ik weet). Ook het beheren verder met dingen als cPanel en Directadmin zijn gewoon erg makkelijk.
Dit is met NodeJS niet het geval. Daarbij moet je al heel snel zelf iets gaan doen met git/github, SSH en dedicated of virtuele servers. Dat zorgt ervoor dat de drempel om iets even snel op te zetten, toch wat hoger ligt dan bij PHP. Ook de benodigde kennis is toch wat veel en tutorials vind ik nog wat karig waardoor je er als beginner lastig in komt. Ikzelf heb geen pure programmeeropleiding gedaan, maar ben er vanuit de front-end kant ingekomen (HTML,CSS en beetje Javascript dus). Dus voor mij was het sowieso wat lastiger.

Wel is het met een Javascript-oplossing gemakkelijker om een backend aan een SPA of mobile app te koppelen. Je praat immers al in Javascript en daarom verschilt het ook minder. Plus dat er aardig wat mogelijkheden zijn inmiddels. Het blijft echter lastig om een solide beveiliging toe te voegen die je gebruikers niet in staat stelt om de volledige database te bewerken. Er zijn wel tools zoals Passport, maar die vragen toch nog aardig wat customization. Ik vind het zelf vooral jammer dat er op dat vlak (en anderen) zo weinig te scaffolden is, want dat scheelt je gewoon bakken met tijd. Even een backend opzetten voor mijn simpele Angular app kost me daardoor bijna evenveel tijd als het maken van de rest van de app.

Een laatste punt is de community. Blijf je binnen jQuery, Angular en Node dan zijn er veel mogelijkheden. Maar wil je iets daarbuiten gaan doen dan merk je dat de community daarbij erg klein is. Er zijn aardig wat handige tools in ontwikkeling om het genereren van code makkelijker te maken of het binnenhalen van scripts/snippets of dependancies, maar die zijn toch vaak erg klein. Als ik iets zie wat me wel handig lijkt, dan kijk ik toch eerst even hoe actief het project wordt ontwikkeld, hoeveel sterren dat het heeft, hoeveel issues er zijn en of de documentatie een beetje toereikend is. Vaak blijkt dat altijd wel ergens niet het geval te zijn. En door de steeds veranderende scripts heb je vaak dat de code niet meer werkt als jij het gaat uitproberen. Zo heb ik al aardig wat MEAN tutorials gezien die gewoon niet meer werken. Ook die van dit jaar niet meer.

Waar je bij het ontwikkelen van native apps toch vaak nog wel de mogelijkheid hebt om het 1 en ander WYSIWYG in elkaar te zetten (interfaces vooral), heb je dat bij Web toch eigenlijk niet (of het genereerd onbruikbare (bv niet responsive) of onleesbare code). Ook kern-elementen moet je vaak zelf in elkaar zetten. Ik heb zelf bijvoorbeeld geen zin meer om de beveiliging helemaal vanaf 0 in elkaar te moeten zetten of, omdat ik net effe iets anders wil, geen standaard-oplossing kan gebruiken. Ik wil me focussen op de logica van mijn app en de inhoud, niet op het framework waar ik het mee maak.

Dus ik zou je willen aanraden om goed te kijken wat je precies wilt doen en aansporen vooral binnen de gebruikelijke paden te blijven alvorens je verder gaat om je eigen ding te doen. Het is een techniek die zeker in de toekomst mooie dingen gaat doen, maar vooralsnog loopt het nog niet echt storm. Gelukkig wordt het nu niet meer beperkt door hardware-mogelijkheden, is het makkelijker te installeren, zijn er meer tutorials om erin te komen en zijn er mooie ontwikkelingen gaande die zeker de markt gaan veranderen. Toch denk ik dat het nog net wat te vroeg is om er volledig in te stappen. Maar geef het zeker even een kans!

Martinspire - PC, PS5, XSX

dinsdag 6 mei 2014 10:24

Acties:

cooper87

Ik kan alleen maar bevestigen wat Martinspire zegt. Ik werk voornamelijk met PHP frameworks, maar wilde graag eens iets met NodeJS in elkaar klussen. Bij één van mijn klanten gebruiken we AngularJS en dat spreekt me ook heel erg aan.

Zodoende ben ik een blog (bij gebrek aan inspiratie...) in elkaar gaan zetten met de MEAN stack, maar ik merk ook dat er een wildgroei aan oplossingen is binnen de NodeJS stack. Daarbij loop ik ook tegen tutorials en andere sites aan met code voorbeelden die niet meer werken. Zo gebruik ik bijvoorbeeld Express 4, wat net weer anders werkt dan de meeste voorbeelden die op 3.x gebaseerd zijn. Wellicht kleine verschillen als je weet wat je doet, maar als je nieuw bent binnen een technologie is het nog wel eens zoeken.

Een ander voorbeeld is het automatisch herladen van de server zodra er wijzigingen in backend code doorgevoerd worden. Hier zijn vrij veel oplossingen voor en ik heb er denk ik 4 á 5 geprobeerd, maar geen één werkt zoals het in tutorials of YouTube videos gedemonstreerd wordt. Allemaal dependency ellende (zal ongetwijfeld aan de nieuwe Express versie liggen o.i.d.).

Als je eenmaal 'up and running' bent vind ik het wel hele leuke technologie om mee te werken. Het is prettig om in één taal je backend en je frontend logica te kunnen maken (en zo dus ook code te kunnen delen) en je kunt hele coole dingen maken. Echter kan het qua volwassenheid nog een stuk beter, maar er is wel enorm veel potentie.

dinsdag 6 mei 2014 10:49

Acties:

Martinspire

Awesomeness

Mja erg irritant als je een tutorial tot de letter volgt (of de voorbeeldcode gebruikt) en het werkt dan niet vanwege een 1 of andere vage error. Gelukkig kun je wel aardig wat terugvinden om het op te lossen, maar als je vanaf het begin al moet gaan bugfixen is het hek van de dam natuurlijk.

Nou is Express 4 ook wel een grote verbetering, maar daardoor sluiten veel tutorials niet meer aan. Je kunt wel zien wat er is veranderd, maar voor een beginner is dat toch wat irritant.

Overigens wordt dat herladen van de server vaak via Grunt gedaan, maar ook daarbij heb ik wel eens problemen gehad dat de reload toch niet goed ging waardoor een extra reload nodig was.

Zelf heb ik een tijd geleden iets in elkaar gezet. Dat werkt prima, maar is (omdat het een leerproject was) iets teveel uit zijn voegen gegroeid. Nu probeer ik een nieuwe opzet en daarbij loop ik toch al snel tegen problemen aan om het mooi te gaan doen. Dus aparte codebase voor server en front-end om ervoor te zorgen dat ik er een app van kan maken. Authorization bv via oAuth e.d. De hele combinatie zorgt ervoor dat er daar helaas nog geen kant-en-klare oplossing voor is waardoor ik helaas toch nog wel wat zelf aan het maken ben. Voordeel is wel weer dat ik dan alles in de hand heb, maar mijn kennis reikt momenteel nog niet ver genoeg om alles te kunnen implementeren waardoor ik weer code aan het lenen ben die ik nog niet helemaal begrijp.

En als iemand nog een fijn adres heeft voor het opzetten van een node-server op een bestaande server die werkt met Directadmin, dan hoor ik het graag. Of waar ik mn MEAN-stack makkelijk neer kan zetten voor gratis of weinig geld (non-profit project) ook

Zelf zou ik graag zien dat er een framework komt om simpel een backend te maken voor mn AngularJS app in PHP/MySQL. Dat draait immers al op vele servers waardoor deployen makkelijk gaat. Nou kun je wel PHP Slim framework, Drupal of een ander framework ombouwen maar daar zit toch nog aardig wat handwerk in en dat is gewoon jammer.

[ Voor 8% gewijzigd door Martinspire op 06-05-2014 10:57 ]

Martinspire - PC, PS5, XSX

dinsdag 6 mei 2014 10:52

Acties:

hillbillie

Fawn schreef op vrijdag 25 april 2014 @ 16:51:
TypeScript klinkt als een oplossing voor de bezwaren die ik nog zou hebben tegen het gebruik van Javascript.

Ik vind het alleen niet prettig om me daarmee te binden aan Microsoft, wanneer Node.js juist op een Google Javascript Engine zou moeten draaien in een (in mijn geval) linux omgeving. Ik verwacht dat ik daarmee ergens mijn hoofd ga stoten qua compatibiliteit of algemene ondersteuning.

http://www.coffeescript.com/ $_/-\o_$

dinsdag 6 mei 2014 11:00

Acties:

Dat is natuurlijk onzin. Of je dan TypeScript gebruikt van Microsoft of CoffeeScript van een andere maker, dat maakt natuurlijk niet uit. Dat je jezelf dan moet 'binden' aan Microsoft is misschien voor een gedeelte waar, maar aan de andere kant blijft het gewoon Javascript. Sterker nog, je zou TypeScript > JavaScript > CoffeeScript kunnen doen zonder problemen, dus als je van de ene naar de andere taal wilt, is dat geen probleem.

Wat ik nochtans een groter bezwaar vind is het constant opnieuw moeten compileren, dat is gewoonweg vervelend en zou niet moeten.

dinsdag 6 mei 2014 12:10

Acties:

hillbillie

alex3305 schreef op dinsdag 06 mei 2014 @ 11:00:
Dat is natuurlijk onzin. Of je dan TypeScript gebruikt van Microsoft of CoffeeScript van een andere maker, dat maakt natuurlijk niet uit. Dat je jezelf dan moet 'binden' aan Microsoft is misschien voor een gedeelte waar, maar aan de andere kant blijft het gewoon Javascript. Sterker nog, je zou TypeScript > JavaScript > CoffeeScript kunnen doen zonder problemen, dus als je van de ene naar de andere taal wilt, is dat geen probleem.

Wat ik nochtans een groter bezwaar vind is het constant opnieuw moeten compileren, dat is gewoonweg vervelend en zou niet moeten.

Wie schrijft er nog typescript / cofee / andere precomiled meta taal zonder een task runner a la grunt / gulp met auto compile?

dinsdag 6 mei 2014 14:23

Acties:

TheNephilim

Wtfuzzle

Heb hier een ledenadministratie in php in elkaar geknutselt, maar wil dit op lange termijn ook eens overzetten naar iets als NodeJS of AngularJS. Lijkt me niet alleen leerzaam, maar ook ideaal voor zo een project. Met projecten voor klanten is het vaak wat lastiger, zeker als het een gewone website betreft.

dinsdag 6 mei 2014 15:54

Acties:

CMD+Z

Ik snap wel dat mensen hier van PHP af willen, maar ik vraag me af of JS zo veel beter is. Sommige mensen klagen hier over vage errrors, dat is inherent aan het gebruik van JS in mijn optiek en heeft weinig te maken met het feit dat er een snelle cyclus van verbeteringen plaatsvindt. Ik mag bij iedere release van de Cocoa Touch SDK ook weer nieuwe Warnings en Memory Leak hints wegwerken en bij iedere grote release van de SDK zijn er weer nieuwe dingen depracated maar je weet meteen waar de problemen zitten en alles is gedocumenteerd.

De laatste versies van PHP staan een vrij dynamische manier van werken toe maar je moet dus niet gaan werken met de oudere en bekendere frameworks.

Martinspire schreef op dinsdag 06 mei 2014 @ 10:49:

Zelf zou ik graag zien dat er een framework komt om simpel een backend te maken voor mn AngularJS app in PHP/MySQL. Dat draait immers al op vele servers waardoor deployen makkelijk gaat. Nou kun je wel PHP Slim framework, Drupal of een ander framework ombouwen maar daar zit toch nog aardig wat handwerk in en dat is gewoon jammer.

Ik heb wel eens een backend voor een app in elkaar gedraaid met http://www.slimframework.com/ en qua PHP is het een aanrader. Ik werk liever met Python en de volgende keer ga ik er Flask voor gebruiken maar ik had met Slim wel zoiets van dit is niet de PHP van vroeger.

iOS developer

dinsdag 6 mei 2014 16:07

Acties:

Cilph

Wat is er zoveel mis dan met Java EE / OSGi style development dan

?

dinsdag 6 mei 2014 18:52

Acties: