Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In search of the perfect JavaScript framework

dev.opera.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: In search of the perfect JavaScript framework

#61

Post by sombremesa »

joshontheweb wrote: post #14
danabramov wrote: post #13

>We want to apply values to variables and get the DOM updated. The popular two-way data binding should not be a feature, but a must-have core functionality. Strongly disagree. I find one-way bindings and one-way data flow much easier to reason about. A little less boilerplate code is not worth mental overhead, cascading updates and hunting down the source of wrong data in my experience. What is important is not updat…

Also, data bindings assume you are working with a DOM which isn't always the case. If you make a video game using canvas built-in data bindings just get in the way.

Even when you are working with DOM, if you are on a device with limited capabilities (e.g. mobile devices), depending on the number of elements on the screen the bindings can cause the DOM to take a long time to render.

Normally not a huge issue, but it helps put AngularJS + Phonegap in an even worse position than before against native apps.

Re: In search of the perfect JavaScript framework

#62

Post by EGreg »

danabramov wrote: post #13

>We want to apply values to variables and get the DOM updated. The popular two-way data binding should not be a feature, but a must-have core functionality. Strongly disagree. I find one-way bindings and one-way data flow much easier to reason about. A little less boilerplate code is not worth mental overhead, cascading updates and hunting down the source of wrong data in my experience. What is important is not updat…

What's with the immutability stuff?

Shouldn't updates just be event driven?

Is it really so hard for developers of parent components to subscribe to events of child components?

Re: In search of the perfect JavaScript framework

#63

Post by oneeyedpigeon »

juliangregorian wrote: post #46
weego wrote: post #7

Earlier quoted context omitted.

The irony of suggesting a framework that abuses html attributes in templates to wire up massively abstracted behaviour as a response to someone tearing into the obsession of JavaScript devs with over-abstraction. You do appear to be overly keen on pimping it, but it looks kinda unnecessary.

It's not really abuse in an HTML5 paradigm, attributes are meant to be extensible and semantic.

Why not actually use the mechanism that html5 allows for (i.e. data-* attributes) rather than making up your own, that it doesn't?

Re: In search of the perfect JavaScript framework

#64

Post by RehnoLindeque »

> We all like simple tools. Complexity kills. It makes our work difficult and gives us much steeper learning curve. Programmers need to know how things work. Otherwise, they feel insecure. If we work with a complex system, then we have a big gap between “I am using it” and “I know how it works”.

One answer to this problem of opaqueness in abstractions is having a well defined denotational semantics. This makes it clear that something can work in one way & only one way (without the need to dive into library internals). I feel that Elm is doing a pretty good job of tackling this for GUIs and signals.

Re: In search of the perfect JavaScript framework

#65

Post by juliangregorian »

oneeyedpigeon wrote: post #63
juliangregorian wrote: post #46

Earlier quoted context omitted.

It's not really abuse in an HTML5 paradigm, attributes are meant to be extensible and semantic.

Why not actually use the mechanism that html5 allows for (i.e. data-* attributes) rather than making up your own, that it doesn't?

Just guessing: (1) it's not actually "data" and this provides more meaningful cues, (2) it provides a bit of namespacing so as to not step on the end developer's own data-attributes, (3) turns out that it doesn't actually break anywhere after all, as proven by many JS frameworks at this point. I tried briefly to track some standards down for you, but I know this gets discussed at length on the Angular mailing lists if you really care for the nitty gritty.

Re: In search of the perfect JavaScript framework

#66

Post by [deleted] »

ef4 wrote: post #50
juliangregorian wrote: post #47

Earlier quoted context omitted.

"Black boxes are dangerous" is maybe a more precise way of expressing the concept. I don't think the author literally believes you must be writing machine code.

If black boxes are dangerous then you really should be writing machine code. Which is absurd of course, and demonstrates that black boxes are a very good thing. Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.

[deleted]

Re: In search of the perfect JavaScript framework

#67

Post by juliangregorian »

ef4 wrote: post #50
juliangregorian wrote: post #47

Earlier quoted context omitted.

