Great discussion, I have been following and waiting for a bit of spare time to dive in to this. Iāve grabbed the key concepts being discussed and adding my 2c for each.
Domains and breaking up into SPA sized pieces
The domains as discussed are pretty big, and probably beyond a single SPA. If we wanted to go the SPA route then some of these domains would be broken up further. To me a SPA is good for a cohesive single UX, something that a user would consider a single job. This is because a lot of the benefits of SPAs are needed in those UX cases. Think things like seamless back and forth between steps in a workflow, allowing things like undo and autosave or options of different non linear approaches to workflows - the user can do things in a way they want.
SPAs (along with APIs) are also good for discrete development, which can make the open source community contributions easier to get set up and do, You may not need to install the whole OFN ecosystem, especially if a staging API can be used and you are just doing front end changes. I think this is particularly good for short term open source contributors, such as hacktoberfest or new coders looking to get some experience.
Choosing safely for the future
This is tough, rally tough. Itās now 2020 and weāre talking about changing from a tech choice made in 2012, thatās a lot of pressure to make the right choice until another chance comes along.
I have used React, Vue, AngularJS (ages ago, although the memories are now flooding back) but have never used Angular.
I lean towards React in terms of future safety as, itās been around longer than Vue, and probably has better docs/vested interests than Angular. I also know that React is very cleanly isolated, it works with a lot of other things whereas I found Vue to be a bit opinionated (much like AngularJS) which concerns me as it makes modifying parts very difficult, you are always locked in to changing the whole.
Now part of this could just be the architectures Iāve seen - it is probably quite possible to have a well separated front end architecture, that is open to extension/change in all 3 of the ecosystems we are looking at.
Iām a big fan of this testing library that has been adapted to all 3 frameworks. This along with tools like Storybook that also work across ecosystems give me confidence that it is possible to create clean, well-isolated front end components, mini and major SPAs with all 3.
Encouraging community involvement
As I touched on in the SPA section, good architecture and ease of dev experience in setting up is key here. Again I think this is possible to be done well with all three. Thinking about the profile of community contributors may help here, are they wedded to a particular framework? Or are they keen to try new things? This may give us different answers than looking at the overall trends. @lin_d_hop are you a good person to ask about the people who have volunteered contributions? Of course past experience may not predict the future so this may be hard to figure out.
Server side rendering (rendered template views)
This is an interesting discussion - there is definitely a bit of a turning back time to before the SPA era that Iāve seen, and itās a fair point - what was so bad about simple rails/django/laravel/.NET rendered views !
Well I guess the main thing is what I mentioned in the SPA section, those āapp-likeā UX features that SPAs really help with. However I wonder how much is really ānot possibleā with routes rendering forms that POST. Iād also shout out here that the Tailwind atomic CSS library and component set is pretty damned good, allowing pretty nice UI in simple html templates. We used it with Alpine which is a very light touch way of adding interactivity to straight HTML (a bit like Stimulus perhaps @sauloperez)
In case Iāve missed the point of this section entirely, I should also mention NextJs - server side rendering of react, with a bonus of data retrieval as part of the render. This is a nice use of react that Iāve experienced which really helps with performance, which is something to think about if the growth in OFN audience is towards more low bandwidth users.
Component libraries
Iād definitely be very wary of a component library as a big time saver/silver bullet for one task that then gets used everywhere, or dictates a tech choice. I had the misfortune to work with ExtJS for a few years, primarily because people were wowed with the component set. Apart from the perf issues as the library bloated, it was the customisations that really killed us. Must have features were often very hard to do as customisations. I lean towards using more atomic components that can be built up to something complex, or that give you the option of doing a large bit of custom work when needed.
Caveat - ExtJS was just bad in many ways so this may just be my scar tissue showing.
OFN API
This is great that the discussion has pulled in the API as well, as I agree it is super important to make it a core part of the work (dogfooding as @luisramos0 said). Iāve loved this approach ever since Flickr did it back in 2005, itās just a no brainer that this is how you get a good API and Iād argue a better app experience.
I say a better App is likely because I think that API/separate front end just gives you more options, more deployment options, more customised curation of workflows that we havenāt thought of yet - a flatly designed API is a good hedge against a beautiful domain structure being thwarted by reality coming in and blurring the divisions youāve created. Whereas Iām not familiar with but suspect from my experience with other MVC backends that rails engines and server rendered views may be more work to adapt to something wild that crosses the sensible boundaries that have been created.
My experience
Iāve used React quite a lot, and have found it quite easy to onboard non JS devs and get them productive quickly and enjoying itā¦ āOh, itās just a simple state machineā it still one of my fave comments from a backend dev 2 days into using React.
I also want to fly the flag for TypeScript here - Iāve found TypeScript much easier to use with React than withā¦
ā¦Vue, which I used last year. It was an inherited project and there was a bit of cleanup to do so not the best starting point. As part of that cleanup I introduced TypeScript to get a hold on the complex data model and untested code. I donāt think Vue and TS were a great combo. However I believe that Vue 3 has much better TS support. I can see the appeal of Vue, but I was a bit thrown by some of the magic/convenience. Iād say itās a bit slower to onboard to Vue than React but Vue is faster (less boilerplatey) once you know what you are doing.
Wouldnāt the frontend benefit as well from being split into domains? I wonder if thereās a way to gradually migrate to an up-to-date framework, whichever.
)
