21–30 of 45 posts
Earlier quoted context omitted.
Really impressive work, thank you. I intend taking an in-depth look later, but just at the moment I hope you'll indulge a more-or-less off topic question; What tool did you use to create the youtube demo on your blog ?
I used a Chrome extension - Screencastify ( https://www.screencastify.com/ )
There is a lot opinions on HNews that Meteor is too monolithic and it's bad: https://news.ycombinator.com/item?id=8772563 However, that kind of projects show the opposite. It is in fact very modular.
The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) t…
Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all documents owned by users in GROUP_A. This is a pretty typical scenario for management chain permissions, but when I've looked ad Meteor and similar solutions it wasn't an option (or incredibly difficult to implement).
Earlier quoted context omitted.
The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) t…
I think that Meteor is pretty awesome, but it isn't good for a lot of use cases out of the box... If you need really granular and flexible security around your models, the out of the box security isn't (or wasn't last I checked) good enough. Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all do…
You should take a look at the Roles package: https://github.com/alanning/meteor-roles
I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
Meteor is monolithic in that it forces your app to be structured in a particular way - It dictates how you should handle your data and how your scripts get loaded/bundled into your app. That said, I think it's much more flexible (and scalable - In a business sense) than a closed solutions like Firebase. I think Meteor is suitable for most projects and monolithic isn't always a bad thing - There is some negative stigm…
Earlier quoted context omitted.
Agreed. I think a lot of that is based on Meteor (understandably) pushing their entire stack. I've always been intrigued by their docs which state: By default all apps include the meteor-platform package. This automatically pulls in the packages that make up the core Meteor stack. If you want to build your own custom stack, just remove meteor-platform from your app and add back in whichever of the standard packages y…
True - even for DDP there are already a number of client libraries not strictly related to Meteor front-ends, as seen from http://meteorpedia.com/read/DDP_Clients
If i understand: - your UI is written in QML. - you are using Asteroid to turn DDP protocol messages into JS events? - are you then reactively changing the QML markup and asking QT to re-render your UI? I'm interested how this part works.
How granular is the reactive rendering, ie the whole page every update, or just changed components (like reactjs DOM diffing)?
Have you dealt with other client side things like routing and page changes, or is it currently content for QML widgets?
How far does QML allow native widgets like tab controls? Does a QML app end up just as janky as html5?
Did you look at just having a QT application that would talk DDP? I guess QML looks like json/markup so it's more appealing for porting an existing meteor app, and it's markup rather than code, but some mapping to QT would presumably give much more control?
How do you deal with client side logic? If QML is just a layout descriptor markup, if you need actual logic client side, how do you bridge between that and the meteor backend? I see Asteroid allows you to send data back and call Meteor.methods. Oh I see QML actually anticipates modules in JS: http://doc.qt.io/qt-5/qtquick-tutorials-samegame-samegame3-e... http://doc.qt.io/qt-5/qtqml-modules-topic.html
Does QML support a webview component? In which case you could also mix in some pages just as webviews if you didn't want to rewrite your whole app in QML? Then again only attractive if the QT webview component uses latest chrome renderer at an OS level, and no JS bridge was required back to your app... that would be like a turducken anti-pattern.
Overall very interesting, thanks for sharing!
Appcelerator... kind of sucks. But it's much better than HTML5. It performs much better than HTML5, but I find it very hard to write. There's just way too much quirkiness and hacks to make it work. The only thing I like about it is that it's written in JavaScript (but it would be fun to learn a new one).
How does QT compare in this regard?
Earlier quoted context omitted.
The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) t…
I think that Meteor is pretty awesome, but it isn't good for a lot of use cases out of the box... If you need really granular and flexible security around your models, the out of the box security isn't (or wasn't last I checked) good enough. Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all do…
Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection
Groups = new Mongo.Collection('groups');
There is a third Collection needed, documents.
Documents = new Mongo.Collection('documents');
To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array.
Documents.allow({
insert: function(userId, doc) {
// doc's owner must be one of logged in user's groups
return Meteor.user().groups.indexOf(doc.owner) > -1;
},
update: function(userId, doc, field, modifier) {
return Meteor.user().groups.indexOf(doc.owner) > -1;
}
}
Meteor.publish("documents", function() {
return Documents.find();
};This is really interesting. I use meteor for the web, but am frustrated with mobile html5 client clunkiness. If i understand: - your UI is written in QML. - you are using Asteroid to turn DDP protocol messages into JS events? - are you then reactively changing the QML markup and asking QT to re-render your UI? I'm interested how this part works. How granular is the reactive rendering, ie the whole page every update,…
In the example, I'm using models (think MVC) and updating that model, which then automagically updates the UI.
I'm not (yet) pushing the QML via Meteor, but that is the next logical step. Should the UI change (say, radioboxes instead of checkboxes), the plan is to do a diff and change altered components (this should be doable as QML's format is still close enough to JSON).
QML already has a decent set of controls (http://doc.qt.io/qt-5/qtquickcontrols-index.html) but I'm working on wrapping native components so there is full coverage of ALL components (this was actually one of my previous posts http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...)
Of course, you could write a C++ DDP lib (and on the long run, probably should, merely for the performance boost), but asteroid and JS just made a proof-of-concept that much easier to build.
QML is not just a layout descriptor - you can embed javascript in it. Think about QML as HTML written in JSON, but without the HTML implied semantics.
Still, JS could also be shuttled accross the DDP connection, and could be run or changed client-side, there is no difference between those and QML as I mentioned above, though this is also something planned-but-not-implemented-yet.
And finally - yes, QML has a webview component(http://doc-snapshot.qt-project.org/qt5-5.4/qtwebengine-qmlmo...)