Web Jouw favoriete techstack

[Raan03]

Echt, JQuery anno 2021?

User requirements Je zou er nog van verschieten hoeveel bedrijven dat nog eisen.
Gezien ik als freelancer werk, ben ik meestal gebonden aan bepaald werk op te leveren binnen bepaalde constraints. De ene klant is de andere niet, sommige luisteren wel .

 

[recipe4hate]

User requirements Je zou er nog van verschieten hoeveel bedrijven dat nog eisen.
Gezien ik als freelancer werk, ben ik meestal gebonden aan bepaald werk op te leveren binnen bepaalde constraints. De ene klant is de andere niet, sommige luisteren wel .

Die zitten dan wellicht ook met een hoop legacy? Of met heel ouderwetse developers

 

[Raan03]

Die zitten dan wellicht ook met een hoop legacy? Of met heel ouderwetse developers

Dat was inderdaad voor die klant beide en zelfs meer. Jarenlange cyclus van Juniors (=lees: schoolverlaters) aantrekken om ervaren personen te vervangen en pas "tijdelijk" een Senior aantrekken als het project zwaar mis loopt. Nu, ik spreek wel van de jaren 2019, dus mogelijks is dat beeld ondertussen verouderd .

 

[breez]

Even een vraag: wat is de omvang van de projecten waar jullie op werken?

Ik werk zelf in een softwarebedrijf dat al heel lang bestaat en waar de meeste pakketten al 10+ jaar meedraaien.
Dat gaat helaas gepaard met heel wat legacy.
Een toepassing met een codebase waar 10+ jaar aan gewerkt is ga je niet zomaar even omgooien om op het zoveelste nieuwe trendy javascript framework over te schakelen.
Wij hebben jaren geleden de keuze gemaakt om op ASP.NET MVC + WebAPI + Angular over te schakelen voor nieuwe projecten en dat is een keuze waar we het nog heel lang mee zullen moeten doen.
Het laatste dat je wil is dat er voor ieder project een andere tech stack wordt gebruikt. Toch zeker als je al die softwarepakketten in-house ontwikkelt, wil laten communiceren met elkaar en componenten wil hergebruiken.

Dusja ik wil maar zeggen, het is niet voor iedereen een optie om alles wat (bij wijze van spreken) meer dan een jaar oud is als ouderwetse brol te beschouwen.

 

[knsL]

Hier ook de laatste 4 jaar Angular + .NET Core (ongeveer 11 jaar professioneel bezig), al neem ik er bij bepaalde opdrachten nu ook wel hasura.io bij voor zaken waar er enkel crud operaties nodig zijn omdat de speedboost gewoon enorm is. Werkt ook goed samen met Auth0 en dergelijke.

Al bij al nog niet veel te klagen gehad over die keuzes. Het jaarlijks up-to-date houden bij Angular en .NET Core valt enorm mee vergeleken met de begin jaren van Angular, alsook de Native Mobile Apps vroeger, en de hybride apps erna. Er breekt ook meer in onze (relatief grote) Django (python) software.

Ik heb wel het voordeel dat mijn klanten op langere termijn werken, en ik gelukkig ook veel andere zaken doe (devops, analyse, ...). Want javascript blijft javascript, en als je van c++ / objective-c / swift / c# komt blijft dat toch altijd een beetje "meh".

Waar ik binnenkort eens mee ga beginnen spelen is Blazor, men hoop is toch dat in dat type framework de toekomst ligt voor web development. ( https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor )

 

[Mocrosoft]

Hier ook de laatste 4 jaar Angular + .NET Core (ongeveer 11 jaar professioneel bezig), al neem ik er bij bepaalde opdrachten nu ook wel hasura.io bij voor zaken waar er enkel crud operaties nodig zijn omdat de speedboost gewoon enorm is. Werkt ook goed samen met Auth0 en dergelijke.

Al bij al nog niet veel te klagen gehad over die keuzes. Het jaarlijks up-to-date houden bij Angular en .NET Core valt enorm mee vergeleken met de begin jaren van Angular, alsook de Native Mobile Apps vroeger, en de hybride apps erna. Er breekt ook meer in onze (relatief grote) Django (python) software.

Ik heb wel het voordeel dat mijn klanten op langere termijn werken, en ik gelukkig ook veel andere zaken doe (devops, analyse, ...). Want javascript blijft javascript, en als je van c++ / objective-c / swift / c# komt blijft dat toch altijd een beetje "meh".

