Why I'm still using jQuery • Hacker News Board

Re: Why I'm still using jQuery

#91

Post by scrollaway » Mon, May 27, 2019, 1:10 PM UTC

englishrookie wrote: post #61

scrollaway wrote: post #55

Earlier quoted context omitted.

Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using Ja…

I'm an old php dev, still doing server side development exclusively, and these are genuine questions: 1. What tooling is there available? Do you mean something along the lines of vim or IntelliJ? 2. How do these techniques make the user experience better, compared to e.g. ajax?

> 1. What tooling is there available?

So here's the thing about the JS world: You have access to essentially all the tooling ever developed for frontend dev. Linters, code formatters, IDEs, etc. Tons of crazy techniques invented to speed up development (hot-reloading in various frameworks; remote debugging with the various browser inspectors…).

All this becomes available to your server development experience the moment you choose to share the language. And having developed with Python for over a decade, I can safely say I no longer enjoy doing that after seriously using typescript for just under a year. This also does have to do with the IDE; VSCode with TypeScript is a better dev experience than Python with any of the popular Python IDEs, even with added typings (python types are awful).

> 2. How do these techniques make the user experience better, compared to e.g. ajax?

They don't. They do enable you to take advantage of them in order to make a better user experience, but you still have to actively pursue that. Someone gave the example of Reddit lower down which is possibly the worst SPA I've ever seen on a popular site. OTOH, if you look at well-built NextJS websites, they're often ridiculously fast both to load and to use.

Re: Why I'm still using jQuery

#92

Post by dmitriid » Mon, May 27, 2019, 1:10 PM UTC

ehnto wrote: post #40

The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next(); On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing? element.nextSibling is very clear. It's the next sibling of the element. It's idioma…

> Had they learned vanilla javascript first

Vanilla Javascript has nothing to do with DOM APIs. DOM APIs is just another interface/library/abstraction that you need to learn after you've learned JS.

> If you learn jQuery today, you're not learning core JavaScript

DOM APIs are not core Javascript.

Re: Why I'm still using jQuery

#93

Post by asark » Mon, May 27, 2019, 1:10 PM UTC

EugeneOZ wrote: post #27

arp242 wrote: post #22

Earlier quoted context omitted.

> If you need state management, build a very complex app, etc. ... don't. I'm not so sure you do for many sites. Take something like Reddit for example; I don't think the new SPA redesign is any better than the old template-driven app. In fact, IMHO it's worse in every way. Part of that is just a matter of design and not technical, but part of it is just "SPA hell": CPU goes to 100% on load, takes ages to load stuff,…

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 that's not an inherent benefit to SPAs, just one thing they usually get sort-of right that's less likely to be correct in oldster template/static sites.

I'm old enough to remember when AJAX was supposed to make the web feel faster. It has failed spectacularly at that goal, in fact, whatever potential it may have had. It gave us much better spying on users though, so... thanks?

Re: Why I'm still using jQuery

#94

Post by JaTochNietDan » Mon, May 27, 2019, 1:12 PM UTC

austincheney wrote: post #78

JaTochNietDan wrote: post #54

Earlier quoted context omitted.

I don't disagree that you should know core concepts of what you're writing. I write a lot of Go without any heavy abstraction libraries (i.e ORMs) and have done with others like PHP in the past too. With abstraction there has to be a balance though. Sure, I concede that knowing how it works is actually important, hence why I've spent a lot of time doing things without libraries in the past, especially as I was learni…

> Writing a bunch of stuff from scratch every time is not particularly productive either. If you were to describe that in offline terms applications would be like books and abstractions would be like parts of the books. In order to make effective use of the book you still have to read, from scratch (whatever that means). When you become well versed in reading and writing it doesn't feel like a chore and you become fa…

I'm not really sure what you're saying at all? It seems like we have agreed but I simply cannot comprehend your example.

The point I was making is that we could all spend our time going as deep as possible with as little abstraction as possible and end up writing stuff in assembly because "it's important to know how something works".

There is always a cost/benefit with abstraction when it comes to getting things done.

Re: Why I'm still using jQuery

#95

Post by scrollaway » Mon, May 27, 2019, 1:14 PM UTC

arp242 wrote: post #86

scrollaway wrote: post #75

Earlier quoted context omitted.

This has nothing to do with an "Argumentum ad populum". I'm saying devs are flocking towards it because it's a lot easier to work with and maintain. There's a lot of reasons why this is true. One is using a single programming language. Another is having the server app be aware of the entire app rendering rather than just templating-in bits and pieces. I could go on but that's not the point I'm trying to make.

