Hacker News Reader

Comment by schizoidboy | Hacker News Reader

> For your SPA logic, you will want a rich model of objects that represent your domain and its rules. And you still need the same for your server logic. And this recipe is just a duplication waiting to happen.

Great article overall but one premise I question is: how often do you really need a non-jQuery JS framework at all in the client?

It seems to me that most apps are simple CRUD apps and server-side rendering is sufficient. Sprinkle in jQuery for simple client functions. Use jQueryMobile for the SPA framework which improves performance by making an AJAX request for any navigation and replacing the page body (instead of doing a full page reload).

I recommend only moving to a full non-jQuery based framework if the design or functions require it (and question that) or the app evolves to require it. As fast as computers, phones, and the internet are today, doing server-side rendering seems good enough for most apps.

View on HN

In jquery programming there’s a huge difference between how the stuff that shows up when loaded is programmed (on the backend) and how the changes you make after it’s loaded are programmed. This leads to a lot of weird inconsistency if you’re doing anything more than showing and hiding existing content. Also, with jquery everything involves a lot of imperative programming and stashing state in random places in the DOM. If you’re doing anything more complex than drop downs and modal windows, use a frontend framework or your code will devolve into a huge pile of spaghetti.

It's not necessarily the case that jQuery code devolves into a huge pile of spaghetti. It's very possible to stay organized without a framework, even for fairly sizable JavaScript apps. It takes a bit of foresight and thinking ahead and discipline, (usually resulting from having written piles of spaghetti in the past). But most large jQuery in the wild is indeed spaghetti, with that I will concur.

Yea, you can write your own framework to avoid it becoming spaghetti. But most developers are going to mess it up. I've seen a lot of bad jquery apps and a lot of bad react apps. The bad react apps, they might be hard to understand, but at least they behave consistently.

> by making an AJAX request for any navigation and replacing the page body (instead of doing a full page reload).

This sounds like the "pjax" idea. I did this recently in a prototype; it's about 30-40 lines of JS (not including a shim for the pushstate-API) and maybe a dozen lines in the backend. It just works(R), and makes things as fast as the backend can deliver stuff. Much faster than stuffing hundreds of kB of framework CSS/JS down the browsers throat for each click, and far more simple than any JS-SPA-frontend-bingo-stack.

You can go one step further and ask, if jQuery does the job for you, why do even need it? The core problems it solved (cross-browser reliability and DOM selections) aren't really problems anymore.

Not that your point is invalid - many people do jump into modern frameworks for sites and apps that are simple enough to not need them. And SPAs don't need to be anywhere near as complex as this article proposes. But if you are going to go down the road of recommending simpler architectures, without a framework approach, then commit to it fully, and just go with vanilla JS.

jQuery makes it easier though, particularly if you know it well.

Reply on news.ycombinator.com