Waar ik binnenkort eens mee ga beginnen spelen is Blazor, men hoop is toch dat in dat type framework de toekomst ligt voor web development. ( https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor )

Wat is je stack voor mobile apps?

 

[knsL]

Wat is je stack voor mobile apps?

Heb ik niet, gezien ik de laatste 3 jaar geen nieuwe mobile apps opgestart heb. Vroeger had ik het liefst alles native (dat scheelde in mijn gevoel een pak naar maintenance). Maar ook gewerkt met nativescript, cordova en ionic toen de projecten nog van korte duur waren. Xamarin nooit een faire kans gegeven na 1 app die duidelijk te vroeg was voor het platform.

Als ik nu iets cross-platform zou moeten maken (staat er bij men klant wel aan te komen)... Misschien een lichte voorkeur naar Nativescript om tijd te besparen (code reuse).

 

[Mocrosoft]

Heb ik niet, gezien ik de laatste 3 jaar geen nieuwe mobile apps opgestart heb. Vroeger had ik het liefst alles native (dat scheelde in mijn gevoel een pak naar maintenance). Maar ook gewerkt met nativescript, cordova en ionic toen de projecten nog van korte duur waren. Xamarin nooit een faire kans gegeven na 1 app die duidelijk te vroeg was voor het platform.

Als ik nu iets cross-platform zou moeten maken (staat er bij men klant wel aan te komen)... Misschien een lichte voorkeur naar Nativescript om tijd te besparen (code reuse).

Ah oké nice, ik vroeg het omdat ik dezelfde techsteck heb. Wij zijn op het werk van xamarin naar ionic overgestapt zodat we één code base hebben.

Ik moet zeggen dat ionic vlotjes werkt en het geeft onze web development mensen de kans om aan een mobiele applicatie te werken zonder enige xaml/c# te moeten kunnen.

Nativescript heb ik zelf geen ervaring in, maar van wat ik lees, ziet dat er ook allemaal goed uit.

 

[Tyfius]

Waar ik binnenkort eens mee ga beginnen spelen is Blazor, men hoop is toch dat in dat type framework de toekomst ligt voor web development. ( https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor )

Ik heb vorige week een hobby project van mij omgezet van Angular/ASP.NET Core API naar Blazor (server side + ASP.NET Core Identity voor de login en user management) en ik moet zeggen dat het verbazend vlot ging en werkt. Ik had er tot daarvoor nog nooit mee gewerkt en was dus aangenaam verrast.

Ruwweg is het conceptueel wat hetzelfde als Angular, je hebt components met een code-behind en een render pipeline voor uw components. Die is ergens gelijkaardig aan die van Angular (OnInit, AfterView, ... component re-use enzo, dus opletten op welk punt exact je uw data fetched).

De klant waar ik momenteel zit is het ook aan het bekijken om wat custom interne dashboarding voor klanten te maken, aangezien er geen Angular/React achtige frontend ervaring aanwezig is bij een aantal teams. Voor die use-case lijkt het mij ideaal, en voor de eenvoudige sites ben ik ook overtuigd, vooral als je het voor jezelf makkelijk wil houden en bij een goeie, vertrouwde stack wilt blijven.

Voor echt grote projecten moet ik het misschien eerst nog eens goed in werking zien, want er zijn wel wat issues nog soms. Ik had bijvoorbeeld mijn code-behind in een aparte file gestoken (het is uiteindelijk gewoon een partial class), maar dat gaf bij het scaffolden van bepaalde items issues. Dat is een known-issue. De workaround is dan om je code-behind in dezelfde file als je component te steken, zoals je met Angular/React ook kan doen. En dat kan in grote sites mogelijks wel een groter probleem worden naar maintainability.

 

[bruno-d]

Een beginnersvraagje: maar wat zijn zoal de belangrijkste voordelen van frameworks?

Ik heb alles zelf geleerd, dus heb ongetwijfeld nog heel wat blinde vlekken. Voor mijn websites gebruik ik PHP + Mysql + een klein beejte jquery, en dat is ruim voldoende, maar misschien mis ik wel iets.

 

[Tyfius]

In heel wat gevallen maken ze het u makkelijker en zorgen ze er voor dat je niet bij elke website het wiel opnieuw moet gaan liggen uitvinden en/of ze gewoon al heel wat structuur bieden. Zeker bij grotere projecten waar je met meerdere personen aan werkt is dat wel handig natuurlijk.

