Live data from Hacker News

Drop jQuery as a dependency from Rails

github.com

111–120 of 123 posts

Re: Drop jQuery as a dependency from Rails

#111
post #36

Earlier quoted context omitted.

Rails is a full-stack framework. One of its strengths is that out of the box you have everything there - database integration, http layer, also JavaScript. Having said that - you have a choice. Rails is about defaults. By default it gives you jQuery, CoffeeScript and TurboLinks, but you don't have to use it at all. I've built a number of Rails apps and most of them use CoffeeScript, but don't use TurboLinks. It took…

First thing I do when creating any Rails app is take out Turbolinks. It's like autopilot.

Turbolinks seem really great for the user. What do you not like about them?

Re: Drop jQuery as a dependency from Rails

#112

Earlier quoted context omitted.

I agree it's not the complete solution, but I think rails does a pretty good job at providing tools for making a progressive webapp. Many of us see the apps that have a blank page until data is loaded and the front end JS then renders. It's just a yuck experience. I dislike the fact that it happens in one of my own projects. While I find the concept of turbo links weird with pulling raw html over XHR and then renderi…

The "blank page" argument was once fairly compelling, but both React and Ember (that I know of) have been increasingly successful at solving that issue.

For sure. I've found getting that to work with a rails stack & webpack setup to be rather challenging. react_rails is pretty straight forward, but then you have a lot of global react components, and it gets trickier to leverage NPM. With webpack there's react_on_rails which is a sizable & complex gem, but it does work.

While I wouldn't use vanilla rails & UJS much today, I still think it has value in getting things going.

Re: Drop jQuery as a dependency from Rails

#113
post #18

I never understood why rails has javascript helpers at all. It just does not bring any value in the long run, just complicates stuff. Rails should be js libraries agnostic and not provide any js related helpers out of the box in my opinion.

I'm one of the (formerly) silent, happy masses who uses the default stack gleefully. Turbolinks is amazing, ujs is wonderful, and coffeescript is adequate until all the latest JS goodness is out for real. Make it so only the first page load happens as an HTML request, everything after that happens via ajax for a couple lines more code sprinkled throughout, and I still get the regular html fallbacks? Yes please.

I'm able to quickly make entire complex interaction flows happen smoothly and maintainably on a single page. Now, there's a point, where when you have to start maintaining the state of various widgets on the page with each other, it gets pretty iffy and its helpful to bust out React. But even then, it's actually usually quicker to prototype out the templates/api for the widgets using vanilla Rails.

The javascript helpers that Rails have are wonderful because they let me quickly build useful software for people, and the fact that they're idiomatically consistent with the Rails request/response setup (is it an html response, or a js one?) throughout projects and apps cuts out a ton of cost of me or other developers (some who'd never even used it before!) dropping back into code I've written later to efficiently change things. Not, "what's being used here? What's the api for that? how is this set up?" etc etc.

I've found that, across many projects with many people, in the long run, these JS helpers are amazingly helpful and clarifying. So I'm going to have to firmly - but respectfully - disagree with your opinion that Rails shouldn't include them, simply because your opinion doesn't provide an alternative that gives me better benefits than what's currently there. It just strikes me as though it will divert engineering on actual hard problems of value to a lot more of simply engineering for engineering's sake. I'm not saying I won't change my mind...I'm saying, show me something better, and let's talk!

Re: Drop jQuery as a dependency from Rails

#114
post #82

Earlier quoted context omitted.

It does help with browser quirks, but if you aren't supporting <IE10, then you really don't need it. I've made it a point to pull out jQuery from every project I have. Nowadays, I can test in Chrome as I develop and then test any other browsers at the very end and I rarely have any browser specific bugs. Crazy how far web dev has come.

You do really need it, at least for me. I'd rather write $ sign calls instead of getElementByID or querySelector just to start with. The sizzle library in jQuery is so advanced, that you can't do complex queries on the dom yet with today's browser.

the industry is moving away from direct DOM mutation and towards v-dom, so this isn't an issue for a lot of devs.

Re: Drop jQuery as a dependency from Rails

#115

Earlier quoted context omitted.

This is one of the best things about Django - outside the admin interface it's not opinionated about your frontend setup.

