Live data from Hacker News

Drop jQuery as a dependency from Rails

github.com

31–40 of 123 posts

Re: Drop jQuery as a dependency from Rails

#31

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.

I've found this problematic in Django: How to integrate a good JS frontend that isn't at odds with the built-in templating system. Offloading the templating to React (eg. node / JSX) seems like a good bet -- but then your Django app is little more than a REST API.

I'd love to see some good, practical examples of a full-featured (ie. integrated) Django app with a js frontend. Pointers welcome!

Re: Drop jQuery as a dependency from Rails

#32
post #7

Earlier quoted context omitted.

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...

And the incompatible ajax interfaces. And the inconsistent element selection. And the... I'm also not sure I'd call document ready the most fundamental as a lot of people (including me) used to use onclick='' and onload='' directly on elements back then when we all loaded script tags in the head.

I know these problems, yes.

But I didn't hit them, because I mostly did everything on the server side.

When I switched to SPAs, I used ExtJS.

Re: Drop jQuery as a dependency from Rails

#33
post #24
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)

I would say no. It's everywhere. Even as you mention it's a common dependency or comes bundled with a lot of stuff. I have not sat down and written logic that "does the same thing in more than one browser" in a very long time but I'd venture to guess the part of jquery that is browser javascript api abstraction is still very relevant today.

Interesting :)

To me it always felt kinda strange seeing all these jQuery Stackoverflow questions and answers.

When I switched from server side rendering to SPAs, I had the impression everyone was already hating on jQuery and avoided it. I read "Pro JavaScript Techniques" and "JavaScript the good Parts" and started my JS career :)

ExtJS 4 came out and I did my first SPA with it.

Later I did some university projects with Ember, which seems to use jQuery, but I never had to call one of its functions directly.

After that I started freelancing and ended up in a React project, which I found kinda nice to work with.

Re: Drop jQuery as a dependency from Rails

#34
post #20

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.

I think you're right if Rails was built for "production" applications. However, the way most people tend to use Rails is a prototyping framework. The nature of Ruby and the vast ecosystem of components (gems) makes building something very quick. It is definitely my go-to solution If I want to experiment with an idea. The problem is if the prototype is successful, it becomes the production system and all the things th…

"There is nothing so permanent as a temporary solution"

Re: Drop jQuery as a dependency from Rails

#35

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…

Right. The frontend story of Django is non-existent and it is a pain to reinvent the wheel each time. Need AJAX to work with CSRF protection? Just copy this snippet of code. Want to use SASS? Try to find a django app that provides an asset pipeline, or copy some django snippets, or do it yourself by bringing grunt/gulp/whatever is the latest hyped js build tool.

Now the remaining part of your comment is unfair. Pure frontend is just one small part of webapp development: templating, controller, ORM, i18n, user and session management, security, testing, etc.

You can do a lot of web backend stuff without websocket. Django is ok for that and if you combine it with Django Rest Framework, you get powerful tools at your disposal.

Re: Drop jQuery as a dependency from Rails

#36

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.

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 me just a few seconds to remove it from my Gemfile.

Also, Rails API project is a subset of Rails that does not require JS (it was merged to Rails so you'll be able to generate API application in Rails 5).

Re: Drop jQuery as a dependency from Rails

#37
post #27

Earlier quoted context omitted.

You're missing the central point of default rails stack. http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

Sure, except in this case the Rails defaults are totally at odds with how the larger JS ecosystem has evolved. CoffeeScript was basically the logical complement to Haml (Ruby-like syntax for HTML) and Sass (Ruby-like syntax for CSS) -- although Sass has since dropped its original syntax and moved on with the CSS-like SCSS. Since then CS has lost a lot of popularity outside the Rails community. Babel and TypeScript pr…

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 rendering it, it does essentially just speed up a non-js capable website.

In time rails will need to replace this out, as the JS tooling keeps evolving, better solutions will arise.

Re: Drop jQuery as a dependency from Rails

#38
post #21

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.

Same thing with Grails, though they've improved support for Angular lately. I prefer vanilla js anyway, its what I used 15 years ago, and it is what I will continue to use the next 15 years and hopefully a lot longer.

OTOH Grails 2 invites people to use the awful formRemotes, which apparently are an idea lifted from old versions of Rails, and are a mishmash of html and javascript. Seems quite an opinionated approach on how you should build your frontend.

Luckily Grails 3 dropped it, but the project I'm working on at the moment is stuck on Grails 2... and Grails 3 is a complete rewrite of the framework

Re: Drop jQuery as a dependency from Rails

#39

As a web dev for the last 15 years or so, this is amazing news. The browsers are finally getting to a point where the pain jQuery solved, is going away.

jQuery helps with browser quirks, though. Search the below file for the string "// Support" to see what I mean. Yes, there are a lot of entries for older browsers, but there are also a lot of entries for relatively recent browsers too.

https://github.com/jquery/jquery/blob/3.0.0-rc1/dist/jquery....

Re: Drop jQuery as a dependency from Rails

#40
post #22
post #2

Someone in DHH's position could approach jQuery and request a subset containing what he needs. And then other projects could benefit from the refactor. If there's even a benefit. This same post by the leader of any other project would involve a study of which components and apps use jQuery. And would state how far back compatibility is to be maintained. So, for example, if commonly used gems require it, or if 90+% of…

The problem isn't jQuery, the problem is that 90% of the use cases for jQuery can now be solved with native APIs (or polyfills if compatibility with older browsers is a requirement). The main feature is basically element.querySelectorAll (or document.querySelectorAll for the global version). The XHR wrapper can easily be replaced with the fetch API. Class list manipulation is easy with element.classList. The event li…

> The XHR wrapper can easily be replaced with the fetch API.

Browser support for fetch is still pretty weak, so you'll need some kind of polyfill to use it today.

http://caniuse.com/#feat=fetch

Post reply on HN