Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm still using jQuery

arp242.net

Post reply on HN
Print view View original

231–240 of 246 posts

Re: Why I'm still using jQuery

#231

Post by oefrha »

saltminer wrote: post #117
sgift wrote: post #33

> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thoug…

The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.

The saving grace in these cases is that often the reader mode would work with the HTML just fine and you don’t need to wait for the useless 3MB JS bundle which you may have blocked. The same reader mode trick sometimes works against subscribe-to-read-the-rest-of-the-article paywalls and no-scroll anti-adblock modals, too.

Re: Why I'm still using jQuery

#232

Post by dmitriid »

52-6F-62 wrote: post #177
dmitriid wrote: post #158

Earlier quoted context omitted.

That was simplified code to create just one element and add it to the DOM. Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.

Not for something so simple. It's trivial to abstract small, oft-repeated actions like that to their own function. As I do, regularly. And then I can give it a readable name, like `createElement` or `insertElement` with an interface like: insertElement(type: string, text?: string. attributes?: object, parent?: string): void; I prefer writing something like that with some minor case-handling over pulling in a library…

I wonder why you found necessary to repeat what I said but in different words? :)

Re: Why I'm still using jQuery

#233

Post by dmitriid »

ehnto wrote: post #187
dmitriid wrote: post #157

Earlier quoted context omitted.

> You are right, but it's kind of beside the point given the context is web libraries. I don't think it is. > so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from? DOM APIs are not as easy to learn. They are verbose, cumbersome, inconsistent in behaviour and capabilities. Even the staunchest evangel…

> That's the end goal of jQuery: to become the disappearing library. I guess my argument is simply that for the most part it's already happened, there is nothing particular scary about "jQuery style" general usage of the platform APIs. Anything more complicated and I would prefer to enlist libraries other than jQuery. Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated…

> Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated I can just use what's currently in the platforms. For animation, CSS and class toggles are usually enough. Anything more complicated and there are better libraries for that.

And that's the thing: there are always libraries. There are very few use cases where you want to use DOM APIs directly. They all but sream "use a lib/wrapper/framework".

Re: Why I'm still using jQuery

#234

Post by dmitriid »

52-6F-62 wrote: post #210
munk-a wrote: post #182

Earlier quoted context omitted.

Browsers are an interesting place since the language we compile to there is generally human readable when compared to assembly lang/machine code but that "more explicit" is something that we've come to reject in general development so I'm curious why it's persisted in the browser world. People[1] don't reject C/C++ because they're putting two much distance between you and the bare metal assembly statements, instead t…

Okay, then I need an addendum: Explicit [within the context of the language]. And by that I did mean human readable. const divElement = document.createElement("div"); divElement.textContent = "Hello world"; document.appendChild(divElement); Is more human readable to me than the jQuery abstraction (that pulls in piles of other potentially unused tooling) than: $(document).append("div").text("Hello, world"); It's more…

> if I have to repeat the methods more than twice I'd probably just wrap the couple of lines into a function, like:

I wrote in a sibling comment:

Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.

Re: Why I'm still using jQuery

#235

Post by kureikain »

jabart wrote: post #124
sgift wrote: post #33

> In my experience server-side generated templates lightly sprinkled with “progressive enhancement”-style JavaScript are still the best way to do that. Those apps are easier to develop, tend to be faster, tend to have fewer bugs, and your laptop’s fan won’t wake the neighbours. Thanks for that part. Really. A heartfelt thank you. Every time I see another "hey, I only want to show you text, but for some reason I thoug…

Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this. In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work. SPA apps are like building a browser, in a browser, and on the server…

In Jira, I constantly have a fear that I will update wrong thing. Every single click make something editable and the page jump around.

Re: Why I'm still using jQuery

#236

Post by dmitriid »

ehnto wrote: post #170
dmitriid wrote: post #160

Earlier quoted context omitted.

1. Significantly more functionality than a few edge cases you can no doubt come up with 2. Significantly improved developer experience. 10x reduction in boilerplate === less bugs. 3. Why not improve DX in the platform APIs?

Perhaps that's where the impasse is, because I see the platform APIs to have a reasonable experience now. I much prefer the browser implementations most of the time. Except drag and drop and Ajax. Those are terrible. I also preferred PrototypeJS over jQuery, it's approach of extending objects made way more sense than a god object that wrapped itself around my existing objects. I have simply never liked jQuery's appro…

> Except drag and drop and Ajax. Those are terrible.

And except actual DOM manipulation which is tedious, error-prone, and requires tons of boilerplate.

> I also preferred PrototypeJS over jQuery, its approach of extending objects made way more sense than a god object that wrapped itself around my existing objects.

Prototype extended global objects which made them even more magic and would break vanilla JS. jQuery creates a wrapper object with well-defined methods and lets you access the actual unaltered underlying DOM object.

And their resulting APIs are not that different

   // Prototype
   $('comments').addClassName('active').show()

   // jQuery
   $('#comments').addClass('active').show()

Re: Why I'm still using jQuery

#237

Post by 52-6F-62 »

dmitriid wrote: post #232
52-6F-62 wrote: post #177

Earlier quoted context omitted.

Not for something so simple. It's trivial to abstract small, oft-repeated actions like that to their own function. As I do, regularly. And then I can give it a readable name, like `createElement` or `insertElement` with an interface like: insertElement(type: string, text?: string. attributes?: object, parent?: string): void; I prefer writing something like that with some minor case-handling over pulling in a library…

I wonder why you found necessary to repeat what I said but in different words? :)

But I expressly wouldn't include a 30-100k library just to wrap a couple of repeated functions.

I happily write them myself. It's a few seconds of work, really.

Re: Why I'm still using jQuery

#238

Post by jb3689 »

I like the progressive enhancement approach using a small amount of JS, and I'm fine with jQuery. The thing is that I don't _use_ very much of jQuery. Rather than pull in all of jQuery you could just define your own `get` and `post` to abstract the XHR verbosity. No need to pull in a giant library to do that

Re: Why I'm still using jQuery

#240

Post by Aaron-goshine »

Fist let me say this thread has turned out to be possible the most important thread in regards to modern web development.

Single page Applications (SPA) and frame works that are used to develop such applications are over used which have led to a whole host of problems in the software engineering industry, I truly believe that if you are building software solutions 90% percent of the time you will be building them to solve business problems, so that should be of paramount importance not necessarily the latest shines concept and tools, especially unproven tools.

A very high percentage of the developers you will interview will be using front end frame work such as Reactjs, Anuglar, VueJs ... etc as a substitute for truly understanding the the native technologies and standards support by various user agents.

The consequences of this is usually very expensive for business while resulting in software products that are convoluted, complex and unstable; I have seen this too many times.

The JavaScript eco system at the moment is littered with these kind problems, pseudo stars developers who want to re invent the wheel (without first understanding the existing mechanics), not only is reinventing the wheel already an idea that has been frowned upon for thousands of years, in the context of software development most of the times it turns out to be a much buggier and less efficient solution.

I have encountered SPAs that have been built out to be so complicated and convoluted to say the least; in order to support server side rendering, hot module reloading, dynamic DOM refresh, Virtual DOM… etc. speaking as if these concepts are some holy gifts from the gods, and when you ask the most fundamental question what are the business values behind all of these concepts, there are no good answers.

Post reply on HN