React versus Xamarin

[BugBoy]

Vroeger was het leven gemakkelijk:

• Unix: C/C++
• Windows: C/C++ en daarna C#
• Web: Javascript

Er zijn in de loop van de jaren natuurlijk allerlei alternatieven bijgekomen. Java is nog altijd erg populair aan de back-end en ook Go neemt in populariteit toe. Maar ook die talen hebben allemaal wel een redelijk duidelijk doel.

Javascript (ik weet het, eigenlijk ECMAScript)
De laatste jaren zie je het eigenlijk steeds meer door elkaar lopen. Was Javascript in het begin echt een taal die alleen gebruikt werd in je browser, maar met NodeJS is het ook een prima keuze voor de back-end. Met React Native kan je tegenwoordig in Javascript programmatuur maken voor mobiele apparaten. Microsoft heeft zelfs React Native for Windows gemaakt, waardoor je deze technologie ook door kan trekken naar het Windows platform.

Ik vond Javascript niet erg onderhoudbaar, doordat er geen strong typing is. Refactoring is daardoor tricky, maar dat is met Typescript prima te ondervangen. De laatste versies met async/await ondersteuning maken het voor mij een taal waarmee het prima mogelijk is om enterprise-grade applicaties mee te ontwikkelen.

C#
C# is een taal die is ontstaan om te kunnen programmeren voor het .NET Framework. Was dat in eerste instantie alleen geschikt voor Windows, maar sinds Mono en .NET core is het ook beschikbaar voor Linux en Mac. Het is een krachtige taal met strong typing en ook het .NET framework biedt eigenlijk voldoende om goede front-end en back-end applicaties te ontwikkelen. Met Xamarin is het ook mogelijk om C# te gebruiken voor mobiele apparaten. Er zijn libraries voor generieke interfaces (Xamarin Forms) of voor native interfaces (iOS of Android).

Wat te kiezen?
Voor nieuwe ontwikkelingen ben ik een beetje zoekende. Stel dat ik een front-end applicatie moet maken. Voorheen maakte ik die in C# met WPF en daar heb ik nooit echt spijt van gehad. Sommige applicaties draaien al jaren bij klanten naar volle tevredenheid.

Maar wat als ik nu opnieuw zou moeten beginnen? WPF heeft ook zo zijn nadelen. De voornaamste is dat het alleen op een Windows apparaat werkt. Liever heb ik een code-base die breder inzetbaar is en dan wordt het toch al wat lastiger. Het liefst wil je een applicatie die ook op iOS en Android kan werken, zonder (drie)dubbele codebases.

Ik zie nu eigenlijk maar een paar opties:

1. Xamarin, waarbij de vergaarde C# kennis niet verloren gaat. Delen van de oude code kunnen wellicht hergebruikt worden. Ik ben 20 jaar werkzaam in het Microsoft ecosysteem, dus Xamarin lijkt heel wat te zijn, maar is dat ook wel echt zo? Microsoft heeft vaker dit soort systemen gehad (bijv. Silverlight) waar zo de stekker uit ging. Dat vind ik wel tricky.
2. React Native, maar dan moet de hele club C# programmeurs om naar Typescript. Ook is React met zijn build-omgeving, packages, ... best een uitdaging en dus een risico voor nieuwe programmatuur. Wellicht eerst maar eens beginnen met een React website (daarvoor heb je toch weinig andere keuze, behalve Angular) en die applicatie voorlopig maar even laten voor wat het is.
3. Kop in het zand en gewoon weer een WPF applicatie ontwikkelen. Minder risico, maar wellicht naar de toekomst toe te ouderwets en te beperkt.

Ik ben eigenlijk wel benieuwd wat jullie visie is m.b.t. deze nieuwe, meer hybride, oplossingen...

[DJMaze]

BugBoy schreef op woensdag 4 juli 2018 @ 11:37:
Javascript (ik weet het, eigenlijk ECMAScript)

Dat is niet helemaal het zelfde.
ECMAScript is inderdaad de basis, maar bijvoorbeeld de DOM is geen onderdeel van ECMAScript

Zie het dus meer als:
C = ECMAScript
C++ = JavaScript


Antwoord op je vraag: ik programmeer gewoon in een taal/framework die ik mij snel eigen kan maken.
Kost wel een dag per stuk om uit te proberen, maar dan weet ik aan het einde van de dag genoeg.

[ Voor 22% gewijzigd door DJMaze op 04-07-2018 11:44 ]

[ThomasG]

DJMaze schreef op woensdag 4 juli 2018 @ 11:42:
[...]

Dat is niet helemaal het zelfde.
ECMAScript is inderdaad de basis, maar bijvoorbeeld de DOM is geen onderdeel van ECMAScript