En indien ze goed zijn en je er vertrouwd mee bent betekend dat natuurlijk tijdswinst. Dus is het project sneller klaar en kost het minder.

Voor de website van de lokale bakker die maar uit 3 pagina's bestaat is de vraag of het de moeite waard is natuurlijk, maar ik weet dat ik door het gebruik van een framework mij niets meer moet aantrekken van users/roles/permissions etc, dat zit er allemaal in. Zo van die dingen.

Voor PHP kan je kijken naar https://symfony.com/ of https://laravel.com/ bijvoorbeeld.

 

[knsL]

Voor echt grote projecten moet ik het misschien eerst nog eens goed in werking zien, want er zijn wel wat issues nog soms. Ik had bijvoorbeeld mijn code-behind in een aparte file gestoken (het is uiteindelijk gewoon een partial class), maar dat gaf bij het scaffolden van bepaalde items issues. Dat is een known-issue. De workaround is dan om je code-behind in dezelfde file als je component te steken, zoals je met Angular/React ook kan doen. En dat kan in grote sites mogelijks wel een groter probleem worden naar maintainability.

Erg goed om te lezen ;-) Thanks!

 

[recipe4hate]

Niet alleen reuse, ook reactivity en SPA zijn voor mij 2 heel belangrijke om voor een framework te gaan.
En natuurlijk goeie best practises en constructs reeds ingebakken.

 

[Tronux]

PHP Symfony voor backend web apps, dependencies managen via composer.
Voor high IO non-blocking; Node js, Deno, Swoole (PHP).
Event driven: RabbitMQ.
HTTP Reverse proxy caching: Varnish-cache.
UI testing via Symfony-Panther of cypress js.
API & database testing via Codeception (BDD)
Unit testing via PHPspec (BDD)
API definition opbouwen via Swagger (OpenAPI spec)
Docker om alles lokaal op te spinnen, phpmyadmin toevoegen voor het gemak.
React voor front-end.
Mobile apps in de vorm van PWA's a.d.h.v. service workers.
Relational DB: Mysql
Memory DB: Redis
Python voor AI toepassingen.

 

[breez]

Ik heb vorige week een hobby project van mij omgezet van Angular/ASP.NET Core API naar Blazor (server side + ASP.NET Core Identity voor de login en user management) en ik moet zeggen dat het verbazend vlot ging en werkt. Ik had er tot daarvoor nog nooit mee gewerkt en was dus aangenaam verrast.

Ruwweg is het conceptueel wat hetzelfde als Angular, je hebt components met een code-behind en een render pipeline voor uw components. Die is ergens gelijkaardig aan die van Angular (OnInit, AfterView, ... component re-use enzo, dus opletten op welk punt exact je uw data fetched).

De klant waar ik momenteel zit is het ook aan het bekijken om wat custom interne dashboarding voor klanten te maken, aangezien er geen Angular/React achtige frontend ervaring aanwezig is bij een aantal teams. Voor die use-case lijkt het mij ideaal, en voor de eenvoudige sites ben ik ook overtuigd, vooral als je het voor jezelf makkelijk wil houden en bij een goeie, vertrouwde stack wilt blijven.

Voor echt grote projecten moet ik het misschien eerst nog eens goed in werking zien, want er zijn wel wat issues nog soms. Ik had bijvoorbeeld mijn code-behind in een aparte file gestoken (het is uiteindelijk gewoon een partial class), maar dat gaf bij het scaffolden van bepaalde items issues. Dat is een known-issue. De workaround is dan om je code-behind in dezelfde file als je component te steken, zoals je met Angular/React ook kan doen. En dat kan in grote sites mogelijks wel een groter probleem worden naar maintainability.

Server slide Blazor doet mij toch heel hard denken aan ASP.NET WebForms.

Onpopulaire mening waarschijnlijk maar ik heb nooit echt begrepen wat mensen zo slecht vinden aan WebForms. Veel hangt af van de manier waarop je ermee werkt volgens mij.
Toegegeven, de page lifecycle is een pain in the ass om mee te leren omgaan, maar eenmaal je mee bent valt het best wel mee. Er zijn gewoon een aantal dingen waar je rekening mee moet houden zoals de viewstate zo clean mogelijk houden.
Het is natuurlijk wel gebouwd in een tijd dat async en dependency injection nog niet echt werden gedaan, maar het kan op zich wel allemaal.