Of course "not opinionated" in this case is an euphemism and really means that Django doesn't help you at all and so you have to suffer the incomplete and abandoned middleware of others to have something that resembles an asset pipeline. And that's actually odd, because both Rails and Django are frameworks born for building frontends to MySQL databases, which means these frameworks really are about HTTP 1.1 frontend…

Django wants to provide solutions that will stick around for longer than the attention span of the js community ;-)

Getting opinionated about js stacks at the moment could backfire hugely and alienate a chunk of their userbase. The policy is basically "Stuff should be left as 3rd party apps until a de facto winner emerges."

Not sure if that's likely to happen any time soon in anything related to front end code so keeping the core framework neutral seems like the best option. Mini-ecosystems can arise where neccesary.

Re: Drop jQuery as a dependency from Rails

#116

Rails should stop messing with Javascript all together. Drop JQuery, CoffeeScript, TurboLinks and what not and let the users decide what to use, make it optional. Rails shouldn't require a JS engine in order to run.

This is one of the best things about Django - outside the admin interface it's not opinionated about your frontend setup.

Django models are nice and easy to work with for the most part, and the template inheritance is great for building out front-ends. But there's a lot of "Django magic" that goes on behind the scenes so I tend to think of Django as an opinionated front-end. Django forms and how they are handled give me nightmares.

Re: Drop jQuery as a dependency from Rails

#117
post #7
post #4

Earlier quoted context omitted.

Is this a legacy thing? I'm a web dev for 10 years now and never used jQuery directly. (I used Ember for half a year, which seems to have jQuery as dependency)

If you've been a web dev for 10 years then you'll know that the most fundamental tool for scripting is a pain point (document ready), jQuery did a good job of abstracting the nuances away, see: http://stackoverflow.com/questions/799981/document-ready-equ...

Document ready is hardly the most fundamental “tool” for scripting, and it has always been easy to resolve in a cross-browser way: stick your scripts before .

Re: Drop jQuery as a dependency from Rails

#118
post #82

Earlier quoted context omitted.

It does help with browser quirks, but if you aren't supporting <IE10, then you really don't need it. I've made it a point to pull out jQuery from every project I have. Nowadays, I can test in Chrome as I develop and then test any other browsers at the very end and I rarely have any browser specific bugs. Crazy how far web dev has come.

You do really need it, at least for me. I'd rather write $ sign calls instead of getElementByID or querySelector just to start with. The sizzle library in jQuery is so advanced, that you can't do complex queries on the dom yet with today's browser.

There are small libraries that help with making native DOM operations more jQuery-like. We opted just to write our own since we didn't need a good portion or even the smaller libraries.

Re: Drop jQuery as a dependency from Rails

#119
post #49

Earlier quoted context omitted.

Which version did you use? I only used ExtJS 4 and 4.1 I liked their API documentation and the xtypes that allowed for declarative Views. React reminded me of this later.

I started on 3(.5?) and helped with a migration to 4 (which was a disgusting mistake of a process on our end). I like the format of their docs -- JSDuck was my favorite docset for a quite a while. I also enjoyed their methodology for constructing views and view hierarchies. Ultimately, I'd say I was a fan of what they were doing, I just think the implementation was rather shoddy, and the docs were frequently wrong or…

Ah yes.

I read about those problems.

First they changed the license then the switch from 3 to 4.

This cost them many customers.

I started with 4, so I didn'T encounter these problems.

Re: Drop jQuery as a dependency from Rails

#120
post #111

Earlier quoted context omitted.

First thing I do when creating any Rails app is take out Turbolinks. It's like autopilot.

Turbolinks seem really great for the user. What do you not like about them?

One problem I've run into is that the Javascript state isn't reset when Turbolinks pretend-reloads the page. This can lead to "interesting" bugs if setInterval() calls or websocket-rails response handlers hang around when you navigate away from the page that they "expect" to be run on.

Attempting to reproduce these errors by refreshing the current page and repeating whatever you just did will not work, since the Javascript state will be wiped clean - you'll need to navigate through the same path that you took to get to that page in the first place. (This happened to me recently; as you may imagine, it took me a while to figure out what was going on!)

It's possible to work around this by "cleaning up" whenever a Turbolinks change event fires, of course, but the point is that you can't just add Turbolinks to your project and expect everything to work as it did before.

Post reply on HN