Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Discussion: Template Simplification #269
I wanted to open this as a discussion point for the next "big issue" we see affecting the SAFE template: the increasing cost and complexity of maintaining it. This affects the project in a number of ways:
As such, this issue is going to form the basis of a discussion of ways to remove, or at least reduce, the friction on the template. My thoughts are that the sheer number of dimensions on the template is the biggest pain:
This is only going to get worse in the future, so here are some ideas that we've tentatively been discussing around this:
1. Cut features
Simply remove some features from the stack that present wins in terms of cost / benefit. Primary candidates are Suave and Fulma themes.
The idea here is that instead of the template itself containing all the code for Azure, GCP, Docker etc., they would become dependencies in some way e.g. NuGet packages or simply GItHub files that can be pulled in by Paket.
Coupling to the Template
We can look at this as a way that whilst the template wouldn't contain the code for the dependencies e.g. Azure, it would still contain the list of e.g. Cloud services in the template options. The template would still have to "pre-generate" the paket dependencies files etc., but they could at least be developed and improved "out of band" of the template itself. We might have to create some kind of common interface that all similar services adhere to in order to incorporate at least the "plug point" into the template e.g. in the FAKE script, if the user chooses Azure, the generated FAKE script would have to know what information the Azure deployment module needed and what the signature looked like etc.
Decoupling from the template
An alternative is to look at something more ambitious and consider either a dotnet tool or similar which is an application that can be run and make in-place modifications to a (freshly-created) SAFE application to add the appropriate features in. For example, someone wanting to add Azure support to the SAFE template would first generate a normal, clean SAFE template (which would not have any options for platform etc.). Then, as a second step, they would run the SAFE tool e.g.
FWIW I think a combination of both options should be used. Firstly, removal of both the options as outlined in (1) should be done in the near future. This can be achieved quickly and easily (e.g. this experimental branch removes both and largely simplifies the codebase). Second, a number of prototypes should be developed to explore option 2.
Thoughts? Ideas? Criticisms? All welcome - let's get some thoughts and feedback going.
For me removing the different layout option for Fulma is a good thing. The different layout we currently have don't really add value to the template.
Most of the time, you just want to know that it's do-able and then build your own layout step by step.
If we include Bulma using
As an example, in Fulma I only provide a really minimal version of the template so people can quickly own the code. There is only one "small" view function which still provide a "clean" first user look.
And if they want to see what Fulma is capable of, then I point them to Fulma demo which is a more ambitious project.
My last example made me rethink about this issue #172
I am not sure if we want or can give it a second look. But I though it made sense to point it out. In. the sense that we could choose/rethink which example better serve the SAFE stack and interaction between the server/client (or is easier to understand).
For example, asking the server to increase a value rarely happen in real world. But asking the server to modify a value is much more common scenario.
I strongly support removing complexity and some options from template. One of the ideas behind SAFE is pushing users into right direction (which fits into F# Pit of Success philosophy), and I think too many options is against this goal - it adds confusion and cognitive overload, users shouldn't need to study all possible options to make decision.
I think I've mentioned something like that ages ago ;-) Again, I'd strongly support such option - this is what popular JS frameworks do. It turns out generic template engines like
Indeed layout options seem to be the lowest hanging fruit here.
Hence I suggest to create a repository per each fulma layout currently in layout options (hero, admin, landing, etc..) - the repositories could be e.g. under https://github.com/Fulma org?
I'd leave "none" and "fulma-basic" options for now, since I believe at some point we could add basic materialUI or antD fable bindings
If we host them under Fulma repo, I will probably strip then from all the SAFE Stack part. They will probably be like the Fulma-demo, just showcase application that are available online and which try to provide an interactive sample.
@theimowski isn't that just going to be more to maintain? I'd rather just point people to themes (there are others as well e.g. Bulmaswatch which I've used in the SAFE Search app and it worked just great.
Regarding materialUI / antD - I'd be up for stripping it out completely and adding back in if / when that happens - we've been planning those for a while but they're not high priority at the moment really.
Yes, that's what I had in mind
@isaacabraham IMO there's a value in having working examples of various layouts. It shouldn't be hard to maintain also as the only dependency there is Fulma.
There's also value in having option of excluding Fulma from SAFE template - e.g. for https://github.com/theimowski/SAFE-TodoMVC I used
Talking about Material UI and Ant D I didn't mean we should add them now, but rather that we should design possible options so that it is easier to add them in future.
To sum up, I propose following changes to layout options:
First draft here: https://github.com/theimowski/fulma-demo/tree/fulma-layouts
I think there is significant benefit in having v2 as a refactor release with a more prescriptive means of developing full stack applications with F#, this would include removal of Suave, removal of Fulma templates (potentially with an expansion of the scss file to include description of how to use different templates and variables in there). I'd also be inclined to go as far as removing libraries like Reaction and Remoting to start with as well as the Azure services components. But I think there's significant value in keeping the different deployment options in place, especially if we can keep them there without needing to modify the application itself.
Then once we've got this, we should look at what new features we could start to add in V3 which could grow the SAFE ecosystem
Currently following workflows are allowed:
Build and run using SAFE Tool
This builds / runs the application just by using the tool, in fact
Add a feature to SAFE project
This creates a
Build and run docker
This will respectively build a docker image and run SAFE in docker container - note you need to have docker enabled to do that, otherwise the tool will tell you it's disabled
Disables docker for the project
IMHO a custom cli tool like the above is the way to go. For me as a user it is not helpful to have plenty options when beginning with SAFE. I like the possibility to add further things like deployment setups later. Also updates to a new version of SAFE could be achieved more easily (how often this happens for an application, I do not know to be honest).