8 ms·

Why Angular, Ember, or Backbone don't work for us.

31 points by tipiirai 13y ago

lauripiispanen 13y ago
"I want two-way binding only, but I'm forced to take the whole framework. There is too much overhead for me. I hope they will make the data-binding a separate piece and make it simpler." How about Knockout.js? http://knockoutjs.com/ http://knockoutjs.com/
- tipiirai 13y ago
  Looks decent. With a quick look the the binding system looks simpler than in Angular and the docs are not blowing up. They openly love jQuery. Much closer to my taste. I picked up the 3 frameworks on my blog entry because they seemed to be the most talked about. Have to keep an eye on this.
- tipiirai 13y ago
  This example from the docs seems quite heavy: <button data-bind="click: function(data, event) { myFunction('param1', 'param2', data, event) }"> Feels a bit strange to define functions on the HTML code.
  - lauripiispanen 13y ago
    If you look at the examples above it, they contain references to functions in scope. This particular example demonstrates that you can also do custom binding if you wish. Most often you don't.
darep 13y ago
Neat. Would be super interesting to see what the architecture is like, how the modules are laid out etc.
- tipiirai 13y ago
  The whole client will be open sourced later once it's properly packaged. It takes time. I'll first release the syntax highlight package, which supports 50+ languages and is super small. Then I'll first release the json-rpc communication piece. Finally the client.
  - darep 13y ago
    Awesome
darep 13y ago
Also, how many people are working on this codebase? :)
- tipiirai 13y ago
  I do most of the work + 2 other contributors.
tharshan09 13y ago
nice post. Could you go into more detail about the controller snippet? What are you doing after the "// listen to events on model".
- tipiirai 13y ago
  When something happens on the topic object (it is expanded, collapsed or someone replies to it) an event is emitted. Here those events are caught and I can do my thing on that moment. It's similar to jQuery custom events, except that we use our own event system so we can get rid of the DOM specific features – such as the jQuery.Event object.
rich_harris 13y ago
Well articulated. If you'll forgive some shameless self-promotion, Ractive (http://ractivejs.org http://ractivejs.org) was born of the same philosophy - programmers shouldn't have to bend their code to the will of a framework, nor should they have to learn a dozen new concepts in order to be productive. It's an alternative to Knockout or React.
- tipiirai 13y ago
  Looks good. I can definitely forgive :) Looks like we have similar goals: > Ractive.js is designed to have as few surprises as possible – no mysterious $scope.$apply()
hejsna 13y ago
Nice article and I agree with most of it - it's very hard to find a framework that strikes a good balance between lean and full-featured. But I don't think the answer is writing everything yourself, either. Rolling your own framework is a lot of work and you're not even guaranteed to wind up with something better than what's out there. Some people believe jQuery is bloated and create their own framework with a mix-and-match from microjs.com. Great! But it's super painful to work with, because at some point you realize "oh, i need to deep-copy this object" or "this should slide down - oh wait" and suddenly you're re-inventing wheels all over the place. With your own subtle browser bugs, Unicode issues, and keyboard problems. Ugh. Especially when you're going to replace things like socket.io, mentioned in the article. But I'm on board with the general concept here and I'm not sold on Ember or Angular - they don't seem to speed up development or prevent bugs as much as they should, per kb downloaded to the client. Sometimes all you need is plain-old jQuery code, with a well thought out and structured API.
- tipiirai 13y ago
  Thanks. One thing to note that I didn't write my own framework. I just found my own way of structuring things. Apart from a custom event library there is virtually no framework code.
  - tipiirai 13y ago
    Okay. I admit that we needed to bang our heads with the custom communication library which we use in place of socket.io. But our solution is more than 10 times smaller!! There is a crazy amount of clutter in socket.io, believe me. And it didn't scale for us. And most importantly we didn't want to use the proprietary syntax that goes inside a websocket channel since something as clean as JSON-RPC exists.
    - lrvick 13y ago
      Did you look at SockJS? It is far more mature than Socket.IO imo. Follows the websocket spec, does not resort to flash for fallback, supports more fallback methods, and later when websockets are fully supported native you just replace "SockJS" with "Websocket" in your code and drop the library.
zarski 13y ago
I heartily agree. I had a similar experience when researching client-side frameworks within the scope of minimal viable products. http://minimul.com/should-i-build-an-MVP-using-a-client-side-framework.html http://minimul.com/should-i-build-an-MVP-using-a-client-side...
EugeneOZ 13y ago
Use Google CDN hosted AngularJS - it's pretty fast. And size of jQuery is bigger ;P