Zie het dus meer als:
C = ECMAScript
C++ = JavaScript


Antwoord op je vraag: ik programmeer gewoon in een taal/framework die ik mij snel eigen kan maken.
Kost wel een dag per stuk om uit te proberen, maar dan weet ik aan het einde van de dag genoeg.

De DOM is ook geen onderdeel van JavaScript. De DOM is niets meer dan een API, wat door browsers o.a. wordt aangebiden in JavaScript. Je kunt prima JavaScript hebben zonder DOM. ECMAScript is een language-specification, en JavaScript is een implementatie daarvan.

[BugBoy]

DJMaze schreef op woensdag 4 juli 2018 @ 11:42:
Antwoord op je vraag: ik programmeer gewoon in een taal/framework die ik mij snel eigen kan maken.
Kost wel een dag per stuk om uit te proberen, maar dan weet ik aan het einde van de dag genoeg.

Als je een architectuur neerzet waar je als organisatie weer 5-10 jaar mee verder wilt, dan is een iets meer gedegen onderzoek denk ik wel op zijn plaats. De afgelopen 10 jaar hebben we prima gewerkt op een .NET architectuur en die kan ook nog wel even mee. Maar ik ben me aan het orienteren op een nieuwere architectuur, die beter schaalbaar is, maar waarbij ontwikkelaars wel op meerdere plekken ingezet kunnen worden.

Ik heb voor een klant een paar jaar geleden een web-applicatie neergezet met AngularJS v1.x. Werkt prima en leek toen een goede keuze, maar Angular v1.x is zo goed als EOL dus achteraf had ik liever React gekozen. Nu krijg je niemand meer die aan die applicatie wil werken, tenzij het volledig geporteerd wordt naar een nieuwere versie van AngularJS (en dat is echt een enorme klus).

Daarom gebruik ik liever een technologie die toekomstvast is, maar waarbij je ook enterprise-grade applicaties kunt ontwikkelen. In de huidige markt moet de technologie ook aanspreken om nieuwe medewerkers te kunnen binnenhalen. Probeer maar eens iemand te vinden die ASP.NET MVC wil programmeren met een jQuery Javascript front-end. Die willen allemaal wat nieuws, dus daar moet je ook rekening mee houden.

Graag hoor ik dan ook de mening van mensen die ook met deze problematiek bezig zijn en wat hun beweegredenen zijn om te kiezen (of juist nog even te wachten).

[418O2]

Waarom bouw je geen webapplicatie? Zie geen reden om het native te doen. Desnoods wrap je een electron app, lijkt het net een echte native applicatie.

[DJMaze]

BugBoy schreef op woensdag 4 juli 2018 @ 11:57:
Daarom gebruik ik liever een technologie die toekomstvast is, maar waarbij je ook enterprise-grade applicaties kunt ontwikkelen.

BugBoy schreef op woensdag 4 juli 2018 @ 11:57:
In de huidige markt moet de technologie ook aanspreken om nieuwe medewerkers te kunnen binnenhalen. Probeer maar eens iemand te vinden die ASP.NET MVC wil programmeren met een jQuery Javascript front-end. Die willen allemaal wat nieuws, dus daar moet je ook rekening mee houden.

Dit spreekt elkaar tegen om verschillende redenen.
Je geeft zelf al Angular als voorbeeld, maar zie ook Flash, SilverLight, .NET, Windows Phone, etc. etc.
Het is niet voor niks dat banken nu problemen hebben met het vinden van COBOL experts.

toekomstvast is een relatief begrip en als iets echt aanslaat zou zelfs C kunnen verdwijnen.
Kijk om je heen en zie hoeveel bedrijven wel niet met legacy spul rondhangen.

Om die reden krijgen ontwikkelaars van mij gewoon de vrijheid iets te maken in RAD wat minimaal 5 jaar mee kan en de kosten te drukken.
En de klant informeren dat het misschien vervangen moet worden na 5 jaar voor iets nieuws.

Ik ontwikkel een applicatie gewoon nog in Delphi/C/C++, maar al het "hippe" er omheen gebeurt gewoon in een taal die een ontwikkelaar leuk vindt.

[ Voor 5% gewijzigd door DJMaze op 04-07-2018 12:27 ]

[ETzPliskin]

418O2 schreef op woensdag 4 juli 2018 @ 12:03:
Waarom bouw je geen webapplicatie? Zie geen reden om het native te doen. Desnoods wrap je een electron app, lijkt het net een echte native applicatie.

Dit ging ik ook voorstellen. Een web applicatie ontwikkelen met je favoriete front-end framework (Angular/Vue/React), en electron gebruiken.