Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Areas needing attention #1

Open
8 tasks
anowell opened this issue Feb 13, 2017 · 0 comments
Open
8 tasks

Areas needing attention #1

anowell opened this issue Feb 13, 2017 · 0 comments

Comments

@anowell
Copy link
Owner

anowell commented Feb 13, 2017

There are lots of areas that need plenty of thought, discussion, and possibly contributors. These need broken out into separate issues (please do open an issue to discuss one of these deeper). This issue serves as a high-level summary:

  • Routing - what's it look like to implement SPA routing on top of quasar? Is this built-in, or does quasar just provide a flexible set of primitives so that other crates can implement routing?
  • Lifecycle management- When should component data, app state, or even DOM elements get dropped/destroyed? Currently all of these live for the entire duration of the app, and the underlying webplatform makes things worse by growing an array of node elements indefinitely (e.g. every event appends an element to it).
  • DOM/JS interop - Quasar needs some deeper thought into how it interop the DOM and JS. This includes increasing the quasar's surface area to expose more DOM/JS functionality. It also includes thinking deeper about rendering. The current use of morphdom.js is probably temporary, and DOM patching in general needs more thought given to updating state of form elements. More generally, quasar might be better served by an alternative to rust-webplatform. Longer term, a future WASM DOM is probably a better story.
  • HTTP - Can we get HTTP client libraries like reqwest to target emscripten (e.g. perhaps the Fetch API)
  • Isomorphic - What's it look like to integrate Quasar with Rocket, Iron, etc? What patterns will lead to effective sharing of rendering code between the client and server?
  • JS Alternatives - Identify or create crates which could serve as alternatives to common JS libraries. (e.g. syntect could be a highlight.js alternative once it can target emscripten)
  • Demos - Quasar is probably a ways from real usage, so demos are currently guiding it's design and implementation. more substantial demos, isomorphic demos, perf demos, demos for specific crates in the browser, demos with different templating. A Quasar Demo gallery could be sweet.
  • Other projects that benefit Rust's emscripten ecosystem in general? cargo-web is nice but still super early. domafic is another frontend framework for those more interested in Elm/Redux architecture? Perhaps we need something like an "Are We Frontend Yet?" to keep track of the moving pieces in this ecosystem?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant