Many people view Facebook policies as creepy and unethical, that is probably driving this negative response. We don't know where mainstream VR will take us in ten years, but we do know that there have been many assaults to our privacy and we don't want to create another keyhole into our private lives.
If WebGL worked in UIKit's WebView, you could just wrap your WebGL game with PhoneGap and use StoreKit for ripping off children... I mean, selling exciting in-app upgrades.
I'm not convinced the App Store is a meaningful marketing channel anyway, except for the 0.001% of game developers that can afford to buy downloads and then happen to get lucky in the App Store curation roulette.
I wonder if it will become a trend to name technologies after taboo items? Imagine if a product called Dildo comes out and it is the best, most easy to use piece of software that ever existed. People would just have to use Dildo and get over the name. It could start a revolution.
Adam has put into words the ideas that have been floating around in my head for awhile, and does so in a very interesting way. Cataloging mental models. Cool. Very loosely reminds me of Jung's personality archetypes.
I'm a person that has spent lots of money on low-latency digital audio interfaces and know from experience that every millisecond counts. It seems like this type of technology always suffers from latency issues. How are latency issue overcome by BandHub?
BandHub is not real time, but rather async. You lay down a track, then someone else lays down another and so on. You record on top of what's already been recorded. It's like a multitrack YouTube so to speak.
EDIT: new tracks show up after ~30 seconds of being recorded by other users. so you can use it for real time production
This is cool, but I found a small defect. If you drag the dot over the images while they are loading, the color change doesn't take place. It might be necessary to call your function after images have been loaded on your demo page.
What problem is ojjs solving and what are the trade-offs?
For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css person would have blurred lines separating their responsibilities. It is a cool project, but it seems like a step backwards to me. Maybe it's just a step sideways or a better way of doing things for a team consisting entirely of programmers.
Author here=). OJ is trying to solve the View layer by creating objects that act like website building blocks. So you can insert a YouTubeVideo or a TwitterButton as easily as you add an img or a div. Check out the plugins: http://ojjs.org/plugins.html
But to your question should all CSS be in JS? I'd say no, that wouldn't make sense. Clearly site level CSS should remain in a file and can be just included in a link tag normally.
The CSS being moved into JavaScript would be just that CSS used by the objects. This is how OJ Objects have no dependencies. The CSS for the YouTubeVideo, or Tab control, or the TwitterButton is included in the objects themselves. So definitely imagine still using CSS as you do now, but pulling out only the css needed for the reusable components into OJ Objects.
This approach creates multiple sources of truth for how elements should look, and in general I would avoid it - in the same way that I avoid using the style attribute or <style> tags.
For structure (the meaning and content of each element), use HTML. For presentation (e.g. colors, fonts, transition appearance), stick to your linked stylesheet. If you need to modify behavior (e.g. what happens on a given event), do that in a Javascript include.
It really depends where you're coming from. For the kind of sites that prevailed maybe five years ago, you could separate HTML and CSS quite neatly and JS was a minor element used to add some effects. But these days you're starting to get web apps etc. with very rich interactivity; and once you're past a certain level of complexity it's inevitable that you'll end up modifying lots of HTML and CSS from JS. So if you reach that point then you can efficiently make JS your main (or even only) source of truth.
Ten years ago, we were all tempted to put <style> tags in the HTML "in order to have the entire website in one place." As site complexity grew, we realized we needed to start separating components that had distinct roles. If I'm changing a font site-wide, I don't want to scroll through lines of totally unrelated copy to get to my styles. I want completely separate files that only need to reference each other (via classes and ids).
I am a huge fan of AngularJS, because it's essentially following the same separation pattern. It uses references (like ng-model, ng-controller, etc.) to attach elements to associated interactive behavior, but doesn't actually interfere with the structure of the page.
Things like fonts can be defined at a high level by higher-level css tags or classes. I usually use less instead of direct css, so for me I'd just throw in an import in each view's less file to get the default styling applied, or I'd just have basic font styling done at a higher level in css so at the level closer to the actual class, I'd only need to apply tweaks as needed.
To be fair, so does Twitter Bootstrap, with its use of classes like "pagination-centered" - but even that's an antipattern. I tend to agree with etj's approach.
The solution is very similar to GWT, Google's ugly step child. Why ugly, because it uses Java... hiss! Boo! Yet it does make every optimization under the sun and boils it down to JS.
Using JS to insert CSS, DOM nodes, and more JS is becoming pretty standard now. ExtJS and GWT led the way seven years ago, and frameworks need only dumb it down more to gain popular acceptance. I've been on teams that made award winning sites with GWT, but you had a steep learning curve. Perhaps OJ can overcome that.
Have you ever used ExtJS? ...I have had the displeasure of developing with it at a large financial institution...it is madness...everything is a JSON object and what ends up happening is a mixing of concerns...putting logic, and layout in the same place.
ExtJS didn't lead shit...there is a reason hardly anyone uses it.
GWT I am not personally familiar with, but if it is at all like ExtJS I want to stay AWAY as much as possible.
> ExtJS didn't lead shit...there is a reason hardly anyone uses it.
One major reason is it's just so freaking large and unruly to do anything simple. It's one of the few frameworks I've used that even after moderate use, I still had to keep the docs open on one screen even during routine development. The error messages weren't very helpful, either.
I did use it for a large project over about 14 months. You do need those docs open and since Sencha's doc servers were always overwhelmed, they suggested you run your own locally ;)
Even so, the GWT creators ended up recognizing the value of presentation markup and introduced the UIBinder system (HTML markup + XML for custom widgets), which arguably made my life a whole lot easier when I was working on a moderate-sized GWT codebase. It's definitely better compared to mucking around with Swing-looking code soup.
GWT-P takes this a step further with completely isolated layers (MVP) so that you can easily make permutations of your app bound to a Tablet, Mobile, and Desktop set of Views very easily. I've been using it a year now and love it.
The goal of these types of systems (react.js essentially does the same thing) is to fully abstract away the need for direct HTML/DOM manipulation.
Now it's possible that the layout of the current browser DOM represents ultimate perfection and we will never improve upon it. However, it is more likely that we will find some way to come up with a better design for the DOM in the future (i.e. new types of nodes, node attributes, member functions, or some sort of entirely new data structure) and these types of frameworks allow us to experiment with new DOM ideas. With oj.js or react.js you could write to this "new DOM" and the library will project changes back to the legacy DOM.
You are right, it doesn't have to. But there are a lot of newcomers to front-end web app development (either moving from other technologies, or new to dev altogether) that might think this library is fit for all sorts of projects and businesses.
That being said, this library does try to solve a problem, it's not useless. In my opinion, it's just not the right tool.. yet.
https://github.com/mark-harmon/HexPixiJs