Live data from Hacker News

Why I'm still using jQuery

arp242.net

121–130 of 246 posts

Re: Why I'm still using jQuery

#121
I still use jquery too and it doesn't have to be a tangled mess of insanity nowadays.

Webpack + ES6 modules + jquery is a reasonable option IMO if you like the idea of server rendered templates with sprinkles of Javascript.

Plus, with the way things are heading with certain web frameworks (like Phoenix), you can do really interesting things like push the diffs of your server rendered templates over a websocket channel without having to write any user land Javascript yourself, and on the initial page load it just gets served without Javascript using the same templates. It's like the best of both worlds (super fast feeling apps, SEO just works and you don't have to duplicate templates and logic on both the client and server).

Re: Why I'm still using jQuery

#122
post #99

Earlier quoted context omitted.

This is some special kind of madness and I wonder when it will stop. There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse. Also the code you have to write is much shorter comparing to frameworks.

> There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks. I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.

That's a healthy response to anything new in the front-end community.

Nevertheless I encourage you to check out this presentation:

https://youtu.be/AdNJ3fydeao

Which explains the idea much better than I ever could.

Two things had me sold on this:

1. They managed to make the thing so easy to use, that even people who's line of work involves mostly Excel sheets were able to create something useful after a short introduction.

2. The output is relatively readable JS. There are some surprises like a few one-letter method names, but overall you could open up the source of a running Svelte app(provided it weren't minified) and figure out what it's doing just by reading the code.

Re: Why I'm still using jQuery

#123
post #93

Earlier quoted context omitted.

SPA is by million times better than "classic template-driven" trash. I don't just "think" so, I have 7 years of experience with "classic templates" and 8 years with SPA.

Been here for just about all of this "web" thing. When I'm pleasantly surprised by how fast & light something is it's almost always server-side rendered or static. Only benefit of SPAs is that at least they're more likely to employ responsive layouts, but then they so often also manage to have bugs that break the page in certain layouts on certain browsers (overlays/modals are a biggie) that it's kinda a wash. And th…

> It has failed spectacularly at that goal

No, it allows apps to don't rerender whole page on every click, so it works just fine.

Re: Why I'm still using jQuery

#124
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. You lose some built in functionality and have to ship the framework down to the client.

Re: Why I'm still using jQuery

#125
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…

This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job.

I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the limitations of this approach quickly become evident; in those cases, I use reactive component frameworks like Vue and React.

But there's also approaches in between! For mid-complexity sites / apps, I've used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing to generate more repetitive parts. I've also used hybrid approaches, where vanilla HTML / CSS / JS is used for more static parts of the site and Vue is used for more dynamic parts. You can use Vue in full-on SPA mode with "server-side rendering"...but you can also just generate HTML server-side as you would have before, then progressively enhance parts of it with Vue / jQuery / whatever.

I've also used "unfashionable" frameworks like Spring before, simply because it met the client's available in-house expertise. As developers, it's incumbent upon us to step back, assess the task / team / environment at hand, and pick tools accordingly.

Re: Why I'm still using jQuery

#126

Earlier quoted context omitted.

Anyone can throw out a better-because-of-experience answer, and in fact I’ll do so now: I also have 15 years of experience in front-end dev and I disagree with your premise. It completely depends on what you’re trying to build, and SPAs are too heavily used at the light-interactivity end of the scale. We’re failing our users with brittle solutions that make us feel cleverer as developers.

Well, literally not anyone can "throw" such argument, only those who actually has an experience :) How many years of these 15 you are building SPApps? It's ok to disagree. I'm in a camp "API + SPA" after my experience. I know as fact that you can greatly increase UI performance this way and build multiple apps (desktop, mobile, web) using single API. So argument "I just think so" is totally not an argument for me.

I guess the other thing that you’re leaving out is the number of users your site will receive. For smaller numbers in a simpler market you can get away with more technically complex solutions. My last four years have been spent working on data driven platforms with a minimum of a billion individual visits a year, and for those typically prerendering the common parts and pushing them to a caching layer is much more computationally efficient and leads to a faster client.

If you’re dealing with a lot of custom data for each user they that plays less well into the prerender solutions. But again, it comes down to how best to serve your users’ needs.

Re: Why I'm still using jQuery

#127

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I…

You have some pretty unidiomatic JS in there. For example: Array.prototype.filter.call(document.querySelectorAll(selector), filterFn); What's more idiomatic is document.querySelectorAll(selector).filter(filterFn) The same holds for forEach. I suggest you look into how javascript prototype based OOP works

[deleted]

Re: Why I'm still using jQuery

#128

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I…

There's a mixed-content warning because the original site doesn't have a valid HTTPS cert but yours forces HTTPS, you might want to fix that.

Re: Why I'm still using jQuery

#129

Earlier quoted context omitted.

> I still believe that they're more difficult to develop than adding JS on top of classic HTML (not saying they're worse, but certainly I don't find them easier). You're right, I should have been clearer. Emphasis on develop and maintain . If you're just building a near-static site with, say, some slideshow that needs basic JS then I'd use jQuery too. I'm sure there's a bazillion plugins that already do what I want a…

> You're right, I should have been clearer. Emphasis on develop and maintain. Did you ever think that you might want to put the user experience first? Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise!…

This kind of terrible state management is super widespread and really annoying. I agree that lots of folks seem to have have spent the last few years thinking more about their build chain and tooling than about basic UX.

Re: Why I'm still using jQuery

#130
post #66

Earlier quoted context omitted.

Small detail, what's with the plus in this code from that site: last = +new Date();

It is a trick to coerce it to an integer. >> new Date() Date 2019-05-27T12:52:41.932Z >> +new Date() 1558961556913 >> +"4" // works on anything else :) 4

+ can concatenate strings. So I guess there is an implied: 0 + in there to make it in integer mode.
Post reply on HN