Er is niks met Composer/NPM als je de juiste workflow benut. Dependancy Managers zijn een handigheid bij het ontwikkelen. En ontwikkelen doe je niet op een shared-hosting server, maar lokaal.

Dus als je een Dependancy Manager in je development omgeving gebruikt, dan doe je het goed!

Ikzelf ben geen fan van MarkDown, maar UBB-codes. Gewoon omdat die ouder en bekender zijn. Vooral op forums doe je iedereen een plezier ermee.

Vanilla JavaScript of met jQuery. De UBB-en textopmaak hier op ICTscripters werkt behoorlijk ruk.

Citaat van wimmpie

beginnende programmeurs zijn die een shared server gebruiken

Ai. Trekken zij ook allemaal code daar vandaan om daar dan aan te werken? Hoe kun je dan garanderen dat jullie niet elkaars werk aan het overschrijven zijn? Hopelijk maak je ook gebruik van een soort van gedistribueerd versioningsysteem want het klinkt een beetje alsof dat de missende schakel is. En dat is wellicht nog een van de belangrijkste dingen die je moet regelen wanneer je met een club aan het programmeren slaat: afspraken en procedures omtrent de ontwikkeling en disitributie van code(wijzigingen).

Citaat van AarClay

De UBB-en textopmaak hier op ICTscripters werkt behoorlijk ruk.

Kun je ook aangeven wat er aan scheelt? En ergens een suggestie tot verandering/verbetering plaatsen? Dit is niet erg opbouwend, maar heb je ook een redenering waarom en wat er dan zou moeten veranderen? Deze heeft inderdaad wel een aantal quirks, maar wellicht is de kans dat er hier iets mee gedaan wordt (aanzienlijk) groter dan een zekere andere site die ik ken *kuch*.

Ik denk dat ik weet welke site je bedoelt, en daar is ooit al een antwoord op gegeven. Maar er wordt geregeld wat gedaan hoor. Maar development kost nou eenmaal tijd die gevonden moet worden.
Maar ook hier zie ik weinig activiteit hoor.. ;).

Anyway, hier krijg ik vaak de melding dat size niet geaccepteerd wordt, maar ik gebruik die tag niet. Ook blijft een gemaakte post vaak staan als die gepost is, en wil ik standaard de UBB-editor gebruiken, en geen WYSIWYG.

/Offtopic
Als het juist iets is waar ik altijd snel vanaf wilt dan is het wel UBB. Ondanks dat UBB zijn voordelen heeft tikt het gewoon minder makkelijk weg dan markdown + het scheelt wat onduidelijkheid bij het uitlezen van je database als je het mij vraagt :-).
/Offtopic/

Composer / npm zijn zo mogelijk de meest verwelkome tools die de development wereld de afgelopen tijd met snelle stappen vooruit heeft gebracht. Ondanks dat een early devver wellicht een shared hosting heeft is het voor een early devver ook belangrijk dat hij depedency management leert als je het mij vraagt..

Citaat van Patrick

+ het scheelt wat onduidelijkheid bij het uitlezen van je database als je het mij vraagt

Die volg ik niet helemaal? Zowel bij markdown alsook UBB (en ook bij gebruikmaking van WYSIWYG-editors enzo) zul je conversies moeten uitvoeren naar HTML?

/offtopic

Citaat van FangorN

Die volg ik niet helemaal? Zowel bij markdown alsook UBB (en ook bij gebruikmaking van WYSIWYG-editors enzo) zul je conversies moeten uitvoeren naar HTML?
/offtopic

Fair enough,
Dan is het meer een persoonlijk iets dat ik het makkelijker vind lezen

Citaat van AarClay

Er is niks met Composer/NPM als je de juiste workflow benut. Dependancy Managers zijn een handigheid bij het ontwikkelen. En ontwikkelen doe je niet op een shared-hosting server, maar lokaal.

Dus als je een Dependancy Manager in je development omgeving gebruikt, dan doe je het goed!

Ikzelf ben geen fan van MarkDown, maar UBB-codes. Gewoon omdat die ouder en bekender zijn. Vooral op forums doe je iedereen een plezier ermee.

Hier moet ik toch even bijtreden. Het gebruik van dependency managers in productie (d.w.z. niet je lokale dev environment maar een live-omgeving dus) is ook aan te raden. Alleen is het best om te kijken om de versies wat te "locken" zodat je geen verrassingen krijgt als je ooit een nieuwe composer install of composer update zou doen.

Eigenlijk moet je alles gewoon testen. Wat nu als de build die je in productie binnenhaalt brak is?

Citaat van AarClay

Eigenlijk moet je alles gewoon testen. Wat nu als de build die je in productie binnenhaalt brak is?

Dat doe je vanzelfsprekend al als je lokaal aan het developen bent natuurlijk. Daarom moet je de versies ook locken voor je applicatie tot op een bepaald punt.

Met dat locken ben ik het volledig eens!