> I'm saying devs are flocking towards it because it's a lot easier to work with and maintain. Two things: first, my experience (and perhaps definition) of "easy" is different. I wrote an entire different post about that[1], but the tl;dr is that SPA may be easy to make things with , but it's hard to debug things , which is a more important measure of "easy" IMHO. Another example would be accessibility (screen reader…

> it's hard to debug things

I agree with the definition of "easy" in your post, and Docker is an excellent example of hell on earth. But I've not had that poorer debugging experience with SPAs, so I don't see what makes them harder to debug. I can't possibly have gotten that lucky?

The hardest problems I've had to debug on my SPAs usually had nothing to do with the SPA stuff and more things such as obscure yarn or typescript bugs/behaviour. These classes of bugs exist in all languages and frameworks.

> Another example would be accessibility (screen readers, etc.) Last time I tried, it was much harder to get that right with SPAs (not impossible, just hard).

I'm very confused about this. What about SPAs makes this any different than regular boring HTML? If anything, having easier access to a component model should make it easier.

Re: Why I'm still using jQuery

#96

Post by Carpetsmoker » Mon, May 27, 2019, 1:15 PM UTC

scrollaway wrote: post #84

Carpetsmoker wrote: post #76

Earlier quoted context omitted.

> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so. Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more r…

I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app). I'm starting to think I need to clarify that paragraph :/

I inserted the word "often" now: "Those apps are often easier to develop, tend to be faster".

The entire topic is complex, and like I said the main point wasn't about template vs. SPA, although I felt like something had to be said about it, as it's obviously related and something of an elephant in the room.

I don't think there is One True Way™, but I also feel that many apps are actually a lot less complex than people seem to think. For example the main competitor for the app I'm working on now (unpublished MVP that's still WIP) is a SPA, and I feel like my simple template-driven app has a much better UX. You just don't need all the complexity, there is so little benefit you might as well not bother. I think this describes many apps.

Would HN be better as an SPA? I don't think so, and I suspect that a "SPA HN" would be harder to develop and get right.

Re: Why I'm still using jQuery

#97

Post by bryanrasmussen » Mon, May 27, 2019, 1:15 PM UTC

scrollaway wrote: post #84

Carpetsmoker wrote: post #76

Earlier quoted context omitted.

> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so. Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more r…

I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app). I'm starting to think I need to clarify that paragraph :/

I think you need to clarify as well, because if someone tells me it is easier to maintain solution X than solution Y I naively expect it must be because solution X's users will have it better than solution Y and complain less, requiring less fixing of user experienced problems.

Re: Why I'm still using jQuery

#98

Post by scrollaway » Mon, May 27, 2019, 1:15 PM UTC

austincheney wrote: post #82

scrollaway wrote: post #55

Earlier quoted context omitted.

Has it occured to you you might simply not understand the advantages of this approach? There's a lot of crazy things in the world. Talk to a child about the economy or country borders and you'll realize how some things are just not straightforward to explain the advantages of. Serverside rendering in JS is no different to SSR in classic frameworks. You generate HTML serverside. Except in this case, you do it using Ja…

> If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so. Bandwagon fallacy. In all fairness popularity is never a qualified descriptor of competence or performance.

See responses to these two comments: https://news.ycombinator.com/item?id=20021685 - https://news.ycombinator.com/item?id=20021743

Re: Why I'm still using jQuery

#99

Post by Tade0 » Mon, May 27, 2019, 1:17 PM UTC

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…

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.

Re: Why I'm still using jQuery

#100

Post by peterangular » Mon, May 27, 2019, 1:17 PM UTC

scrollaway wrote: post #84

Carpetsmoker wrote: post #76

Earlier quoted context omitted.

> So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so. Let me put it this way, both as a developer and user of SPAs, I have long since observed that SPAs, on average, tend to be much more r…

I have no claims that SPAs are better end-user experiences out of the box. Your quote is about how easy it is to develop and maintain an SPA, not how good users have it after the fact (which entirely depends on how good your team is at building the app). I'm starting to think I need to clarify that paragraph :/

Probably - "Has it occurred* to you you might simply not understand the advantages of this approach?" makes you sound pretty dismissive of the parent comment's points.

Also - as someone who disagrees with you I don't see any compelling points in things like:

> "So when the author says that classic HTML with sprinkled js on top is "easier to develop", I smirk. If it were, developers would not be flocking en masse towards SPAs and the like. Those are gaining traction because they are easier to develop and easier to maintain. Monumentally so."

You're on HN - there's a huge chunk of us who are attempting to KISS web development. You're not wrong that React and Typescript are wonderful tools - but they're absolutely not the only way to develop things.

Also you may want to address people's worries about SPA development if you want to convince people it's not as bad as they're saying. (like performance - which is a huge reason I keep my light-weight vanilla-style apps the way they are)