Live data from Hacker News

In search of the perfect JavaScript framework

dev.opera.com

51–60 of 85 posts

Re: In search of the perfect JavaScript framework

#51
post #50

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.

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 - events that won't be caught, arrays that use their own iterator, etc.

They decide to suppress language features like console logging and replace it using different names. You never learn this by reading the outdated documentation but by startling discoveries 45 minutes into what ought to have been a 15 second bug.

And let's not get started on how utterly useless the call stack or object inspector becomes.

They presume there are fewer coherent approaches to programming in a language then there actually are so they shoehorn you into writing things in one specific poorly documented, buggy, highly complex, inappropriate, monolithic, and fragile way.

One of the main arguments for the abstraction approach is that they assist average programmers like a golfing handicap. But the reality is that the quality of the programmers work remains the same - but now with the abuse and misuse of the language AND a convoluted abstraction. You are far worse off.

The historical problem is that these things despite all of these clear flaws become immensely popular - each one for about 6 months.

And then your business critical application gets locked in. Locked in to the hottest framework from 5 years ago.

Awesome

btw, I tweet about my hatred of this specific topic here: https://twitter.com/frameworkhater ... I think a proper manifesto may be in order.

Re: In search of the perfect JavaScript framework

#52

>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…

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...

Re: In search of the perfect JavaScript framework

#54
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…

[deleted]

Re: In search of the perfect JavaScript framework

#55

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…

> 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.

So basically go back to writing Javascript like we were doing ten years ago?

No thanks.

I was there, it was hell, I hated every second of it.

The Javascript framework scene is very chaotic today but it's exciting, a lot of new concepts and approaches are being discovered on a weekly basis. A lot of them won't pan out but some will, and they will make writing Javascript even more fun than it is today.

And one thing I know for sure: it's hell of a lot more fun to write Javascript today than it was ten years ago.

Re: In search of the perfect JavaScript framework

#56

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…

> 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. So basically go back to writing Javascript like we were doing ten years ago? No thanks. I was there, it was hell, I hated every second of it. The Javascript framework scene is very chaotic today but it's exciting, a lot of new concepts and a…

I get your point but, for me, it was more fun back then. There was more to hack on; heck, you could craft your own selector engine and people would use it. Awesome. Now, seemingly, all there is to do is build yet another CRUD application with whatever framework is hottest.

Re: In search of the perfect JavaScript framework

#57

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...

I believe the intention is basically "bind to a setter method, not a field." I'm guessing for much the same reasons the same is used in Java: You can change methods. You can add sanity checks, new behavior, etc.

Re: In search of the perfect JavaScript framework

#58
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…

I only read the beginning few sections of the article, but it seems like it IS about "what abstractions are good", as opposed to "abstraction is bad". He's recommending abstractions that let you understand what's REALLY happening, so that you can reason about performance better.
Post reply on HN