Comments (18)
I don't think Grain needs JavaScript target for DOM access. I remember years ago there was talk from React team that React would have option to run in web worker that doesn't have DOM access and only code that would do DOM patching would run in main JS loop. My understanding is that they didn't implement it. But Grain or any Wasm app can use similar system. Example using something like morphdom https://github.com/patrick-steele-idem/morphdom that Elixir's LiveView is using. Wasm code will just send batch of DOM updates to JS.
from grain.
@spotandjake thanks - was just looking for new things to try, and found grain, but want to do dom stuff... I'll keep watching!
from grain.
4 years and a big nada so far. Given WASM doesn't support DOM manipulation (nor is it ever likely to) maybe you should drop DOM from your docs and stop misleading people.
from grain.
I put up a PR to remove the DOM doc page from the website. We obviously aren't trying to mislead anyoneโthis is a project we work on for fun in our spare time. As you can imagine, it's difficult to keep the docs up to date (in fact, this was the only page of the stdlib docs that isn't auto-generated and I completely forgot it was there).
Can we bind js like Rust does it?
We absolutely can. This is a great opportunity for a community package that doesn't necessarily have to be Grain specific.
All one needs to do is define a WIT DOM world and implement the JS side. Through the power of bindgen, we can have JS and Grain bindings for free. This wouldn't be terribly difficult, just a lot of work. Could have something basic working in under an hour, but doing the entire API is likely a full-time job.
from grain.
Looking forward to writing UI's with Grain.
from grain.
Would this communicate with DOM via JS for every query and mutation?
I think Grain, as a language, could be interesting for DOM work, if there was a JS backend - but I don't think that's on your roadmap anytime soon?
I would hope to see this moving more in the direction of Elm, Reason or Imba - more so than the direction of C# with Blazor. Imba is perhaps particularly interesting as a reference, since the language has some of the qualities of Grain, and also makes precise DOM updates without virtual DOM or diffing. Something like Sinuous or Solid might be interesting as references too, embracing reactivity and precise DOM updates with minimal complexity and overhead.
I'm not saying the language needs to come with a library or framework, necessarily (although this was probably key to Elm's relative succes) but it would be nice if it enabled the community to build those things. The DOM model is all about mutation, so there's no particular incentive to choose a language like Grain unless it somehow enables you to conceptualize of the DOM as immutable within the language.
And it needs to be able to compete with mainstream frameworks on performance, which I'm guessing isn't really feasible if it's happening from WASM via JS? I don't think there's any real advantage to having WASM drive a UI in terms of performance, probably the contrary - and there's almost definitely only drawbacks in terms of complexity and debugging. A JavaScript target is probably the only way to make a DOM library in Grain truly useful?
from grain.
@mindplay-dk there will never be a "js backend", just as there will never be an x86 backend. Those are not the goal of the language and you'd be better off finding a different language.
Reference types are already in the spec and the DOM stdlib will be implemented with them.
from grain.
Well, never say never. Even if a JS backend isn't on your roadmap, there's no saying the community won't do it - it happens to almost any language with some traction, sooner or later. JS looks like a much easier target than WASM. ๐
from grain.
I know you are rewriting the DOM module. I would like to make a suggestion. The site listed below is a good example of creating PWA's with Elm and Rust. I would like to suggest that Grain would be a good match for this type of use case to develop Desktop/Mobile/Web PWA's with a web assembly base as is the case shown. This could go far for those in need of multiplatform accessibility to software paradigms, without the complication of choosing a native platform framework and working within those complexities. I feel that Electron, Photon, etc. are the way to go and that the normal platform terminal will eventually end up being the web terminal anyway in the near future.
https://sindrejohansen.no/blog/willow/rust/elm/2018/11/16/willow-elm-in-rust.html
Anything simpler than this over complicated mess with .net would be great. Bolero and F# have the right concept but the programming framework is too complex for a normal maker/programmer to utilize efficiently in both the syntax reference structure and the pieces and parts that make up a solution file set.
https://fsbolero.io/docs/Elmish
Having one grain file and one generated run time file for the PWA would be ideal, or maybe two including a generated html file. I know this sounds overly simplified, but it could be done. Don't know if the manifest file would or could be generated in the same process or would need to be generated by hand.
from grain.
Just as a follow up, here is what can be done with Rust and Yew and web assembly. I think this is the way you would want to go.
https://yew.rs/getting-started/build-a-sample-app
from grain.
Not sure about the DOM specific progress, but I was browsing for a solution for something and came across something that I thought I would post to pass along maybe a solution that would give similar results graphically to having direct DOM access depending on the desired results of interaction with the browser. If all that is needed is interaction and GUI then this may be a good solution if converted to a grain module for compiling to wasm for js interactivity in a web page : https://github.com/flyover/imgui-js
from grain.
Isn't there also talk now of a standardized WASM API providing access to the DOM/BOM?
from grain.
Not sure about that, but there is a github project that is trying:
https://github.com/web-dom/web-dom
from grain.
I also saw this in the how did they do that category:
https://www.remobjects.com/elements/platforms/webassembly.aspx
from grain.
Not sure about that, but there is a github project that is trying: https://github.com/web-dom/web-dom
Or "was trying"? No updates in 3 years.
Looks pretty solid though - big โ for generating these from WebIDL, and for building a language-neutral module for all languages targeting WASM. I suppose you could build something more language-specific on top of that, if necessary - but just having the original WebIDL APIs made available should go a long way towards adoption, as these are the APIs front-end developers already know from the browser.
from grain.
Is this still being worked on?
from grain.
It's not actively being worked on I think we may be waiting for stuff.
from grain.
Can we bind js like Rust does it?
from grain.
Related Issues (20)
- Grainfmt: Comment lost when preceding a number HOT 1
- Formatter: Pun aliases when possible
- Formatter: Missing trailing comma on inline record fields
- Stdlib: Add `String.map` and `String.flatMap` functions HOT 2
- Formatter: disallow double-breaks on attributes
- Docs: Add variant docs to Json data structure
- Cleanup: Use graindoc `Markdown` lib in lsp
- Lsp: Provide context for `use XXX.*`
- stdlib: Add `input` function HOT 2
- language: look into overloading the `array[x]` syntax to support multiple number types.
- Rework: `toString` to use a buffer HOT 1
- Decrease initial memory pages to 1 HOT 3
- Implement LEB128 stdlib HOT 2
- stdlib: Add a `TOML` library
- stdlib/runtime: Implement a basic parsing library HOT 1
- Improve compilation of large list/array literals
- Redundant Operations in stdlib Set.intersect HOT 1
- Fix link to lexer in compiler walkthrough
- Installer not Working Windows HOT 3
- Memory leak on unused function calls
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grain.