Meteor and Qt • Hacker News Board

Re: Meteor and Qt

#31

Post by achipa » Tue, Dec 23, 2014, 10:23 AM UTC

antoniuschan99 wrote: post #28

My stack uses Appcelerator, Rails, and Meteor. 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?

Performance-wise Qt is quite good, but still comes up a bit short on the Widget quality and consistency side - this is where project like my native component-wrappers come in to the story (shameless plug - http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...). The good news is that you can still keep on the JSON/Javascript side for all of this, regardless of whether you use custom UIs, use Qt Quick Controls or something else.

Long story short - it's not quite an Appcelerator replacement just yet, but certainly keep an eye on it! :)

Re: Meteor and Qt

#32

Post by achipa » Tue, Dec 23, 2014, 10:35 AM UTC

adrianlmm wrote: post #16

achipa wrote: post #14

Earlier quoted context omitted.

That's certainly possible for the data part - but a lot harder for UI/code. With the method I'm using, you can actually push code AND UI to the client on the fly. As far as I know, that's a lot more difficult with Xamarin. Also, the licensing is a lot more flexible than with Xamarin and Qt does provide support for more platforms.

It looks attractive, but at these times, the client application can be easily be auto-updated, that's how all applications work, including those made by Google.

Just wondering - what auto-update mechanisms are we talking about when it comes to native apps?

Re: Meteor and Qt

#33

Post by uptownJimmy » Tue, Dec 23, 2014, 11:36 AM UTC

lourd wrote: post #29

tracker1 wrote: post #22

Earlier quoted context omitted.

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…

This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) 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'); Let's assume we want Users…

I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that I read on the subject says that NoSQL is simply not robust enough for doing anything more complicated than storing a list of names and email addresses for a simple user forum. That ain't gonna cut it for most apps.

Re: Meteor and Qt

#34

Post by Matthias247 » Tue, Dec 23, 2014, 12:01 PM UTC

If you want a higher-level cross-platform websocket layer between client and server you could also checkout WAMP (http://wamp.ws) as an alternative to DDP. You would need to implement some things on your own, but on the other hand it's more of an open standard and there are already multiple targets available.

Re: Meteor and Qt

#35

Post by achipa » Tue, Dec 23, 2014, 1:06 PM UTC

uptownJimmy wrote: post #33

lourd wrote: post #29

Earlier quoted context omitted.

This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) 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'); Let's assume we want Users…

I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that…

AFAIK The reactive part is not that easy to with Mysql et al - sure, you can hack around stored procedures, UDF and such, but it's far from being elegant. If you "think in SQL", then of course nosql seems to make everything difficult, but in reality, you're just taking back some of the logic and heavy lifting from the DB server in exchange for more freedom/scalability, which may or may not be something you want.

Re: Meteor and Qt

#36

Post by adrianlmm » Tue, Dec 23, 2014, 3:03 PM UTC

achipa wrote: post #32

adrianlmm wrote: post #16

Earlier quoted context omitted.

It looks attractive, but at these times, the client application can be easily be auto-updated, that's how all applications work, including those made by Google.

Just wondering - what auto-update mechanisms are we talking about when it comes to native apps?

In the case of Android, jsu uload the new version to Google Play and the applicatio will auto-update it self.

Re: Meteor and Qt

#37

Post by achipa » Tue, Dec 23, 2014, 5:12 PM UTC

adrianlmm wrote: post #36

achipa wrote: post #32

Earlier quoted context omitted.

Just wondering - what auto-update mechanisms are we talking about when it comes to native apps?

In the case of Android, jsu uload the new version to Google Play and the applicatio will auto-update it self.

This is not the same thing by a long shot - you cannot force a Google Play update, and that update will take hours or days to trickle down to the users. What we're talking about is that the application updates itself instantly, even WHILE RUNNING. The user needs to nothing, no "update your app" or "newer version available". I can literally add an option in the settings menu or change something in the app and it will immediately be reflected on ALL clients connected without touching the appstore.

Re: Meteor and Qt

#38

Post by achipa » Tue, Dec 23, 2014, 5:15 PM UTC

Matthias247 wrote: post #34

If you want a higher-level cross-platform websocket layer between client and server you could also checkout WAMP ( http://wamp.ws ) as an alternative to DDP. You would need to implement some things on your own, but on the other hand it's more of an open standard and there are already multiple targets available.

Looks nice - Meteor natively speaks DDP so it makes most sense to use when talking to Meteor, but for other back-ends I will certainly consider WAMP! (no reason why this principle could not be applied to other back-ends hooking into the same WS powered Qt front-end)

Re: Meteor and Qt

#39

Post by eatmyshorts » Tue, Dec 23, 2014, 8:02 PM UTC

uptownJimmy wrote: post #33

lourd wrote: post #29

Earlier quoted context omitted.

This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) 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'); Let's assume we want Users…

I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that…

Remember that Meteor only just reached v1.0. There still is much to come from the platform. Redis support is being implemented currently, and shows great promise: https://groups.google.com/forum/m/#!topic/meteor-core/Jl5Jt7... Several people are working to integrate standard SQL support, too: https://github.com/numtel/meteor-mysql http://www.lshift.net/blog/2013/02/25/live-updates-to-meteor...

It was a big concern at first for me, too. But the platform is so much fun to develop with I decided to start developing with it anyways. Seeing the pace at which things are developing with the platform, and knowing about these non-Mongo data store efforts, I am certain that this won't be a drawback for the platform for very long.

Re: Meteor and Qt

#40

Post by tracker1 » Tue, Dec 23, 2014, 8:14 PM UTC

primigenus wrote: post #23

tracker1 wrote: post #22

Earlier quoted context omitted.

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…

At a high level, what you're describing is pretty straightforward to implement. You just publish the data a user has access to read, and you use allow/deny rules to determine which they can write to. 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 inferi…

Cool... as I admitted it's been a long while since I've looked at implementations... last I looked, if you opened your Meteor server to the (html/web) client, the client could do nasty things to your backend database, or you had to implement some complicated and/or not very flexible permissions... I'm glad to see that this has changed.