News for hackers. Stuff that matters.
Re:The Cost of Frameworks by unabridged on Tuesday November 17, 2015 @06:38PM (#10584832)
To everyone defending JS frameworks: create a challenge that you believe requires a framework and see if someone can solve it more elegantly in vanilla JS.

Years ago when browser compatibility required 100s of workarounds for each browser and version, it made sense to use a framework to hide the complexity and keep up to date. But with modern browsers this just isn't the case.

Re:The Cost of Frameworks by grumblestumble on Wednesday November 18, 2015 @01:04AM (#10586236)
- render a list of items, with a panel showing additional details for the selected item.

- update the view when changes from a backend data source arrive, either via some sort of polling mechanism or a persistent connection.

- allow the user to edit fields on the selected item.

- automatically save any pending changes when navigating away from the page.

AKA every CRUD app ever. You are going to need a framework (most commonly MV*) to deal with this in a maintainable way. Whether you use a vendor or create your own, you will end up with a framework.

Re:The Cost of Frameworks by TimJYoung on Wednesday November 18, 2015 @09:00AM (#10587676)
When you say "vanilla JS", do you mean "just JS with other JS-only libs for special controls, etc.", or "just JS". Because, if the latter is the case, then the challenge is easy:

Virtual list controls that need to manage thousands of items/rows.

Hint: you're going to need a custom scroll bar.

Re:The Cost of Frameworks by lhorie on Tuesday November 17, 2015 @09:56PM (#10585626)
Random things off the top of my head that are a pain without a framework:

- take object of arbitrary depth {a: 1, b: [1, 2, {c: 3}]} and send as querystring parameters to Rails/Node/PHP/whatever backend

- take two parallel ajax calls and run some code when they're both done

- SPA w/ parameterized urls