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

21–30 of 85 posts

Re: In search of the perfect JavaScript framework

#21

Post by dustingetz »

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…

While I have been using React since it launched in May 2013 and I agree with a lot of what you said, using words like "right" and "wrong" doesn't help. React is a great way to write applications but it isn't the most mature library ever, and the junior developers I worked with had quite a bit of trouble working with it for a while because functional programming is so different. The ecosystem is filling in, things are great, but "you are wrong and I am right" harms as much as it helps.

Re: In search of the perfect JavaScript framework

#22

Post by carsongross »

failed_ideas wrote: post #5
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…

I'll be honest, I'd be much more receptive to you doing a show hn over pimping the framework in the comments of every js post.

Fair enough.

Re: In search of the perfect JavaScript framework

#23

Post by fastball »

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 that my experience with Dart seems to meet those criteria nicely.

https://www.dartlang.org/

Re: In search of the perfect JavaScript framework

#25

Post by danabramov »

dustingetz wrote: post #21
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…

While I have been using React since it launched in May 2013 and I agree with a lot of what you said, using words like "right" and "wrong" doesn't help. React is a great way to write applications but it isn't the most mature library ever, and the junior developers I worked with had quite a bit of trouble working with it for a while because functional programming is so different . The ecosystem is filling in, things ar…

Of course there isn't a “right” or “wrong” way. I'm sorry I didn't write it more clearly.

Approaches like jQuery soup or making SQL queries from PHP templates aren't “wrong” either. They are friendlier to beginner, too.

When I wrote “wrong” I meant “in my experience, inferior for building applications with complex stateful user interfaces and later maintaining them for a period more than several months in the face of changing requirements”.

Also, I'm not talking specifically about React. Of course it has its own shortcomings. All I'm saying is that relying on `Object.observe` and giving out global state to all components to mutate is the same as using global variables throughout the program. I don't know whether it is helpful to call global variables “right” or ”wrong” but I'd certainly stay away from them when there are ways to achieve the same without future maintenance nightmare.

Re: In search of the perfect JavaScript framework

#26

Post by mark_l_watson »

A difficult article to write - I would not have tried. There are so many good alternatives and choice depends on the application and available skill sets.

I spent time today working in Clojurescript which wraps the Closure library. In the last month I have used Ember.js, Clojure with hiccup, and meteor.js. I really like all of these tools and frameworks. I used to use GWT a lot, and almost committed to Dart. So many good choices.

Re: In search of the perfect JavaScript framework

#28

Post by thekingshorses »

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 route to many controllers. Each controller is a page/screen on mobile.

* There is only one model (API) that interface with 3rd party library. API layer talks to 3rd party library to get data or gets data from server directly, caches data, etc. Provides sync (Cached data) and async (Cached data or fresh from server) interface to controllers.

* There is a app class or I call it a page manager. Responsible for managing pages like ordering, loading, unloading etc (Kind of big and complex 200+ lines of logic).

- Decides which page to animate in which direction on mobile (Loading new page or going back).

- Order of pages (Back button)

- Passes events to its controllers

- Decides which pages to keep in DOM, and which to remove.

--- If you go from homepage to comments to profile page, all pages are in DOM.

--- When you go back to comments page from profile page, profile page will be destroyed and controller will be notified. Same happens when you go from comments to home page.

--- If you go to same comments page again, it will be loaded as a new page.

* Controller:

- Each controller may have multiple CSS and templates

- Controller uses its template to render

- Using sync API to get data to renders page.

- If sync API returns no data, renders empty page with loading, and makes async API call.

- Controller are idle when transitioning (animating) from one page to another on mobile. (Very important for smooth animation)

- Simple but fat controllers

- Controller handles events, UI logic

- Self cleaning so that browser can collect garbage when necessary

I package app using node/gulp. Anything that is not specific to page/app related, it becomes part of a helper library. Each app has its own model (Data layer), and controllers. I use micro templates, precompile using node for faster performance.

Re: In search of the perfect JavaScript framework

#30

Post by wereHamster »

dustingetz wrote: post #21
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…

While I have been using React since it launched in May 2013 and I agree with a lot of what you said, using words like "right" and "wrong" doesn't help. React is a great way to write applications but it isn't the most mature library ever, and the junior developers I worked with had quite a bit of trouble working with it for a while because functional programming is so different . The ecosystem is filling in, things ar…

You don't need to understand functional programing to use React.
Post reply on HN