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

41–50 of 85 posts

Re: In search of the perfect JavaScript framework

#41

Post by ef4 »

> "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 the only way we get anything done.

What you really mean to say is that bad abstractions are bad. But stated so clearly, it becomes obvious that it's a tautology. Well-designed abstractions that leak as little as possible are essential to everything we do.

This stuff matters, because instead of having stupid arguments over "how much" abstraction we want (which really boils down to 99 layers vs 100 layers) we should be debating exactly what abstractions we want.

Re: In search of the perfect JavaScript framework

#42

Post by ef4 »

wwweston wrote: post #11

> Abstraction is dangerous True statement. Of course, it's more or less true, depending on how much the abstraction you're using leaks. Few (if any) abstractions completely encapsulate complexity, almost all will leak. But there's a range. Some abstractions elegantly cover a modular portion of your problem space and do it so well you only rarely have to think about what's going on under the hood (and will even produc…

No, it's not a true statement. It's fundamentally wrong. Because if abstraction is dangerous, we should all be laying out transistors by hand instead of writing code.

People get so comfortable with their familiar abstractions that they forget they're still abstractions.

Taking the article as an example, even his "less abstracted" examples are absurdly abstract, and I doubt anybody here can really say for sure how they work completely, underneath all the abstractions. That's a good thing, because it lets us get things done and express ideas in hardware-independent ways.

Re: In search of the perfect JavaScript framework

#43

Post by Bahamut »

ef4 wrote: post #42
wwweston wrote: post #11

> Abstraction is dangerous True statement. Of course, it's more or less true, depending on how much the abstraction you're using leaks. Few (if any) abstractions completely encapsulate complexity, almost all will leak. But there's a range. Some abstractions elegantly cover a modular portion of your problem space and do it so well you only rarely have to think about what's going on under the hood (and will even produc…

No, it's not a true statement. It's fundamentally wrong. Because if abstraction is dangerous, we should all be laying out transistors by hand instead of writing code. People get so comfortable with their familiar abstractions that they forget they're still abstractions. Taking the article as an example, even his "less abstracted" examples are absurdly abstract , and I doubt anybody here can really say for sure how th…

Abstractions are dangerous - if you abstract wrong, your code is potentially worse than the unabstracted version since it is easy to impose an abstraction where there is none, but a poorly abstracted component is harder to correct.

Re: In search of the perfect JavaScript framework

#44

Post by blktiger »

nilliams wrote: post #16
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…

Yep the Ember team also seem to have come to the same conclusion on 2-way bindings. My dumb takeaway is something like '2-way bindings demo well but are rarely what you actually want in real apps'. I think (not 100% sure) Tom & Yehuda (of Ember) talk about how they became disenfranchised with 2-way bindings in their recent Changelog podcast episode on Ember 2 [1]. [1] http://thechangelog.com/131/

If I remember correctly, the Ember team isn't planning on abandoning two-way bindings. They simply want to give the developer control on when to use two-way bindings and they are going to make one-way bindings the default. That way you can decide if you need live updates or if data-flow control is better.

Re: In search of the perfect JavaScript framework

#45

Post by ahoge »

carsongross wrote: post #39
ahoge wrote: post #37

Earlier quoted context omitted.

> Well, it's a library, not a framework: you can use it for as much or as little of your app as you like with as little as a single attribute declaration doing something useful for you. If it has an entry point, it's not a library, it's an application. If said application does basically nothing on its own and you're supposed to extend it, it's a framework. http://en.wikipedia.org/wiki/Software_framework Pay close att…

Ah, OK. Well, good news: intercooler doesn't have an entry point. Good point on the concatenation issue, I'll fix it for the next release.

> intercooler doesn't have an entry point.

It does.

There is an IIFE which is run when the script is loaded. Right before the object is returned to the global "Intercooler" variable, a callback is registered via a jQuery.ready() shorthand.

Practically speaking, this callback is the entry point (theoretically, it's the IIFE itself).

If it wouldn't have an entry point, adding attributes to elements would do nothing.

http://en.wikipedia.org/wiki/Entry_point

"an entry point is where control enters a program or piece of code"

Re: In search of the perfect JavaScript framework

#46

Post by juliangregorian »

weego wrote: post #7
carsongross wrote: post #2

My theory is that, for much of the web, the perfect javascript framework is no javascript framework. Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON. That's intercooler.js: http://intercoolerjs.org Here's an image I tweeted trying to explain how to get there mentally: https://pbs.twimg.com/m…

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.

Re: In search of the perfect JavaScript framework

#47

Post by juliangregorian »

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.

Re: In search of the perfect JavaScript framework

#48

Post by aikah »

Bahamut wrote: post #43
ef4 wrote: post #42

Earlier quoted context omitted.

No, it's not a true statement. It's fundamentally wrong. Because if abstraction is dangerous, we should all be laying out transistors by hand instead of writing code. People get so comfortable with their familiar abstractions that they forget they're still abstractions. Taking the article as an example, even his "less abstracted" examples are absurdly abstract , and I doubt anybody here can really say for sure how th…

Abstractions are dangerous - if you abstract wrong, your code is potentially worse than the unabstracted version since it is easy to impose an abstraction where there is none, but a poorly abstracted component is harder to correct.

ANYTHING done wrong can be dangerous,abstraction or not. The problem isn't abstraction but "poor code",whatever it means. spec writers chose to go with the DOM,which is a poor API and it led to things like DHTML because DOM just sucked. It was clearly not made for what devs are doing with the web today,thus the need to abstract a bad API with a framework or a library.

I bet you don't write web apps adding DOM nodes to the DOM document.You're already using an abstraction if you're using any DHTML api.But you didn't know that.

Re: In search of the perfect JavaScript framework

#49

Post by itsbits »

I don't agree with DOM event handling: setting events at every node comes with a cost. And I think you forgot to mention the performance issues with that approach and so now a days almost all frameworks prefer to event delegation.

I think author except in 1,2 points didn't bother to take side with performance aspects.

Re: In search of the perfect JavaScript framework

#50

Post by ef4 »

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.

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.

Post reply on HN