"Black boxes are dangerous" is maybe a more precise way of expressing the concept. I don't think the author literally believes you must be writing machine code.

If black boxes are dangerous then you really should be writing machine code. Which is absurd of course, and demonstrates that black boxes are a very good thing. Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.

Sometimes you really kinda do. Garbage collection and DOM repaint/reflow come to mind. No abstraction is completely airtight, doesn't mean it's not useful, doesn't mean it isn't a "black box" to a neophyte.

Re: In search of the perfect JavaScript framework

#68

Post by AdamCraven »

danabramov wrote: post #52
AdamCraven wrote: post #34

Earlier quoted context omitted.

It is a shame to conclude two way data-binding should be a casualty in the maturation of frameworks. Like one way data-binding, it can be misused. Two-way data binding to properties is generally not good. It increases likelihood of problems as updates to one value have to be observed to adjust other values. It is easy for bugs to slip in and hard to reason about the code. Two-way data binding to methods is better. Me…

What is two-way binding to a method? Can you give me an example? I can only think of this[1] but despite being similar to two-way binding, this is one-way and explicit. [1]: http://facebook.github.io/react/docs/two-way-binding-helpers...

What you are linking to is still two-way data binding. Which enforces a one-way flow of data.

Two-way binding: Read & Write. Read & Write happens through getter/setter methods.

One-way binding: Read only. Writes happen by external event listeners.

Both can be used to enforce one way flow of data. Just as one way binding can be used to have a uni-directional flow of data.

A pseudo code example with two-way data binding with one-way flow of data:

  

  function getOrSetValue(newValue) {
     if (newValue) {
        // Send an event to a dispatcher with updated value.
     } else {
        return value // can be single value from model or derived value, such as calculation of multiple values.
     }
  }

Re: In search of the perfect JavaScript framework

#69

Post by z3t4 »

kristopolous wrote: post #51
ef4 wrote: post #50

Earlier quoted context omitted.

If black boxes are dangerous then you really should be writing machine code. Which is absurd of course, and demonstrates that black boxes are a very good thing. Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.

Ok let me try. Bad abstractions are bad. Additional complexity without additional functionality, increased dependencies without increasing stability, poor documentation and buggy implementations; strongly coupled things which have no business being coupled and overt assumptions on what kind of application you are writing and how you ought to structure it. They have fundamentals which don't interact with anything else…

I can see all sides of the arguments here. I do love API's, but I hate "frameworks", especially when they consist of useless functions like

  function _MY_framework.enterprise.displayMessageInConsole(msg) {
    console.log(msg);
  }
That does something that would actually be easier in vanilla JS. All years of writing JS may have made me blind, but that's how I see most JS frameworks. Mostly useless.

That said, manipulating the DOM in JS is a PITA. I can totally understand why you would want to do it another way.

I guess the DOM is not meant to be manipulated with ... And breaks if JS is turned off.

I think in the near future in maybe 5-6 years we'll see apps that are a mix of Browser and Native. That has the protected environment like a browser, that ask for permission to use hardware features, that can be accessed through high level API's, have native performance and run by typing an domain address much like WWW.

Re: In search of the perfect JavaScript framework

#70

Post by s_kilk »

juliangregorian wrote: post #47
ef4 wrote: post #41

> "Abstraction is dangerous" The fact that Javascript people keep saying this with a straight face is getting really absurd. You do realize Javascript is also just an abstraction, right? And that the browsers that run it also abstractions, and the operating systems, and the kernels, and even the hardware itself has multiple layers of abstraction? "Abstraction is dangerous" is just fundamentally wrong. Abstraction is…

"Black boxes are dangerous" is maybe a more precise way of expressing the concept. I don't think the author literally believes you must be writing machine code.

Black boxes {are|should be} a good thing.

"Leaky Black Boxes" however (like angular), are awful.

I quite like having a black box with two sockets on it, that I can plug cables into and have it just do whatever it's supposed to.

However, if the sockets are a weird shape, or there 39 of them, or they leak a strange green ooze, then I get upset.

Post reply on HN