Discussion: Using a web framework

[marcelklehr]

While magpieInit with its declarative configuration is probably quite simple and elegant to use, things seem to get out of hand pretty quickly when you need to create a custom view.

In order to simplify this, we could make use of a component-based web framework. These frameworks usually have good conventions and simple interfaces for rendering views as well as updating and managing state, that still allow building complex functionality without losing yourself in the code.

A drawback of using a framework would be that users of this library would be tied to that framework, too, and would most probably be required to run a build step -- as is customary nowadays in the world of javascript, in order to make use of advanced features like js modules.

If we choose to use a framework, the rub often lies in the particular choice. I'm not too particular about a specific choice, although I have made good experiences with both React and Vue.js. React seems to have a steeper learning curve, especially nowadays, while Vue.js usually lends itself to all kinds of environments quite naturally and can be adopted incrementally.

Ease of use might indeed have been the reason that you initially chose to avoid frameworks and using a framework would probably require a significant amount of refactoring, but I think it would be well worth the effort for the increased extensibility as well as maintainability.

[x-ji]

I've been thinking about something similar recently. Probably it would have been a right decision to start with a framework from the beginning. I wasn't much involved in the frontend part of _magpie, though seems to me the current way the code is organized is frankly speaking a bit out of control. The project could use some major refactoring.

Vue would be a good choice IMO. It's the most lightweight and flexible, and it can be added progressively to a project.

[michael-franke]

I had also though (a while back already) about using something like React. I am unfamiliar with Vue.js. Such a move would be great it makes designing views with more elaborate timings of events more streamlined. If such a component-based framework would also help making the creation of interactive/dynamic experiments easier, that would be a strong argument in favor.

…

On 24. Apr 2020, at 22:23, Xiang Ji ***@***.***> wrote: I've been thinking about something similar recently. Probably it would have been a right decision to start with a framework from the beginning. The current way the code is organized is frankly speaking not so nice. The project could use some major refactoring. Vue would be a good choice IMO. It's the most lightweight and flexible, and it can be added progressively to a project. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[x-ji]

Yeah I remember you suggesting React in the beginning and Stella and I saying that it might end up being too complex, requiring preprocessors etc., and scaring people off 😅. However, a JS project quickly goes out of control when there's not an underlying framework to help organize things, especially when we want to realize something relatively complex such as interactive/dynamic experiments. In our current instructions we ask people to use npm already anyways, so using a framework wouldn't really add much to the setup complexity.

I heard that @marcelklehr is going to join as an RA on this project, which is great, since you apparently have extensive frontend development experience already. I am more of a backend (Elixir) developer, though I do write from time to time some Vue code on my current job. I'm also trying to start a side project probably with Vue. Therefore I'm more familiar with Vue than React.

Though my suggestion came only from the perspective of my (somewhat limited) knowledge of those frameworks. If we want to go for something more extreme we could also use stuffs like Elm 😄, which claims to produce almost no runtime errors whatsoever due to the guarantees offered by it being a statically typed functional language; it also provides a timetraveling debugger. I just felt that, pragmatically, Vue would be the most lightweight and beginner-friendly approach, especially if other users who might not have a background in coding also want to add their own experiments.

We could discuss the approach to adopt going forward in a call. I also just emailed Michael yesterday about the next steps on the project, before Marcel opened the issue. Maybe we could agree on a timeslot via email.

[marcelklehr]

I heard that @marcelklehr is going to join as an RA on this project.

Indeed, I'm sorry for the cold issue opening without an intro :) I'm happy to work with you all! :)

I just felt that, pragmatically, Vue would be the most lightweight and beginner-friendly approach, especially if other users who might not have a background in coding also want to add their own experiments.

I tend to agree. I'm currently working with Vue on nextcloud and with React on a different side project and am impressed by how ergonomic and intuitive it feels to use Vue, while the latest updates in React seem to have heavily sacrificed usability in favor of purity with their pure-functional approach.

like Elm, which claims to produce almost no runtime errors whatsoever due to the guarantees offered by it being a statically typed functional language; it also provides a timetraveling debugger.

Static typing could be worth having, indeed, as long as it's not too much of a burden on beginners -- I'm uncertain on that. TypeScript would be a natural fit for that, here, I think. Oh, and Vue also has a plugin called "VueX" which provides a functional data store with timetravelling 😍 -- if we should need that 😄

Maybe we could agree on a timeslot via email.

👍 I'm available most days in the afternoon.