Comment by payne92 | Hacker News Reader

Comment by payne92 | Hacker News Reader

Parent Full thread

TL;DR OP chose Ember for a small project, found himself [1] "fighting with Ember a lot", and felt that it would have been easier/quicker to build just a Rails CRUD app in the first place.

This is a standard challenge with any framework, but the issue is especially acute in Javascript-land.

Many JS libraries and frameworks exist to cover missing libraries and functions that would be "batteries included" in other languages. As core JS has evolved (along with CSS), the value of those frameworks decreases, but their legacy is deeply present in Github, StackOverflow discussions, and other libraries.

JQuery is one example: a minuscule wrapper around document.querySelectorAll() plus ES6 arrow functions gets you 75% of the way there, without having to understand how/where JQuery is being "clever" in various event handling corner cases.

Bootstrap is another: flexbox is not perfect, but it replaces a lot of CSS cruft and JS hackery.

Moral: above and beyond the usual tradeoffs for framework decisions, make sure the framework/library is still as relevant today as it was N years ago. Don't just go with inertia.

[1] The author's name is "Matt".

> Don't just go with inertia.

Well. Inertia is powerful: A new project I start in jQuery today? Next to 100% chance I can pick up a dev who has seen jQuery, even in three or four years. Worldwide.

A new project I start in AngularJS or whatever is the current fad? Good luck if the framework hasn't done yet another BC break or hasn't vanished into oblivion by then.

At this point, I think React seems popular and stable enough that there's not much of a point in going with jQuery for the sake of stability/popularity. And there's still a huge pool of people with AngularJS 1.x experience, too. What's more important, in my opinion, is what tools are going to be easiest for you and/or your current team to get stuff done.

OP's note and my comment are about considering the option of no framework.

Instead of choosing JQuery (on inertia) or the current fad, consider just using current base language features and best practices.

It might be a better choice.

As a bonus, to your point, you're then far less worried about finding future devs with your library/framework-specific experience.

I've seen jquery code that looked like spaghetti, it was very hard to read or change even if you knew jquery. This is the problem that most libraries and frameworks tries to fix. I think react has succeeded.

> JQuery is one example: a minuscule wrapper around document.querySelectorAll() plus ES6 arrow functions gets you 75% of the way there, without having to understand how/where JQuery is being "clever" in various event handling corner cases.

jQuery predates querySelectorAll - that's why it's so popular. It sticks around because now it's to JavaScript what Boost is to C++: things that are needed a lot of the time that the official standard library moves too slowly to add themselves. I don't use jQuery myself anymore, but if the DOM added support for "element collections" and if JavaScript added lodash-style functional methods to all collection types (e.g. if `Array.prototype.map/forEach/filter/etc` worked on NodeList) then we'd be fine.

That was exactly his point.

Thanks for the tl;dr :) this post did run a bit longer than I planned

> himself [1]

> [1] The author's name is "Matt".

I hate to say it but these days you just can't assume the previously obvious.

Reply on news.ycombinator.com