He uses the stuff. He wants to run only code he wrote. He's made a ton of money doing things his way. He was an evangelist for Intel back when they had their first CPUs. Then he went on his own and did motion control chips and then ISDN.

Last time I talked to him his plans were for a CPU/OS that would be 100% text. He said Microsoft's leverage was binary->text. I didn't exactly follow, but I didn't ask questions either.

I'm guessing this guy is crazy smart and could have made a lot more money doing some things other people's way.

I'm guessing the extra money this guy could've made doing some things other people's way wouldn't have been worth the trade off to him.

That wasn't my point. My point was simply that he didn't make a lot of money because he did everything himself.

Edit: maybe that's still vague. I just mean crazy smart people can make money in a whole lot of ways. Therefore the fact that they make money one way isn't actually good proof that that particular way is a good idea.

It's not just file size.

I did even more reading and a ton of people compare ember to rails and backbone to sinatra. There's a gigantic camp of people on both sides. Just because something does something for you doesn't mean it's the right decision, in a lot of cases it won't even save you time too.

Many CS students do this
The CPU design a little less often but there's only so much you can take from the crappy x86 architecture before the floodA20gates of anger open and you scream out "screw this ima do something better"

Ahh A20 gates.. "The Gates of Hell"

Does anyone know how to filter youtube searches by langauge? Or if its even possible? If I search with the words tutorial and beginners I don't want videos in ****ing spanish

Maybe he just decided he'd rather live a modest life, but spend it doing something he loved and found interesting?

There's not much point in being the richest man in the graveyard...

Juk

RubyMine 30% off untill the 16th...I think I'll buy it (47 Euro for personal license)

Hack: Search on google with site:youtube.com and use "&hl=en" on the resulting url :P
Iirc hl=en only needs to be set once and not on each query because it stays untill you manually change it back

Thanks

Hopefully you saw my follow up post where I pointed out that wasn't my point.

Sure.

First 40k is nothing, especially since the browser will cache after the first request. jQuery is 32k and we never complain about that because of how great the benefits are. How big would jQuery have to become before you stop using it?

So first lets start with what Ember is... it's an MVC framework and MVC is really freaking important when there is application state. You're probably thinking well I know MVC because you code in Rails/Django, but that's not really MVC. Why? Because there is no state in HTTP. Each request does not depend on the last request, requests are short lived, and you do not have to manage state transitions between the requests. If the person requests the users page, you give the all the users page, if they request the home page, you give them the home page. The previous requests don't factor into the current request. In Javascript applications there is a lot of state... things like is the user currently logged in? Which part of the application is the user in now? If they are looking at list of orders and we need to filter by orders paid with visa, what do we apply that filter to? None of these questions exist in your standard webapp/http because each http request is stateless. Btw, this is one of the reasons why writing web apps so easy/awesome because http completely removes the complexity of having to manage state. Now they are we are starting to see more statefull server side apps (things that use websockets) we'll start needing help managing state on the server. Anyway lets get back to Ember... Ember gives you models (data), controllers (state), views (presentation/ui/events) so you do not have to manage any of this stuff yourself.

Backbone is not an MVC framework, it's probably more like MVVM, but you could easily build a MVC structure on top of backbone. When I was writing backbone apps I used collections as a controller layer and that worked pretty well, but I mean **** you could probably use backbone views as a controller layer as well. When you start having all of these different ideas that solve the same problem your code gets real ugly really quickly. Backbone is also really lightweight and is made to be built on top of (imo). It provides you with very little tools, no convention, and lets you choose whatever path you want to follow. This gives you speed and the idea of freedom, but ultimately it means you are writing more code and responsible for more things. More code often leads to more coupling and bad architecture, which is bad.

Ember is very convention over configuration (yay javascript buzzword of 2012!). I think the Ember guys sum it up best when they say 'optimized for developer happiness'. Lets get into a few things that make Ember apps fun to write.

1) Computed properties.

Basically you have a function that returns a value, but when you access that function you access it as a javascript property. This makes refactoring code really easy because internally you can express things as functions/properties, but externally they will always be viewed as a property.

We can go from:

We can later refactor the above to become

You can see how massive refactorings become really nice because you only have to internally refactor, to the outside everything stays the same.

2) Bindings.

Bindings are basically variables that are shared across multiple objects, including views and templates. This means you can have something like {{name}} in a template, and when the user changes their name the template automatically updates.

Think about a shopping carts. A user has one $10 screwdriver in his shopping cart. So you would have a page that displayed his cart, summed up all the items and printed out a nice total. What do you do when the user adds a $20 hammer? You do nothing, because ember does it all for you... Ember will automatically update the page to show a new item in the cart and a new total.

Here's a dirty example for how total might work: When the user clicks on a buyItemView it will add that item to the cart. When the cart changes a new total will be calculated and the html will be updated to show the new total cost of the cart.


