[amelius]

I'm looking for a toolbox that can give me:

1. client-side (javascript) database access

2. automatic updates to the client's view of the database

And also:

3. automatic optimal re-execution of javascript code whenever something changes in the input (e.g., the database). Note the word "optimal", e.g., no glitches, and no (or minimal) unnecessary work done.

Of course, it should be fast :) Does anybody know where to find such a toolbox, or libraries that allow me to accomplish the above? Any pointers are greatly appreciated!

[thekaleb]

Take a look at https://www.meteor.com

[amelius]

Thanks for that link. I did a bit of reading, and found this [1].

> These are the main bottlenecks when scaling Meteor, and they introduce two main issues: 1. The polling and comparing logic takes a lot of CPU power and network I/O. 2. After a write operation, there is no way to propagate changes to other Meteor instances in real-time. Changes will only be noticed the next time Meteor polls (~10 seconds).

This seems like quite a limitation. So I wonder if there are any libraries out there that successfully solved this?

[1] https://meteorhacks.com/does-meteor-scale.html

[killing_time]

Specifically about this issue, see the section about the MongoDB oplog further down in the article. This removes the polling interval/overhead, so should significantly improve performance and responsiveness.

[amelius]

Ok. It indeed seems to be the case that the polling delay can be eliminated. But I'm wondering, if db-changes are written to the client directly, is it still possible to apply security rules to that? Evidently, I don't want all my db-changes to be written to all clients, and, preferably, a security-filter should be able to determine which clients receive which updates.

[killing_time]

Yeah - the very earliest preview versions of Meteor had this obvious gap where reads and writes were basically a free for all. However, it's changed a lot since then. As a development crutch the aptly-named 'insecure' package is installed by default (which maintains the free for all), but you're expected to remove it and able to apply fine-grained control to which clients can C/R/U/D which data.

These two steps of the Meteor tutorial probably describe it best: https://www.meteor.com/try/10 https://www.meteor.com/try/11

[ExpiredLink]

You are looking for ... PHP!

[amelius]

I'm looking for a solution that allows database access from the client (the browser) directly. As far as I know, you can't run PHP on the client (at least efficiently).

[waps]

Since there are a million "what is GWT" questions, let me give a thorough answer :

If you have any question with "javascript" anywhere in there GWT is not the answer, unless it's "how can I avoid javascript alltogether ?" (a common question for me and a lot of others).

GWT is a crosscompiler, RPC generator and UI toolkit. That means :

1) Crosscompiler: all code is in Java (and you can pick what code runs client-side). You write browser applications in Java, instead of Javascript. It's not emulated. The client-side javascript is not large (like asm.js stuff), doesn't require plugin downloads that don't work on half the platforms (flash, ms stuff, ...), it's not limited (like most of the javascript frameworks that are advised here that won't work for graphs in canvas ...), ...

TLDR: it's cross-platform, resulting application can work on all browsers, and everything else (e.g. native Android/iOS/Windows/...) (even IE6 if you really want).

2) RPC generator: you can call server-side methods that are also in Java. You can call them as if they are local methods, except that they can execute asynchronously and they can fail with network-related exceptions. This means you don't do it yourself, meaning no work and no errors.

This means that using any java-accessible code on the server in your in-browser applications is trivial.

3) A powerful desktop-like UI toolkit that works well. GWT is "Delphi/Visual Basic/Visual C++/..." with Java as the backing language on the web. https://www.youtube.com/watch?v=kV5H3rGfqOE

4) It's java. The same code works on Android, works on iOS, works in Windows, works on linux native, works on ... and works in the web browser (though you'll have to use different UI toolkits. But in a well-designed application, MVC, only the V needs to be platform-specific).

5) Because reusable code is actually possible in this UI toolkit, you find graphing libraries/controls/... that work well within the toolkit and that work together and you can usually get support for (e.g. Vaadin).

Making client-side Models and Controllers that work on all platforms is very easy (with a little discipline). Making sure that code stays in sync across all platforms is trivial (java is statically typed. Add a new field, and forget to add it on one platform, boom, compile fails).

The big disadvantages :

The big one : Java is a language that is made primarily to allow you to manage complexity in large applications. There is a lot of "default" complexity and lots and lots of tools to manage and refactor large codebases. Java itself is a static language with access controls and many tools to help you. That means that GWT-Java based applications can be a LOT larger than anything you'll ever write in Javascript. This also means that this is meant for large applications. You will find it less helpful for small applications.

You can't use javascript frameworks easily (but it's possible).

It's possible to not use the UI toolkit, but it requires lots of inside knowledge.

You have no easy control over the generated javascript (again, possible, but if you don't know compilers, you may want to avoid this).

You have very indirect control over the DOM elements in your web page. If this is important to you, life's gonna suck.

It's java, not many people would call this their favorite language.