Live data from Hacker News

This Week in Rails: jQuery no longer part of Rails, and more

weblog.rubyonrails.org

101–110 of 143 posts

Re: This Week in Rails: jQuery no longer part of Rails, and more

#101
post #86

Earlier quoted context omitted.

> No, that's simply not true. Wow, really?! I stand corrected! I'm glad you took the time to bestow this illuminating perspective. Here I am thinking that 20k+ files for a Hello World App was a bit much but your response really cleared things up for me, thanks!

Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum. > Here I am thinking that 20k+ files This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind o…

I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies. It literally takes minutes to download everything which I've had often fail. npm installs of SPA templates are one of the few things that can cause my MBP CPU to burn and HDD to thrash for long periods of time where I'd expect it to consume a non-trivial amount of energy.

The fact there's so many deps mandates additional tooling to manage and bundle them down to a manageable number of deps during development.

Facebook's recommendation for a hello world app [1] wants you to use their package manager, Webpack, Babel, Flow, a Linter, CSS preprocessor, their test runner, an embedded HTTP server just for starting off, building any meaningful App requires more dependencies where eventually you'll also consider a module loader. Then you're going to need to package/deploy your App and if you go off-script you'll need to manage and understand how all the different moving parts work together which you'll also need to know when wasting time chasing down dependency conflicts and tooling integration issues after package updates.

Your point about their being only 2 dependencies is completely inconsequential for development and shows inexperience in the recommended state of the art React SPA development.

[1] https://github.com/facebookincubator/create-react-app/blob/m...

Re: This Week in Rails: jQuery no longer part of Rails, and more

#102
I somehow still seem to need jQuery. Mainly because I need to use a UI component, and out there one already exists, which does exactly what I need. So jQuery gets in as a dependency. Maybe because I have used it for more than 8 years now, I seem to know the jQuery based components well.

Especially times when one needs things like https://fullcalendar.io/ and Kendo UI jQuery becomes a required dependency.

To those, how to you program enterprise systems, without jQuery? Do you any mature UI toolkits which don't depend on jQuery? I am genuinely interested in knowing about these.

Re: This Week in Rails: jQuery no longer part of Rails, and more

#103
post #21

Earlier quoted context omitted.

Although the comparison isn't perfect, you can think of jQuery as PHP in the late 90s and early 00s. PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999. In the same vein, jQuery filled a very important niche when the web was just getting started. It made Javascript accessible, by s…

>PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999. PHP didn't make it easy. It made it possible. Until fairly recently, getting a VPS was insanely expensive, so any learner, hobby, startup went to shared hosting. As a result, any tech which required starting servers or elevated p…

There were a few CGI script websites around, like Matt's Script Archive and his (in)famous FormMail.pl.

There were also URL libs, eventually, as well as other CGI-specific tools, like counters, banners etc.

You are right that PHP was the logical simpler choice, and it did take off in the second half of the 90s. But for the best part of the decade the web was built on CGI.

I would argue that the CGI era was a good one. Writing a CGI required low-level knowledge of HTTP, HTML, how web servers worked, and very likely knowing your way around a UNIX system. Solid skills, that are still useful today, marked a high bar which raised the overall level.

Furthermore, the nature of CGIs made for better architectures. Simple entry and exit points, dedicated services. Connecting them to something else required careful consideration. They made you gravitate naturally towards KISS, REST and other best practices which are still observed today.

I would also add that there were several other hobbyist fields popular at the same time, like MUDs (usually built in C) or IRC servers/clients/bots (also Perl/C/TCL) to name just a couple. Knowledge gained in one of them lent itself fairly easily to another.

Re: This Week in Rails: jQuery no longer part of Rails, and more

#104
post #28

Pour one out for jQuery! jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentize…

I think what drives me nuts is that so often jQuery+Bootstrap would deliver a faster quicker product. While the big frameworks are incredible, they really are designed [1] for really large applications, ala Angular and Gmail. But, I see them being pushed onto what would otherwise be very simple projects: static websites, sites with a single contact form, etc.

1 - http://www.planningforaliens.com/blog/2016/04/11/why-js-deve...

Re: This Week in Rails: jQuery no longer part of Rails, and more

