In search of the perfect JavaScript framework • Hacker News Board

Re: In search of the perfect JavaScript framework

#71

Post by rapind » Sun, Feb 08, 2015, 2:42 PM UTC

thirdsun wrote: post #18

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…

As a developer that recently made the transition from FileMaker, which is very user-friendly but limiting, to Rails, I love the new possibilities and the fact that Rails provides nearly everything I need and comes with established best practices, but I'm always a little helpless when interactivity (without reloading the page) is required. The apps I'm working on (internal, business apps) mostly work perfectly fine wi…

You might want to play with React and it's ilk. It's basically a framework for only the view, and it's pretty easy to reason about once you wrap your head around it. You're just asking for calculated fields on change events right?

jQuery is fine for this too, but can become painful to use and organize once you have a lot of DOM manipulations.

React only starts to get complicated once you dive into the Routing + Data Fetching + Flux stuff IMO. React on it's own if you don't need any of that is pretty simple.

Re: In search of the perfect JavaScript framework

#72

Post by davej » Sun, Feb 08, 2015, 3:11 PM UTC

danabramov wrote: post #20

nilliams wrote: post #16

Earlier quoted context omitted.

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/

I think marketing is also a problem here. Even frameworks that realize shortcomings of two-way bindings feel compelled to support them because it's hard to educate newcomers to abandon their old ways. “Two” looks better than “one” on a feature checklist. Quoting Sebastian Markbåge from React, “Angular is intuitively better to most engineers based on previous experience and ideals. React is better in practice. This is…

Two-way data binding is not inherently a bad idea. In fact, it's awesome in many cases, especially forms and form-like elements.

The problem is that people have a habit of misusing them and start using two-way bindings where they should be using events or similar patterns.

Re: In search of the perfect JavaScript framework

#73

Post by mathgeek » Sun, Feb 08, 2015, 3:29 PM UTC

I was slightly disappointed that this didn't point to a 404.

Re: In search of the perfect JavaScript framework

#74

Post by tel » Sun, Feb 08, 2015, 3:38 PM UTC

The whole "abstraction is dangerous" spiel is so wrong (imo) that I don't even know how to respond to anything that follows.

The primary complaint appears to be that abstraction eliminates your ability to operationally trace the meaning of a program. This is true, but sacrificing operational denotations only hurts if you replace it with nothing else—and abstractions of general purpose languages are almost always more interpretable than the operational denotation of the base language itself!

Of course, there are always places for poor abstractions. I am not talking about these. Abstractions which are intentionally opaque, have confusing action-at-a-distance, etc---you're bringing down the name of abstraction in general. "Leaky" is insufficiently demeaning.

A good abstraction will have its own semantics. These can be equational, denotational, operational, what-have-you but, essentially, these semantics must be easier/simpler/more relevant than the semantics of the base language they're embedded in. Otherwise why abstract?

So what does React give you? It gives you, more or less, a value-based compositional semantics. Components have some "living" nature (an operational semantics w.r.t. to state) but they're mostly defined by their static nature. Because you can build whole applications thinking only about the static, compositional nature of components you can take massive advantage of this abstraction.

Ultimately, you do not want operational semantics for React. This is what gives us React Native, background rendering, and probably what will lead to sensible animations (in time). To define operational semantics, especially ones which have to look like or (worse) be identical to those of Javascript, would destroy almost all possibility of extension. At the cost of making things more complex and harder to reason about.

All so that you can just stick to "obvious" Javascript base operations.

Re: In search of the perfect JavaScript framework

#75

Post by _pmf_ » Sun, Feb 08, 2015, 4:54 PM UTC

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…

>> "Abstraction is dangerous" >The fact that Javascript people keep saying this with a straight face is getting really absurd.

I stopped expecting anything of value in the article after reading this in the introduction, too.

Re: In search of the perfect JavaScript framework

#76

Post by mercer » Sun, Feb 08, 2015, 6:55 PM UTC

padolsey wrote: post #56

zak_mc_kracken wrote: post #55

Earlier quoted context omitted.

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

I'd say not having to worry about 'crafting your own selector engine' and stuff like that leaves you free to spend you creativity on things that are a bit higher on the abstraction ladder. Yes, it makes things that once required creativity more boring, but shouldn't that be cause for excitement that you can now be creative about other things?

Re: In search of the perfect JavaScript framework

#77

Post by mercer » Sun, Feb 08, 2015, 7:00 PM UTC

thekingshorses wrote: post #28

I like the direction author is going. I have used similar methodology designing my applications (for mobile), simple, micro libraries, one way data binding. http://hn.premii.com/ http://reddit.premii.com/ * I have bunch of helper functions (UI and non-UI). Each function define in its own file and independent (easy to unit test). Personal library like jQuery but not a jQuery replacement. * App is route based. One rout…

Thanks for creating hn.premii.com! About half my use of Hacker News is through your web app. I even wrote a little bookmarklet that turns all links on hn.algolia.com and hckrnews.com into links to your app when I happen to be browsing on mobile! And I'm always happy to find out you introduced a new feature (which I would like to see more regularly, not that I'm complaining!).

Alongside Alien Blue, your app is my most used app on my phone. Your work is very appreciated!

Re: In search of the perfect JavaScript framework

#78

Post by _asummers » Sun, Feb 08, 2015, 7:08 PM UTC

untog wrote: post #6

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…

Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously You can't just say "remove local state and use HTTP instead" - people didn't invent local state from nowhere, it has a lot of advantages to relying on an HTTP call for everything you do. Particularly when you're scaling out widely or when you're dealing with mobile devices.

Or when dealing with some of the offline features of HTML5. Those are literally impossible to do without some local state.

Re: In search of the perfect JavaScript framework

#79

Post by [deleted] » Sun, Feb 08, 2015, 8:14 PM UTC

aikah wrote: post #48

Bahamut wrote: post #43

Earlier quoted context omitted.

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

[deleted]

Re: In search of the perfect JavaScript framework

#80

Post by lastofus » Sun, Feb 08, 2015, 8:46 PM UTC

thirdsun wrote: post #18

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…

As a developer that recently made the transition from FileMaker, which is very user-friendly but limiting, to Rails, I love the new possibilities and the fact that Rails provides nearly everything I need and comes with established best practices, but I'm always a little helpless when interactivity (without reloading the page) is required. The apps I'm working on (internal, business apps) mostly work perfectly fine wi…

I found Knockout to be a great middle ground for when "I can do this in jQuery, but it's gona be messy" and "I'm building a SPA".

It hits the sweet spot between easy learning curve, abstraction, and interacting with the DOM nicely.

Sadly, it's not as hip as React/Angular/Ember these days.