This is a good set of arguments explaining some challenging corners of AngularJS.
It is true that when you start getting into the realm of edge cases, substantial knowledge of the framework's internals is required to put together a solution that is consistent with the 'zen of Angular'.
The author argues that some of the challenges introduced by Angular's $apply lifecycle and its approach to two-way bindings make it a challenge to use in certain circumstances. I would rephrase that and say that Angular's state-tracking and two-way binding solution is a very elegant hack to a very complex problem, considering limitations imposed by javascript, css and html. Angular proposes a set of integrated solutions that allow developers to avoid a substantial amount of boilerplate (and complex boilerplate, at that) for synchronizing state and the view. As with every other framework, it is not appropriate for every problem.
That being said, I continue to use and love Angular in a complex app with quite a few moving parts. I migrated from Backbone.js about a year ago and never looked back.
For the vast majority of websites, this is true and I agree.
However, there are now websites that are more akin to applications than to the traditional website of yore and that are meaningless without Javascript. This is not a bad thing; it is just the opening up of the web platform to new opportunities.
Some of these emerging applications may want some of their content to be searchable and so I argue that the posted solution is solving a real problem and is of value to users.
Google has proven itself as a company capable of, and prepared to move into new markets and to diversify its portfolio of services. Twitter, on the other hand, has only diversified around the 140 character concept.
In my mind, it is diversification that allows a tech company to stay afloat when new entrants can have such a rapid impact on the market.
It is in no way conceivable to me that the 'trendy' means to communicate will still be in 140 character morsels 10 years from now.
This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package.
As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some interesting benefits offered by TogetherJS; the system has cursor and presence features out of the box.
That being said, the main drawback that I see in TogetherJS is that it seems to be tightly coupled in a way that it is hard to take smaller parts of the overall system. It would be great if the P2P network system could be extracted and plugged into a node.js Stream interface. That would allow the code to plug into a whole ecosystem of interesting libraries [3].
I'm really excited by all the powerful libraries that Mozilla has been pumping out these days. The web is a great place to be.
[Author here] The big way TogetherJS differs from many of the other realtime products out there, like Firebase or (to a lesser degree) ShareJS, is that it doesn't do any storage. It coordinates real-time sessions, but it's not there to take the place of the application, instead it augments the application. If your application has persistence, it has traditional persistence. Whatever auth system you have is your own. At the same time while it dodges any persistence, it extends the scope beyond what those other tools typically do to include more with session management and the standard tools that I think are needed for collaboration. There's nothing exciting about text chat, but you need it anyway.
Still, ignoring persistence I think will help keep the surface area of the TogetherJS smaller compared to some other tools. Or at least focused on other things.
People have mentioned the idea of being able to chop TogetherJS up before, but I have a hard time seeing how that would actually work. For instance, the architecture is built around a pretty dumb server, so hooking into Streams would seem counter to that principle. And just allowing for the possibility would add a lot of complexity. Ultimately the UI is actually the bulk of what makes up the TogetherJS code (or maybe it's the part I find hard and so I feel like I spend a lot of time with it), and I don't know how to make this kind of UI while being modular. Without the UI I don't think it's nearly as compelling a project (becomes more like ShareJS, or Firebase, or Google Drive Realtime API – neat but a big investment, and sometimes only appropriate for greenfield projects.
Anyway, I'm certainly interested in how people want to extend or integrate with TogetherJS. I'm skeptical of splitting it up into pieces, as it is theoretically easier to do things that way, but I expect in practice it will just leave a confusing pile of pieces that aren't fun to put back together. But that doesn't mean that there aren't use cases worth exploring... and with some creativity there might be other approaches to handling those cases.
[mozilla employee here] There's no catch except an absence of a commitment to keep running it. Mozilla Labs is charged with figuring out how to make the web better. We think this could help make more apps collaborative. You tell us if we're right.
It doesn't seem to be a P2P system, since it requires a server. According to the docs, "This server does not rewrite the messages or do much of anything besides pass the messages between the participants" [1] , so it's not really P2P.
I'm fairly sure the Firebase requires a server too... (their server, or else they couldn't charge for it).
On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to each other, and while we want to support that kind of architecture in order to get it working we still need to simulate P2P using a server.
WebRTC makes it possible, but not easy, nor abstracted. You still have very long connection strings to establish the connection, and those strings change as you move around, so it's not something we'd want to ask users to send to each other in order to establish a connection. The approach usually used is a server where the two people rendezvous to exchange the connection strings. That server is kind of like what we have – but then once it's in place, changing over to WebRTC just doesn't seem as exciting. (And even then the connections are slower to establish and less reliable than WebSockets.)
We provide wysiwyg editor integration (Aloha-Editor) with presence and remote cursor. We are working on a hosted/downloadable service with low-level data-sync api and high level wiki features: https://wikidocs.com
You can actually do that in Plunker right now by having an `index.md` file instead of `index.html` [1].
In the absence of an html index, the plunker preview server will try transpiling to html from different languages. Markdown is currently supported.
Also transpiled are things like less, scss, coffee-script and more. Essentially, your html requests a file with the target suffix (e.g.: .css) and the preview server will search for compatible source files to transpile to that target.
It integrates with your existing UI, and not as a separate box like Wave or other plugins. I also like that this is free, open source and _from Mozilla_.
Wow, thanks for reminding me of http://bootswatch.com! I just checked it out again after having not looked for a while and I'm impressed with the v3-targeted swatches.
I think that making claims on the changing capital market climate based on historical P/E ratios may be measuring the wrong thing. A declining trend in P/E ratios may suggest a decline in valuations but it also may suggest a change in capital structure. Or it may suggest a combination of the two.
It would be interesting to look at the trend for EBITDA multiples over time instead: https://cloudup.com/cHNL3Wcy5yH [1]. In this view, you can see that TEV/EBITDA ratios are very similar today to what they were in 1995 even though they took a very circuitous route to get there.
[ROM][LineSkipper v3.0.1][Now fixes crash bug when joining line behind Audi's]
Although perhaps ridiculous at face value, I wonder how automobile manufacturers and legislators will prevent modders from tweaking driving algorithms to win the prisoner's dilemma of traffic.
This is the thing that scares me the most. If the self driving cars need to cooperate for maximum efficiency what if there are some cars that don't do it and exploit that?
It is true that when you start getting into the realm of edge cases, substantial knowledge of the framework's internals is required to put together a solution that is consistent with the 'zen of Angular'.
The author argues that some of the challenges introduced by Angular's $apply lifecycle and its approach to two-way bindings make it a challenge to use in certain circumstances. I would rephrase that and say that Angular's state-tracking and two-way binding solution is a very elegant hack to a very complex problem, considering limitations imposed by javascript, css and html. Angular proposes a set of integrated solutions that allow developers to avoid a substantial amount of boilerplate (and complex boilerplate, at that) for synchronizing state and the view. As with every other framework, it is not appropriate for every problem.
That being said, I continue to use and love Angular in a complex app with quite a few moving parts. I migrated from Backbone.js about a year ago and never looked back.
/x-post from Reddit: http://www.reddit.com/r/javascript/comments/1pdzbz/things_th...