191–200 of 250 posts
Congrats Meteor! but I really find it loading a bazillion javascript files a bit of an overkill. Also debugging is a pain in the butt.
So last time I used this was back in August 2013. The main concerns we had was scalability and reliability. How does 1.0 address the previous concerns that was enough to abandon meteor.js altogether?
Congrats to the Meteor team! We've built an enterprise/b2b app on meteor, and even through all of the hard yards, it's been a success & the right choice for us. When I first heard about meteor, back at v0.5 or v0.6 - I watched the video from their home page, and thought it was full of buzzword bullshit. I didn't have a clue what it did. I then ended up reading about how their latency-compensation API system worked [M…
> * You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment]. What opportunities exist in the enterprise market that specifically benefits from this feature?
Low latency (real-time) can be an important part of effective and engaging communication.
Sure, it's not for everything; I wouldn't want my email communicating word by word to my recipients as I typed.
However, enterprises usually involve a lot of communication - with team members, stakeholders, and clients. - there are many opportunities to spice things up and make them more engaging & effective.
There's also the opportunity to instantly communicate non-prose - manipulating datasets, images, graphs and charts in real time.
Server side I have multiple choices that guarantee me heigh scalability, performance, and real time. Also the mongodb solo option, without sql is very restrictive.
Client side, there are great js frameworks like React, Ember and Angular that are great modular libraries.
Earlier quoted context omitted.
Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.
This is something that I've wrestled with when working with meteor, how do you execute privileged queries from the client? You can do a 'Meteor.call' to execute code on the server, but there is no way to shield the user from accessing the parameters used in the query. Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can t…
Earlier quoted context omitted.
You can ask it either way. seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?
For starters: 1. You can reuse your existing API, or choose the stack you're comfortable with (I prefer Python to Javascript and Postgres to Mongo) 2. They are being used in production by high traffic websites (Guardian and Instagram respectively), so they're more battle tested 3. Their press releases aren't loaded with buzzwords and hyperbole
* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.
* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...
* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.
* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.
Earlier quoted context omitted.
The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers . Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the…
Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.
You can only view & modify data on the client that has already been published.
Data that you don't publish / is server only, will remain so.
When the first release of meteor came out, I was really impressed by the product. The real time update of the web page with zero code was an amazing feature. Today why I need of Meter? Server side I have multiple choices that guarantee me heigh scalability, performance, and real time. Also the mongodb solo option, without sql is very restrictive. Client side, there are great js frameworks like React, Ember and Angula…
Most of our customer projects use "old school" sql and only a few nosql-databases.
Waiting for Version 2 ;-)
When the first release of meteor came out, I was really impressed by the product. The real time update of the web page with zero code was an amazing feature. Today why I need of Meter? Server side I have multiple choices that guarantee me heigh scalability, performance, and real time. Also the mongodb solo option, without sql is very restrictive. Client side, there are great js frameworks like React, Ember and Angula…
I hoped they change meteor and opened it to other databases. The mongodb only option was the reason for us to stop using meteor. Most of our customer projects use "old school" sql and only a few nosql-databases. Waiting for Version 2 ;-)
I think Meteor is a great concept because of their seven principles [3], which I haven't seen in any other framework. I haven't worked with Meteor yet but will start a project in short term which uses Meteor, so I'm very excited to see how this works out.
[1] https://trello.com/c/Gf6YxFp2/42-sql-support
When the first release of meteor came out, I was really impressed by the product. The real time update of the web page with zero code was an amazing feature. Today why I need of Meter? Server side I have multiple choices that guarantee me heigh scalability, performance, and real time. Also the mongodb solo option, without sql is very restrictive. Client side, there are great js frameworks like React, Ember and Angula…
I hoped they change meteor and opened it to other databases. The mongodb only option was the reason for us to stop using meteor. Most of our customer projects use "old school" sql and only a few nosql-databases. Waiting for Version 2 ;-)