31 points by tipiirai 13y ago

"I want two-way binding only, but I'm forced to take the whole framework. There is too much overhead for me. I hope they will make the data-binding a separate piece and make it simpler." How about Knockout.js? http://knockoutjs.com/ http://knockoutjs.com/

tipiirai 13y ago
Looks decent. With a quick look the the binding system looks simpler than in Angular and the docs are not blowing up. They openly love jQuery. Much closer to my taste. I picked up the 3 frameworks on my blog entry because they seemed to be the most talked about. Have to keep an eye on this.
tipiirai 13y ago
This example from the docs seems quite heavy: <button data-bind="click: function(data, event) { myFunction('param1', 'param2', data, event) }"> Feels a bit strange to define functions on the HTML code.
- lauripiispanen 13y ago
  If you look at the examples above it, they contain references to functions in scope. This particular example demonstrates that you can also do custom binding if you wish. Most often you don't.

darep 13y ago

Neat. Would be super interesting to see what the architecture is like, how the modules are laid out etc.

tipiirai 13y ago
The whole client will be open sourced later once it's properly packaged. It takes time. I'll first release the syntax highlight package, which supports 50+ languages and is super small. Then I'll first release the json-rpc communication piece. Finally the client.
- darep 13y ago
  Awesome

darep 13y ago

Also, how many people are working on this codebase? :)

tipiirai 13y ago
I do most of the work + 2 other contributors.

tharshan09 13y ago

nice post. Could you go into more detail about the controller snippet? What are you doing after the "// listen to events on model".

tipiirai 13y ago
When something happens on the topic object (it is expanded, collapsed or someone replies to it) an event is emitted. Here those events are caught and I can do my thing on that moment. It's similar to jQuery custom events, except that we use our own event system so we can get rid of the DOM specific features – such as the jQuery.Event object.

rich_harris 13y ago

Well articulated. If you'll forgive some shameless self-promotion, Ractive (http://ractivejs.org http://ractivejs.org) was born of the same philosophy - programmers shouldn't have to bend their code to the will of a framework, nor should they have to learn a dozen new concepts in order to be productive. It's an alternative to Knockout or React.

tipiirai 13y ago
Looks good. I can definitely forgive :) Looks like we have similar goals: > Ractive.js is designed to have as few surprises as possible – no mysterious $scope.$apply()

hejsna 13y ago

Nice article and I agree with most of it - it's very hard to find a framework that strikes a good balance between lean and full-featured. But I don't think the answer is writing everything yourself, either. Rolling your own framework is a lot of work and you're not even guaranteed to wind up with something better than what's out there. Some people believe jQuery is bloated and create their own framework with a mix-and-match from microjs.com. Great! But it's super painful to work with, because at some point you realize "oh, i need to deep-copy this object" or "this should slide down - oh wait" and suddenly you're re-inventing wheels all over the place. With your own subtle browser bugs, Unicode issues, and keyboard problems. Ugh. Especially when you're going to replace things like socket.io, mentioned in the article. But I'm on board with the general concept here and I'm not sold on Ember or Angular - they don't seem to speed up development or prevent bugs as much as they should, per kb downloaded to the client. Sometimes all you need is plain-old jQuery code, with a well thought out and structured API.

tipiirai 13y ago
Thanks. One thing to note that I didn't write my own framework. I just found my own way of structuring things. Apart from a custom event library there is virtually no framework code.
- tipiirai 13y ago
  Okay. I admit that we needed to bang our heads with the custom communication library which we use in place of socket.io. But our solution is more than 10 times smaller!! There is a crazy amount of clutter in socket.io, believe me. And it didn't scale for us. And most importantly we didn't want to use the proprietary syntax that goes inside a websocket channel since something as clean as JSON-RPC exists.
  - lrvick 13y ago
    Did you look at SockJS? It is far more mature than Socket.IO imo. Follows the websocket spec, does not resort to flash for fallback, supports more fallback methods, and later when websockets are fully supported native you just replace "SockJS" with "Websocket" in your code and drop the library.

zarski 13y ago

I heartily agree. I had a similar experience when researching client-side frameworks within the scope of minimal viable products. http://minimul.com/should-i-build-an-MVP-using-a-client-side-framework.html http://minimul.com/should-i-build-an-MVP-using-a-client-side...

EugeneOZ 13y ago

Use Google CDN hosted AngularJS - it's pretty fast. And size of jQuery is bigger ;P