Include Angular library in example app

[amark]

Include Angular library in example app

[amark]

Realistically I should just remove the angular dependency, such that all gun example apps in the gun repo are just plain JS.

I do want common library/framework examples but I do not want to have to bundle their source code in our repo.

So the option is have some default examples with existing frameworks in the gun repo (which would be nice) but rely on a CDN which causes issues while offline. Or remove those examples entirely to another repo.

Ideally I want neither. Any clever alternative?

[coolaj86]

Make a repo for each example that is batteries included.

—
Sent from Mailbox

On Wed, May 13, 2015 at 10:19 PM, Mark Nadal [email protected]
wrote:

Realistically I should just remove the angular dependency, such that all gun example apps in the gun repo are just plain JS.
I do want common library/framework examples but I do not want to have to bundle their source code in our repo.
So the option is have some default examples with existing frameworks in the gun repo (which would be nice) but rely on a CDN which causes issues while offline. Or remove those examples entirely to another repo.

Ideally I want neither. Any clever alternative?

Reply to this email directly or view it on GitHub:
#51 (comment)

[coolaj86]

Or just use package.json and bower.json in each example folder so after npm install and bower install the stuff is downloaded.

—
Sent from Mailbox

On Thu, May 14, 2015 at 9:15 AM, AJ ONeal (Home) [email protected]
wrote:

Make a repo for each example that is batteries included.
—
Sent from Mailbox
On Wed, May 13, 2015 at 10:19 PM, Mark Nadal [email protected]
wrote:

Realistically I should just remove the angular dependency, such that all gun example apps in the gun repo are just plain JS.
I do want common library/framework examples but I do not want to have to bundle their source code in our repo.
So the option is have some default examples with existing frameworks in the gun repo (which would be nice) but rely on a CDN which causes issues while offline. Or remove those examples entirely to another repo.

Ideally I want neither. Any clever alternative?

Reply to this email directly or view it on GitHub:
#51 (comment)

[coolaj86]

BTWs it's not possible to use just JavaScript since JavaScript has no way to do file access or http access. You end up having to use jquery or angular if you want to use just JavaScript since they shim the DOM to return proper native JavaScript objects instead of C++ and Java linked objects that aren't compatible with native JavaScript functions.

[alexlafroscia]

@coolaj86 what does that mean?

[coolaj86]

What does which mean?

[alexlafroscia]

BTWs it's not possible to use just JavaScript since JavaScript has no way to do file access or http access. You end up having to use jquery or angular if you want to use just JavaScript since the shim the Dom to return proper native JavaScript objects instead of C++ and Java linked objects that aren't compatible with native JavaScript functions.

What can't you just use JavaScript for? Also, where are C++ or Java involved in including or not including Angular in anything?

[coolaj86]

There's this whole hipster bs lately about "vanilla js", but "vanilla js" would mean proper ES5 "use strict";, Promises instead of callback hacks, etc.

But even with that, JavaScript still doesn't have any way to do web requests. JavaScript does not have a way to set a timeout or interval. JavaScript doesn't have a way to access a file system. JavaScript has no native I/O capabilities and no built-in asynchronous routines (other than Promise).

When you use the DOM (think of the inappropriately named XMLHttpRequest) you're accessing C++ (Chrome, Firefox), Java (some embedded browsers), or C# (Trident / MSIE) and exposing incompatible objects through a binding layer.

For example, have you ever tried calling JSON.stringify(ev) on a click event? It gives you a non-javascript DOM-bound event object that can't properly be stringified. Or how about using JS-native Array methods on a DOMList (think querySelectorAll).

Any time you run console.log(foo) (console is NOT "vanilla js", btw) and you see function [Native Code] as the output, you're not using "vanilla js".

The reason that we have jQuery and Angular is that the developers who created the DOM decided to use crappy wrapper objects instead of exposing them as "vanilla js". Libraries like jQuery and Angular copy or wrap the non-javascript objects with actual javascript objects so that you can use them more easily in your code.

When you use node, the story is a little better. For the most part all of the node bindings to C++ actually return real "vanilla js" objects. In fact, as much as I can recall, node doesn't return any objects or expose any public APIs except for "vanilla js".

If you did, however, really want "vanilla js" for the dom there are two libraries (react and jsdom) which will do so.

So "plain js" and "vanilla js" are a ruse. They are completely useless and the best we can do is to use the non-js apis that we are forced to use and wrap them such that they expose "vanilla js" to us.

[alexlafroscia]

Okay, but what does that have to do with including Angular in the example app?

[coolaj86]

1. You don't need to include angular in the repo. Just use bower.
2. Angular objects and functions are "vanilla js". They are much much more "vanilla js" than the DOM.

[alexlafroscia]

I see what you're getting at, although I'm not sure it's really fair to say that using the DOM isn't "vanilla js" since pretty much anyone working with JavaScript is doing it in a web browser with the end goal of manipulating the DOM (unless you're using Node, of course), especially considering those other libraries are really only wrapping the same underlying code that you could use yourself. But that's neither here nor there.

@amark I think that @coolaj86's suggestion of breaking examples out into separate repos is the best option. I'm still on board to make an Ember package/demo now that I have time.

[amark]

oh my, that was a hilarious tangent. Thanks for the entertainment.

@alexlafroscia yeah, I still want some examples bundled with the repo just so it is easy for people to try things out in one go. But you're right, any examples that start using popular external tools should probably be broken out into their own project. Plus then we can make those ones look "pretty" too, such that they focus on the aesthetics of gun powered apps while the bundled ones would be super simple microscopic apps that are easy to fiddle around with, understand, and get started with.

An Ember demo would be great! Although warning: our next release of GUN will have a lot of breaking changes and finally have support for tables and stuff. So be prepared for things to change.

[alexlafroscia]

@amark Any idea when that's coming? If it's that different, I'd probably be better off just waiting until it has been released. Maybe we can chat on Gitter about what the best way to approach that is.

[amark]

@alexlafroscia I just started coding again, so I'm not sure how long. :(

The internals are changing a bunch, but how you USE gun stays the same, with the EXCEPTION of some API renaming:

• .get will be renamed to .val
• .load will be renamed to .get
• .set will be renamed to .put
• .all will be introduced.

Are the major things, some minor details like .blank is being renamed .not or maybe depreciated.

Yes, hit me up on the gitter whenever you want. It is up to you whether you want to wait or not, I don't blame you if you'd rather hold off.

[amark]

Broken into #79 which resolves the immediate issue. Now this issue is about splitting an angular app into its own seed project repo that we put up on github.

[amark]

We have some starter app examples using different popular frameworks here or listed here: https://github.com/gundb/gun-starter-app

I didn't see Angular specifically mentioned yet. But I'm gonna say that that should be the reference point, not gun core anymore - we want gun core issues to be about "bugs" to help people understand potential existing flaws. With that, gonna close! I hope that is okay.