objectbox-dart
objectbox-dart copied to clipboard
objectbox
Web support vol.2
Part of #185
- adds objectbox-javascript library stub
- adds a test file that can be run in the browser
- evaluates dart vs JS-interop call performance
TODO:
- [ ] Add a simple IndexedDB performance evaluation, comparing
- [ ] dart:indexed_db vs JS IndexedDB
- [ ] storing objects vs storing strings (a.k.a. flatbuffers data), ideally strings should be real flabuffers to also evaluate FB serialization cost in the browser
- [ ] check how generic classes are handled by
webpack& dart-js code interop (including generator)
Eagerly awaiting web support. Would be great to see the package with all platform support on pub dev.
What is the current progress? The last commit is nearly half a year ago. Is there any obstacle? What can I help with?
@vaind Did you have any initial perf results yet?
We go with TypeScript, right? For web, I would even go forward with TypeScript if it would be significant slower that some Dart only thing (which seems quite unlikely unless there's some Dart quirk), so would not spent more time on Dart vs TS perf tests.
The scope of this PR should be a minimal Box APIs working; i.e. Box TypeScript API using IndexDB wrapped by Dart. Right?
Update: deferred the target architecture discussion to here.
@vaind Did you have any initial perf results yet?
no, these TODOs are up to date
We go with TypeScript, right? For web, I would even go forward with TypeScript if it would be significant slower that some Dart only thing (which seems quite unlikely unless there's some Dart quirk), so would not spent more time on Dart vs TS perf tests.
Looks like dart (compiled to javascript) may end up being faster than plain javascript:
https://github.com/dart-lang/sdk/issues/38705#issuecomment-573960765 Dart version, dart2js compiled -O4: 29ms JavaScript version: 44ms
So it's not a clear decision (from the performance perspective) unless a small benchmark is created.
So it's not a clear decision (from the performance perspective) unless a small benchmark is created.
No need. As I've mentioned before, the decision about the tech stack is not primarily about nuances of JS performance.
So it's not a clear decision (from the performance perspective) unless a small benchmark is created.
No need. As I've mentioned before, the decision about the tech stack is not primarily about nuances of JS performance.
Yes, in that case I agree TS might more useful (for future reuse) albeit a bit harder to implement than plain-dart solution