#105
post #21

Earlier quoted context omitted.

Although the comparison isn't perfect, you can think of jQuery as PHP in the late 90s and early 00s. PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999. In the same vein, jQuery filled a very important niche when the web was just getting started. It made Javascript accessible, by s…

I apologize in advance and mean no disrespect, but I think this analogy is terrible. PHP was browser-agnostic. PHP was a flawed tool that existed alongside other tools, and survived based on various merits and despite various drawbacks. jQuery was a life preserver. Javascript is wholly browser dependent, and at the time of its inception, browser compatibility was a jungle full of king kongs and velociraptors. Before…

I'd like to point a possible flaw in your counter-argument: jQuery wasn't the only choice and it wasn't the first. PrototypeJS, which came before it, did an arguably better job since it didn't have many of jQuery's design flaws, like hijacking 'this' or silent selector errors.

The PHP analogy is therefore spot on IMHO: both it and jQuery (and I'd like to throw MySQL in there while we're at it) were tools that achieved success by lowering the quality bar in exchange for feature abundance and "if it works why do you care how".

Re: This Week in Rails: jQuery no longer part of Rails, and more

#106
post #93

Earlier quoted context omitted.

Nikanj isn't wrong (and is funny), but I think the other (more justifiable) reason is that jQuery largely isn't necessary anymore: when it came out, there were an uncountable number of browser incompatibilities that needed painting over, and APIs for remote requests, DOM querying & manipulation and the like were very immature, so a library to make everything usable was extremely valuable. Now, those APIs are mature &…

I recall reading that element.querySelector(All) was inspired by jQuery. If true, it means jQuery was so much of a success that parts of it were implemented natively in browsers! (I couldn't confirm this by googling, so if anyone can confirm or deny that this is the case I'd love to know!)

To some degree, it's absolutely the case that JS frameworks of the era have shaped what browsers have done in the late-00s.

I can't remember the detail of document.querySelectorAll; it was first proposed around the time jQuery was originally released.

element.querySelector I think was largely inspired by jQuery's usage of it (in part to make it easier to run more of jQuery's selectors natively!).

Re: This Week in Rails: jQuery no longer part of Rails, and more

#107

Earlier quoted context omitted.

I'm not a fan of CoffeeScript but do they really need to lug the huge amount of dependencies babel brings along with it? Why not target ES5 with some ES2015 sprinkles in depending on compatibility and slowly work towards ES6?

I'm not sure how you slowly 'work towards' ES6. Unless you decide to only support bleeding edge browsers, you cannot use ES6 or ES7 features in production applications. The only way we can use them is through transpiling. This will be the case for at least another three or four years.

You can absolutely use some of ES6, but only the library parts, which by and large aren't that interesting.

Re: This Week in Rails: jQuery no longer part of Rails, and more

#108

Can anyone explain when did jQuery start to fall back in the tech era? What were its failures? It is a bit sad to say goodbye to such an old friend.

jQuery to me was always meant as a DOM manipulation library. It didn't fall behind per se, it's just that browsers became good enough and standard enough that you no longer needed this type of tool. I think it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React, because it really was never meant for building web apps (of course you could still use jQuery in Backbone and…

> it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React

What would you call jQuery UI?

Re: This Week in Rails: jQuery no longer part of Rails, and more

#109

I'm not a Ruby/Rails dev, but why the hell was it ever included? :o Isn't Ruby a backend language and Rails a backend framework? :o

It's a full stack framework. You can include JavaScript for your views, probably most commonly used to show, hide, and insert and remove elements from the DOM.

To expand on this, the tool of choice for the frontend part used to be PrototypeJS. In Rails 3.1 the relevant portions were decoupled and became options rather than baked-in, with jQuery as the default but still an option among several: http://weblog.rubyonrails.org/2011/4/21/jquery-new-default/

Re: This Week in Rails: jQuery no longer part of Rails, and more

#110
post #51
post #48

Earlier quoted context omitted.

> And then it seems you try to lie your way out of it. Please be charitable and give others the benefit of the doubt when commenting here.

Are you a mod? I'd like to apologize for crashing this jQuery funeral.

dang and sctb are mods.
Post reply on HN