[brwr]

Building a website doesn't have to be complicated. You build a Rails site 10 years ago. You probably used jQuery, if you used JavaScript at all. Why can't you do the same today?

The real problem here is that not enough developers understand that "just because you can, doesn't mean you should." Once more of us get a handle on that, life will be better.

[brilliantcode]

> You build a Rails site 10 years ago. You probably used jQuery, if you used JavaScript at all. Why can't you do the same today?

You can and I do. However, I am thinking of using polymer or vue.js as I think they are a much lighter candidate than react.js & angular.

The power of marketing is underrated in the developer circles.

[brwr]

If you still use Rails and jQuery, why both with Polymer or Vue? What is the benefit they give you?

Promise I'm not giving you a hard time. I'm honestly curious if there's something I'm overlooking.

[brilliantcode]

I asked the same question last year and to be honest, building a SPA is tough with just jQuery. It's more of my needs changing, I don't think SPA can be ignored in 2017, the progressive web app and AMP will put a huge dent in the native apps space.

I just like to think that I'm developing a mobile app with front-end javascript framework....it's just the tooling and prerequisite knowledge is quite chaotic. Finding the right articles (up to date) is half the battle, as it's scattered in endless git repo pages.

[brwr]

Run `( find -E ./ -regex '.*\.jsx?' -print0 | xargs -0 cat ) | wc -l` inside your `node_modules/` folder. It counts lines of code in JS files. Prepare to be sad.

[codingdave]

I'm not sure why an SPA with jQuery is tough. $.ajax. Send data. Do stuff in a back-end. Return data. Update divs. If it is tough, you might be trying too hard. I'm not trying to be glib... it just sounds like you might be buying into the over-complexity that the original question was talking about.

[brilliantcode]

it starts to get to be a problem when approaching 1k LOC with multiple developers. The benefit is separating the UI layer from the data layer. I didn't think much of this but the complexity is very real and there's a number attached to this slow & fragile & tightly coupled jQuery app.

If you are using jQuery to build a big SPA with multiple devs, you can certainly do it, but it's not enough. At the same time I'm against over engineered frameworks that imposes high cognitive friction on developers. Vue.js and Polymer hits the right notes for me. I feel that Vue.js is a reaction to React & Redux (seems like the trend is to use it when we don't need it). There will be use cases that makes one more favorable then the other but not many shops are employing 1000+ teams working on FB, therefore the premium you pay to mitigate complexity that you don't have results in loss of productivity, is how I like to think about it.

I won't use something because everyone else is. Often, the majority is wrong and easily influenced by marketing and authority (especially if you are good at lighting billions of dollars on fire to build an elusive monopoly). It happens all the time in dev communities but what makes it worse are the complete lack of insight into why you are not FB or Google. We blindly emulate them hoping to be like them.

I say, approach the problem with a blank sheet of paper. Figure out and evaluate what works for you and your team while watching out for marketing myths and other disinformation from the unicorns.

[flukus]

The problem with jquery is that the state is stored in html elements. It makes it hard to debug, maintain and learn bigger applications. Things like accessing a hidden variable become DOM traversals rather than property accessors.

[codingdave]

jQuery is just a framework, if even that. If you choose to use it to store state in html elements, that is your choice. And yes, a common one. But the framework does not force it. If you make an AJAX call in jQuery, you get JSON back. (Or, I use it to get JSON back... you can send whatever you want back.) You can do whatever you want with that JSON.

Frequently, I do store metadata in a DOM element because the next event I will react to is a click on that DOM element, so I already have a handle on it from the ui element jQuery gives me... I do not have to traverse the DOM. But if the future use of the data is NOT going to be a response to a click on a specific DOM element, then no, I will do something else with the data.

Again, just because everyone else does it doesn't mean you have to, and doesn't mean it is inherent in the tools. I'm not saying jQuery is the best tool out there... I'm saying that complexity in an SPA doesn't come from jQuery itself, but from design choices made with it.

[flukus]

My experience is with c# and knockout, which is pretty similar to rails and vue. I've found the sweet spot to avoid SPA's (which I'm pretty sure you can do with vue). Generate the html server side and only use javascript for the dynamic parts where it makes sense.

[brwr]

Absolutely! Unfortunately, this is very hard to sell to teammates on the SPA bandwagon and management who require all developers to be buzzword-compliant.