There are a lot more things that Ember provides to make writing code easy. On the controller side there are a number of classes you can inherit from to manage arrays/lists/objects/statecharts. Views are the same, for example there are a number of built in classes that make updating objects from forms extremely simple. The Ember run loop is really smart about how it processes bindings/events, and the best part is you don't even need to worry about it because it is completely abstracted away from you. There's ember-data too, which makes syncing your javascript objects/relations really simple with your Rails/backend apps. There is so much more to Ember than I have mentioned in this post and tbh I haven't even scratched the surface.

I recommend checking out emberjs.com: the todos example is simple, but effective in showing you how to write a quick app. Also, all of the code in this post is a mix of ember, js, and pseudo code... and sorry for writing such a long post.

It's a non-issue for me because I don't use jquery and never once had the urge to use it. It's bloated spaghetti trashware. The only reason it thrives is because people love taking the easy way out and expect to Google for a pre-made solution and then find a plugin that mostly works for them. Also the jquery developers scared people into thinking it's really scary and hard to write cross browser compatible code.

I got about this much from the video. I dunno, I'm not a ruby developer but I would definitely dig myself deeply in the Sinatra camp if I were (I use express with node.js which is similar).

I think the whole MVC vs MVVM vs MV* discussion is pretty ******ed too. It doesn't matter what it's called as long as it allows you to separate your concerns in a way that makes sense.

I recently discovered that if you want to use backbone views or the router it depends on jquery (or zepto) which is disappointing. They might as well say it's a hard dependency to use BB in general because chances are you're going to want views and routing. Guess it's time to find another alternative.

i agree with the bolded. as for the rest... sorry, back to my butter churn.

Lol at not using jquery. Its probably overused but talk about a waste of effort if you're not using it based on some sort of trivial performance objection.

also shoe and shabby, IT FEELS LIKE I AM JUST TOO CLOSE TO LOVE YOOOOOOOOOOOOU

I'll retort with lol at using query.

Have you bothered to even attempt to figure out what you need to do to get xhrs, selecting, and setting most attributes to work in all grade A browsers (IE 8+ included)?

I'll give you the tl;dr version... not much effort at all.

Next you're probably going to say that jquery is really fast and not much different than making native calls? Am I right?

Is the effort more than 5 minutes? Because that's probably what it took me the first time I used jquery.

As for performance, are we going to argue about ms again?

Of course it's more than 5 minutes, but it's less than 5 hours.

What solution seems more promising to you given the situation below:

You have a site that's pretty popular and you get 2 million uniques a month. You're hosted on the cloud so you're paying for cpu cycles and BW as it's used. You have a little javascript usage but not a ton. You update some content with ajax and offer a few neat snippets of functionality that makes the UX better.

Traffic distribution is heavily weighted towards desktop browsers but at least 20% of your traffic comes from mobile devices and you assume in the future that % is going to grow.

Would you rather A:

Spend a day or 2 (once) rolling your own light weight solution that gives you IE 8+ / A grade browsers full cross browser support for everything you do on the page.

Or B:

Mindlessly download some massive library because "everyone else does" and offers no benefit at all other than saving you a few hours once. However it introduces a ton of unknown negatives over the long haul of your site.

You realize that rolling your own solution contains a ton more unknown negatives, right?

You also realize that every time you want a new feature you're going to have extend your home-grown solution? Right?

So sure if you can write bug free software and are building a site that will never change you should probably roll your own solution.

Edit: I forgot also never going to have other devs looking at your code.

Shoe can you give us some general idea of where you work or the problems you're typically solving?

Massive library lol. Sorry, I don't write webapps for Somalian dialup users.

the term "bloatware" inherently implies some performance issue. a winXP machine loaded with bloatware takes a long to boot up, eclipse takes a long time to start and uses a lot of RAM, etc.

i've never seen anyone complain about jquery taking too long to download, or lag time for mouse events to be processed.

honestly, it sounds like your objections are based on some principle or philosophy that doesn't connect with real world problems.

this is so wrongheaded. you are underestimating the pain of doing it yourself, you aren't considering that your 2 day roll your own solution won't be as robust or well tested as jquery, you are ignoring the fact that with jquery any other developer you hire will need 0 rampup time, and you are overestimating the supposed difference in BW cost. there is a reason that no serious company thinks about the problem the way that you are.

Hi Shoe Lace,

In the above case, it doesn't make much of a difference which solution you choose and the developer should go with whatever is more fun. The better question is what are your future needs? Unless your needs are highly idiosyncratic, it seems unlikely that maintaining your own library while gradually adding features is worthwhile, unless you find it fun and make that a side business. The expectation is that jQuery will evolve to meet the needs of current and future users (or it already has) - your library won't, unless you put more and more effort in. The other reason for not reinventing the wheel is that the current wheel is almost certainly better tested and far more robust. Furthermore, using a widely used core library and following its convention makes it easier to interface with and reuse other people's code.

Would you advise a developer to roll out his own lightweight database engine (should take a day or so) for a simple web site with simple persistence needs? After all, for simple data and simple requirements, a full blown RDBMS, or even a full NoSQL solution like MongoDB/CouchDB are overkill. They probably won't save you much time and take up a ton of resources and introduce a ton of unknown negatives.