I always have a problem with these kinds of frameworks. Every time I try to use one, and want to do something more in-depth for fancy than a lot of the functionality out-of-the-box, then I end up having to hunt down the way to extend X feature, and it often takes me more effort to do that then just writing in the root language would be.
That is to say: The abstraction isn't as expressive as the root language, and when I need something more expressive, then it's more troublesome than writing than the root language.
The rendering engine here does seem to perform admirably, and I have to congratulate them on that. Maybe I've just been burned a few too many times from this kind of language.
I've built many apps using Ember and the time I save not writing boilerplate code or jquery spaghetti is well worth the time I spend understanding how to do more complicated things. Every time I get a bit frustrated with something seemingly complicated, I always realize it was better that way in the end.
Often I discover that I can do exactly what I wanted in just a few lines of code and writing it in pure javascript or jquery would have been many, many more lines of code and much less maintainable.
Developers smarter than I have struggled with these problems and developed optimal solutions that might not be easy to fully grok at first, but are always worth the effort to understand.
I didn't take his comment to be about a learning curve. I think the complaint is that the abstraction on top is not as expressive as the thing it abstracts. This means that when you break the abstraction you have the complexity of the thing you abstracted away on top of the abstraction layer itself, which means you might have been better off without the abstraction in the first place.
That's what I like about the whole WebComponents movement. Whether you use Polymer or X-tags, it's just new DOM elements, and they function just like regular DOM elements, and you can drop down to vanilla JS easily without throwing the productivity benefits of a framework out the window.
I have been following Ember since its 0.9 beta stage and believe me until it released around 1.3 or 1.5 there has been lot of change and was a huge learning curve. But now that I know how exactly ember works, it is easy and fast to write Ember Apps since lot of boilerplate can be easily avoided.
Yeah, I think what you just stated is an issue for any type of abstraction. You really just have to examine an interface in depth before you start writing code with it to see if it's capable of supporting the functionality you need.
Only a few months ago while developing a REST API in Ruby, I implemented MongoMapper for my ORM/Database access layer. Turns out it didn't support a few things I wanted to do, so I hacked my code into little (ugly) pieces just so I could continue using MongoMapper (Didn't have time for a rewrite). I think if I would have just stuck with using the native Ruby Mongo driver, development would have taken less time and my code wouldn't look like a steaming pile of shit!
I've been working on a large app using Ember, and this has been my experience over the last several months. I'm still excited about embers future, and hopeful our choice to use it will one day pay off, but for this first project, we would absolutely have been further along, and happier, had we chosen a less all-encompassing framework and built the required abstractions ourselves (for the very reasons you have pointed out).
I have a real problem with an article that claims something about someone else that the other person themselves would openly refute. It's a classic straw man argument from the start... Assigning expectations and beliefs onto someone else and then deriding them for not holding up to the expectations they've placed on their target.
This is a fun little game. Starts out hard, until you start learning some of the rules. 1's are your friend, as well as large numbers. It'll get easier as you learn more patterns, but there are some that are a good challenge.
So... I'm conflicted about this. Sure, on one hand peer-to-peer streaming could solve some of the problems she's talking about, so long as there's a large enough audience for each video. Services like Steam have used P2P very effectively. At times it can break down to a very frustrating level quickly, so you'll still want CDNs around to act as seeds. It also doesn't work for live broadcasts which is becoming more common with the likes of Twitch. Also, the current technologies being discussed (marketed?) would require a plugin to work. I don't think this will fly until a browser-native solution is engineered.
> so long as there's a large enough audience for each video
Completely a non-issue. The providers would "seed" all the videos from their own servers, too, so when there aren't enough peers seeding it, the bulk of the streaming would be offered by the provider.
Using the Pareto principle, something like 80 percent of the videos would be "long-tail" with few to no seeds (other than from the provider), but only use 20 percent of the video traffic (so the provider's burden is greatly reduced anyway). The other 20 percent videos would represent 80 percent of the traffic, and those are the videos that would be helped most by P2P streaming.
On one hand the interface is interesting and novel, but I'm not sure it really has a lot to offer initially. It's much easier to visualize the relationships between pieces of data with how the linking works, but the individual dots are spread enough that it doesn't provide quite the context that it has the potential to provide.
I'm impressed that it works in Chrome on Linux with no additional plugins or craziness. Their interface is clumsy though, and could learn a lot about user interaction in 3d space from video games.
Their interface is clumsy though, and could learn a lot about user interaction in 3d space from video games.
Yes. I was trying different things with the mouse to help me navigate and orient myself, but aside from zoom, it is just for selection. I'd like to see controls like with the Homeworld series of RTS games, where you can easily rotate around a selected item.
In general, I'm just seeing a sea of topics, without much sense for where I am in the information space. More could be done by varying the size and shape of the nodes to indicate relevance, popularity, or category. I don't think color is enough.
It's possible to rotate the ship only on a 2D plane, we must use + and - to move on the 3rd axis. This makes navigation slow and goes against our reflexes built with years and years of videogames. I hope it gets added soon.
The nicest thing of this interface is being able to see the links to related pages/stars. For reading a page Wikipedia is best, but this is a better tool for exploring the network.
CPU backdoors are a very real concern, but not only in the CPU but in the growing complexity of the motherboard chipset. For example, a malicious memory controller could manipulate data on the way to the CPU, causing a faithful CPU to do malicious things.
For highly secured systems, this is of growing concern. With the amount of stuff made in China the supply chain is considered a considerable attack surface which has to be considered when sourcing electronics.
I abandoned x86 a few years back, because I'm far less concerned about China knowing my secrets than I am with the Five Eyes countries violating my privacy. The likelihood of the nsa or gchq tampering with an allwinner or freescale chip en route is much lower than with Intel or AMD. And far more resources would be involved than would be financially reasonable to tailor an operation for a small-potatoes corporation running an all-ARM setup like mine.
So I'm seeing it as a decrease in attack surface, overall.
I think you underestimate the anger he's caused in the bureaucracy. Governments see him as a security threat, which means they'll spend military-level amounts to keep him under as much control as they can, and will justify that spending as a show of force against other would-be threats.
I'm not really sure changing the behavior of fundamental operations really counts as metaprogramming, but in many ways I think it's very in-line with some conceptual constructs JS already has in place. Considering that you can access an object's properties by addressing an array, the ability to call a function by accessing a property isn't very alien. Considering the flexibility of JS, I'd be curious to see how crazy you could get.
At the same time, I'm also very scared to see what kind of crazy code this will lead to that I'd have to look at. I think lots of people will probably implement overly complex or obtuse ideas because they are interesting.
That is to say: The abstraction isn't as expressive as the root language, and when I need something more expressive, then it's more troublesome than writing than the root language.
The rendering engine here does seem to perform admirably, and I have to congratulate them on that. Maybe I've just been burned a few too many times from this kind of language.