These are chat archives for amelisa/amelisa

23rd
Apr 2016
Ilkka Huotari
@ile
Apr 23 2016 01:15
hey
I thought of doing racer + swarmjs but I guess I don't have to now? :)
Ilkka Huotari
@ile
Apr 23 2016 01:21
What CRDT library is this based on, @vmakhaev ? Or did you create your own? I guess you didn't use swarmjs directly?
Vladimir Makhaev
@vmakhaev
Apr 23 2016 05:23
@ile hi. The idea was to have queries for collections and general JSON CRDT data type with object, array, string, number operations, similar to Racer. These two things are quite different from what Swarm do (key-value with different data types as values) and made Amelisa go it's own way. Though we go separate ways, I'm in touch with Swarm team and we share ideas/knowledge.
Ilkka Huotari
@ile
Apr 23 2016 06:07
Ok. What is the difference with key-value and your approach? Is it just more complex queries or something else too?
Vladimir Makhaev
@vmakhaev
Apr 23 2016 07:37
@ile queries and, in general, having collections is a good way to separate document types. Right now there are discussions on how to add queries to Swarm. Thoughts are: distinguish somehow same data types in key-value, put their states to separate database with collections/queries (Mongo, SQL or something), make queries to grab document ids, subscribe data by ids from key-value storage. It's not so straightforward as it's done in Amelisa, where state and oplog are stored in same storage (this also makes implementation of offline queries very simple). But in Amelisa oplog and state are stored in same document. It's not a problem with object operations, where oplog cleanup itself and it's length will be about document fields count. But for other types (array, string, number) there is no way to cleanup oplog naturally, so we need to clean it based on date (ops older than 1 day, for example) or oplog length. In general, I think both approaches have it's own pros and cons. And probably Amelisa will adapt ideas from Swarm or vice versa in the future.
Right now main storage is Mongo, because it has rich and structural queries, but I'm also looking at RethinkDB because potentially it can be much more performant with query subscriptions, which is the main bottleneck for now as we see from Racer experience.
Vladimir Makhaev
@vmakhaev
Apr 23 2016 07:43
Also I want to add GraphQL, because it's popular and there is a lot of hype around it. :-) I see two advantages from it, compared to doc/query subscriptions: relations and computed values.
And there are plans to create plugable rich text data types for Draft, Quill and others
There is proof of concept integration with Ember https://github.com/amelisa/ember-amelisa, which is not usable right now, but I would like to accomplish it and create similar for Angular. Right now there are React and React Native build-in integrations.
Ilkka Huotari
@ile
Apr 23 2016 07:51
Right, ok, thanks for the explanation on the internals. If I may ask, did you create this CRDT implementation from scratch, or where did you find it? Because I assume it would be quite a lot of work to do a working CRDT. I believe Swarm has been on the works for a few years now.
And this was CmRDT, not exactly CRDT?
This message was deleted
(I didn't post that screenshot. Someone used the computer, who doesn't quite yet know how to type....)
Vladimir Makhaev
@vmakhaev
Apr 23 2016 07:56
@ile as a basis for object type I took what was called Model type (key-value) in Swarm 0.3. That was starting point and other types where implemented based on ideas from everything that I could find about CRDT on the web :-)
Ilkka Huotari
@ile
Apr 23 2016 07:56
Ok, cool.
Hmm, one thing I noticed was that npm install took quite a long time. Do you know what's with that? Can it be speeded up somehow?
I mean with amelisa-crud-example and amelisa itself too I guess
Vladimir Makhaev
@vmakhaev
Apr 23 2016 08:04
mongo driver, redis driver and phantom from dev deps probably
Ilkka Huotari
@ile
Apr 23 2016 08:04
It took like 20-30 minutes... Wonder if it's just my setup or does it take that long usually?
oh if it compiles phantom, then it probably does take that long
So this comes with phantom? What is it used for?
Vladimir Makhaev
@vmakhaev
Apr 23 2016 08:09
Is should take couple of minutes anyway. Probably something on your side. How long does it takes for other projects?
Phantom is used for integration tests, it's not required when you use library
I tried, It takes 6 min for me
Ilkka Huotari
@ile
Apr 23 2016 08:19
I didn't find Phantom there in node_modules, but maybe it has something to do with Babel?
i'll try again doing the install...
Ilkka Huotari
@ile
Apr 23 2016 08:26
oh, now I remember that it also gave this error message: npm ERR! Maximum call stack size exceeded
I'm using node 5.11.0 and npm 3.8.6 ... the latest I think
Maybe I'm running out of memory and it's swapping
Vladimir Makhaev
@vmakhaev
Apr 23 2016 08:31
Maybe. I use node 5.6.0 and npm 3.8.7 and it works fine
it does not install phantom in amelisa-crud-example, because it's in amelisa's devDependancies
Ilkka Huotari
@ile
Apr 23 2016 08:32
Ok
Ilkka Huotari
@ile
Apr 23 2016 09:19
I added more memory to the virtual machine (total 4.5 GB), and more processors (total 2), but it still took 20 minutes... And ended with this: https://gist.github.com/ile/a0274c94197124db99b3d085f9ba1a00
usually npm install takes just a minute or two
It does take 100% of CPU i think though
Vladimir Makhaev
@vmakhaev
Apr 23 2016 09:26
try to npm install another project on your virtual machine or try to install amelisa-crud-example on your local machine
Ilkka Huotari
@ile
Apr 23 2016 09:29
I think it may be because of the Windows filesystem that I'm using on Linux... :)
Vladimir Makhaev
@vmakhaev
Apr 23 2016 09:40
yes, probably :-)
Ilkka Huotari
@ile
Apr 23 2016 09:55
Yes, that was it. Well, it still took maybe 8 minutes, but no errors... a big improvement
This virtualbox can use the Windows filesystem under Linux but it's a "little" shaky
Curran Kelleher
@curran
Apr 23 2016 11:14
Amelisa looks like an awesome initiative. I'm starting a new project on Derby, but will be watching Amelisa with interest. Would much prefer to use React and modern ideas, but Derby seems quite stable.
Ilkka Huotari
@ile
Apr 23 2016 11:37
How about the server side rendering? Is that coming in the future? If I disable JavaScript, it doesn't seem to render on the server side now?
Vladimir Makhaev
@vmakhaev
Apr 23 2016 11:41
@curran thanks, I'm happy for any feedback
@ile it's implemented on basic level, but in amelisa-crud-example it disabled by https://github.com/amelisa/amelisa-crud-example/blob/master/app/pages/Root.jsx#L15
you can find more on this, if scroll down here http://amelisajs.com/docs/react
Ilkka Huotari
@ile
Apr 23 2016 13:16
Ok.
Ilkka Huotari
@ile
Apr 23 2016 16:28
I'm trying to figure out why I should be happy to use React and I'm not yet seeing it... I read this: http://firstdoit.com/react-1/ ... but I'm still in this first phase "Hurry! Kill it with fire!"
Are you sure it's good? Derby's components seem pretty good to me, I like that the templates are in their own files and code in their own. Are you seeing advantages with having everything in the same file?
Also I'm not sure there will be any performance improvements? Can you really optimize those model bindings?
Vladimir Makhaev
@vmakhaev
Apr 23 2016 18:16
Personally I like React's view more than Derby's. It's very simple, declarative and does not have any DSL. If you like templates, just use frameworks with templates.
Vladimir Makhaev
@vmakhaev
Apr 23 2016 18:23
What about performance, in some scenarios Derby's view is better (like tables with thousands cells), because Derby create binding for particular dom elements and React tries to rerender everything every time. But in most cases you will not notice any difference.
Pavel Zhukov
@cray0000
Apr 23 2016 18:24
and React is the only thing which can do native mobile with JS, which is also very powerful
we use both React and Derby.js and none of them are the magic bullet
Pavel Zhukov
@cray0000
Apr 23 2016 18:29
you still have to optimize the project really well to get a good performance
both on React and on Derby
and the difficulties to optimize it are pretty much the same
Derby's templating engine still has bugs, for example the template attributes are not working properly, you can't pass expression's results into the component's model, instead you just get a ParentWrapper and you can't do model.on() on it. And over all attributes in Derby work on the level of View but a lot of useful features are only available on the level of Model -- model.on(), model.start() and there is no direct connection between those View-variables and Model-variables
Pavel Zhukov
@cray0000
Apr 23 2016 18:34
on the other hand React has stateless components and doesn't have any DSL -- writing templates in JS allows more flexibility
but since React is stateless, binding stuff is difficult compared to Derby
2-way binding
Pavel Zhukov
@cray0000
Apr 23 2016 18:42
so my personal opinion is that for projects with heavy collaboration (and overall with some kind of a stream of frequent small updates going on constantly) Derby is better. For projects where collaboration are not required and for projects where you also need to create a native mobile experience -- React is better
in the end it all depends on the project and on the skill of the team
and React is obviously much easier to start with since it has a much wider usage and support and a lot of components are already written for it -- for web usage and for react-native usage.
Ilkka Huotari
@ile
Apr 23 2016 19:45
Yes, true, I can see those benefits of it having more ready made components and react-native being there.
And I have too seen the ParentWrapper when I didn't need it.
Not sure what you mean by DSL though? "React doesn't have DSL", what do you mean?
Pavel Zhukov
@cray0000
Apr 23 2016 19:47
no specific templating language
Ilkka Huotari
@ile
Apr 23 2016 19:47
Ok yes
Pavel Zhukov
@cray0000
Apr 23 2016 19:47
in react you can move html into a separate js function and execute that function inside another function which generates html
Ilkka Huotari
@ile
Apr 23 2016 19:49
right. well one thing is that all this JSX looks messy, would be better to have some more clarity. a lot of "boilerplate". i suppose it can be arranged then to look clearer.
Pavel Zhukov
@cray0000
Apr 23 2016 19:50
In Derby the situation is that we have HTML with some part of JS -- inside bindings we can use JS expressions, but can't write functions.
In React it's the opposite -- you write HTML inside of JS, with full features of JS available to you inside HTML
yeah, JSX breaks the established MVVM pattern
it's one big file with the whole MVVM inside
but it's more of a holywar topic whether it's right or wrong, too many opposite opinions on that one
Ilkka Huotari
@ile
Apr 23 2016 19:53
yes... and I believe people moved from code + templates to separated code / templates for some reason :)
Pavel Zhukov
@cray0000
Apr 23 2016 19:54
yes, I don't like having html inside of js in one file either, but a lot of people say that it's actually fine when you start writing a lot of small components on React
Ilkka Huotari
@ile
Apr 23 2016 19:55
but i don't have a strong opinion on it, as i haven't used it yet, so this is just thinking out loud
ok
Pavel Zhukov
@cray0000
Apr 23 2016 19:55
the whole point of React is having a lot of small components
if you have a big component more then 100 lines with mixed html and js then obviously it becomes a mess
Ilkka Huotari
@ile
Apr 23 2016 19:56
right. i have some big derby templates that i got scared of when thinking about them in React
Pavel Zhukov
@cray0000
Apr 23 2016 19:56
if everything is divided on small components less then 100 lines then having JS and HTML in one place doesn't look so messy
Ilkka Huotari
@ile
Apr 23 2016 19:57
yes
Pavel Zhukov
@cray0000
Apr 23 2016 19:59
probably writing some complicated app with a lot of interactions between components is harder in React since you need to divide everything on components right away, while in Derby you can afford to write some big scary component and divide it on smaller components later on when you are doing refactoring
but I don't know whether it's good or bad, maybe thinking ahead about the components size and writing components to be small right away is a good disciplinary measure
and keeps the code simple if you follow that rule from the beginning, even though it's harder to follow that rule all the time.
another problem with vanilla derby is subcomponents which are simply non-existant
and there are no guidelines on writing components in Derby
Ilkka Huotari
@ile
Apr 23 2016 20:03
i don't know if i could split that big component into smaller ones, it just has some html that "blowed up" with a lot of if/elses... so it's hard to break up i think
Pavel Zhukov
@cray0000
Apr 23 2016 20:04
though the subcomponents issue was addressed by @cjblomqvist in https://github.com/BBWeb/derby-ar
sorry, not derby-ar, that project solves the absence of Active Record pattern in Racer
and having subcomponents with the ability to require a component inside another component makes it much easier to divide everything into smaller components in Derby
Pavel Zhukov
@cray0000
Apr 23 2016 20:09
actually we should be having this discussion of React vs Derby in the derby.js gitter channel. This channel is for holywars between Amelisa and Sharejs and overall CRDT vs OT :)
Ilkka Huotari
@ile
Apr 23 2016 20:15
this subcomponents stuff looks good. i guess it just adds a few lines into the derby internals and so adds this new feature
Pavel Zhukov
@cray0000
Apr 23 2016 20:16
yup
Ilkka Huotari
@ile
Apr 23 2016 20:16
i thought of having this war here, i didn't want to "pollute" the official derby channel :)
Pavel Zhukov
@cray0000
Apr 23 2016 20:17
actually Lever doesn't do office hours anymore
it would be great to gather together some time
like we did before on office hours
and discuss everything around derby, racer, sharedb, amelisa, react
Ilkka Huotari
@ile
Apr 23 2016 20:20
well pluggable view modules would be a nice feature for derby, i suppose... but Amelisa probably has that. do you see switching totally over to Amelisa at some point?
Pavel Zhukov
@cray0000
Apr 23 2016 20:21
it's going to be difficult to switch to Amelisa since it doesn't support JSON type fully
it operates on a document level
but eventually Amelisa will support all types and at that point Sharedb and Amelisa will be compatible with each other
and Amelisa is already preferable in mobile-oriented applications where offline usage is required
and we tested Amelisa in a production application already
Ilkka Huotari
@ile
Apr 23 2016 20:25
hmm, what doesn't it support now? it does support boolean, numbers, strings, arrays i guess?
Pavel Zhukov
@cray0000
Apr 23 2016 20:26
so it's ready for the prime time
Ilkka Huotari
@ile
Apr 23 2016 20:26
good to hear
Pavel Zhukov
@cray0000
Apr 23 2016 20:26
it supports all of it but the operations happen on the document level
Ilkka Huotari
@ile
Apr 23 2016 20:28
but it supports nested objects too? http://amelisajs.com/docs/setters ... so what does that mean, that it operates on the document level..?
Pavel Zhukov
@cray0000
Apr 23 2016 20:33
well, all the main operations are supported, but I'm not sure whether it tries to actually resolve the concurrent operations on nested paths of boolean, number, array. Maybe @vmakhaev already added full support for all operations, it's a question for him.
Ilkka Huotari
@ile
Apr 23 2016 20:36
ok ... one thing is that what types of arrays are supported.. is it arrays of numbers, strings, booleans and even arbitrary objects. question again for @vmakhaev
i have been wanting offline usage for derby for a long time so this is definitely a good improvement
Pavel Zhukov
@cray0000
Apr 23 2016 20:39
yup
Vladimir Makhaev
@vmakhaev
Apr 23 2016 21:04
@cray0000 @ile it supports operations on following data types: object, array, string, number, boolean. Object can have any data type as field values, including object and array. Array can have any data type as item, including object and array. So it can be nested structure like for example, array of arrays of objects. And Amelisa resolves concurrent operations on data types, located on any level of this nested structure.
For example, if one user moves object in array and another user changes object's field at the same time, it will be resolved.
Pavel Zhukov
@cray0000
Apr 23 2016 21:07
@vmakhaev cool, so basically on the current level of development Amelisa is already a full-featured alternative to Racer, right?
Ilkka Huotari
@ile
Apr 23 2016 21:37
:clap: :+1: