this post was submitted on 08 Sep 2023
530 points (94.0% liked)

Programmer Humor

19817 readers
28 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Theharpyeagle 41 points 1 year ago* (last edited 1 year ago) (11 children)

Honestly, as a mainly backend dev wanting to do more full stack, webdev is frustratingly intimidating. I keep trying to look up best practices but there's so little in the way of consensus. "Use JQuery, no use Vue! React is better, but also React is clunky and bad. Write pure js, no don't that's a waste of time, at least use typescript." It's all such a mess and I spend so long trying to figure out what to use. I'm trying to just pick something and stick with it, but I keep worrying that I'm not doing things the best way.

[–] 9point6 16 points 1 year ago* (last edited 1 year ago) (3 children)

I'd agree with you if you were saying this about 8 years ago, but IMO the post-jQuery-front-end dust has settled and the "best" (in terms of what most organisations end up choosing) hasn't really changed in a while.

  • Typescript unless you've got a really good reason not to.
  • React if you have anything remotely complex.
  • Webpack (or one of the wrappers) to bundle it up.

Sure, someone may like a React alternative, and that's completely fine. But at the end of the day, most companies are using React because it's basically industry standard at this point, and it's got too much momentum behind it for that to change any time soon.

I'd say the back end is where all the choice is these days

[–] zebbedi 4 points 1 year ago (1 children)

Webpack..... Aren't you on the vite train?

[–] [email protected] 2 points 1 year ago (1 children)

We must be in different organization circles because almost every frontend I've seen at my jobs or those of my friends at other organizations uses Angular

[–] [email protected] 4 points 1 year ago

I'll be honest, I think it's been years since I last saw anyone even mention Angular anywhere.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Maybe I'm just too used to it, but with next.js static site generation I find react to also work really well for simple sites too. If you're not dealing with state, react is basically just functions that return templated html. IMO it's pretty sleek for static websites since tsx let's you do basic templating with functions.

[–] [email protected] 13 points 1 year ago (1 children)

Don't worry, none of us are doing things the best way.

[–] [email protected] 5 points 1 year ago (1 children)

Lol yeah. Op needs to realise we are just throwing shit at the wall and waiting for the next new tool we have to learn this week

[–] [email protected] 6 points 1 year ago

As a previously front-end gone full-stack gone and settled in backend/infra... don't bother. But if you have to bother, or really, really want to 🙂, pick a relatively popular thing (e.g. Vue), and learn that, ignore the rest. By the time you come up for air the new hotness will have changed anyways, and the wheel will have been reinvented twice. It's a moving target, just learn the fundamentals with something and you'll be good to go.

[–] AVengefulAxolotl 5 points 1 year ago (1 children)

If you just want to try frontend, not trying to get a job there are these frameworks you should try:

  • Solidjs (love it so far) for a web application so SPA with separate backends
  • htmx to have a decently interactive website, it can be integrated with any webserver
  • astro for generating static sites

And i think everyone should use either Typescript or JSDoc for any bigger application.

[–] [email protected] 5 points 1 year ago (1 children)

Svelte is a happy middle ground between vue/react and SolidJS which is maybe too bleeding edge still

[–] AVengefulAxolotl 3 points 1 year ago (1 children)

Agreed on the svelte part.

But I think solidjs has a real chance of taking over React, because its similar, meaning JSX and hooks, but without the footguns. After using React, its so much cleaner and easier to work with, i cannot recommend it enough.

[–] [email protected] 2 points 1 year ago

Thanks for recommending it, it does look really nice. I'll definitely check it out when a fitting project comes along.

[–] aubertlone 4 points 1 year ago (1 children)

For sure don't use jquery.

React is industry standard, but not my favorite. That being said, even my personal projects I do in react. I'm happy with my current role, but if I wanna switch down the line there's less openings for a dev with mostly Svelte (my favorite framework) experience.

[–] Theharpyeagle 3 points 1 year ago

Right now I'm working on a personal project with Vue because it happened to be the one I was hearing most about when I started. I've got one project that I'm definitely gonna finish at some point started in react, so maybe I'll try out svelte on my next project.

[–] [email protected] 4 points 1 year ago

Wait until you meet "Platform Engineering"/DevOps. The sheer amount of CNCF projects and new tools out on a daily basis are on par with the JavaScript world.

[–] [email protected] 3 points 1 year ago (1 children)

jQuery is obsolete and insufficient if you're looking for an easy monolithic framework. Angular, React and Vue are all good (disclosure, I haven't used react), just pick one and learn it well and you'll have a good foot in the door. If you already know JavaScript and don't want to learn typescript, Vue can be used with plain JavaScript.

[–] [email protected] 3 points 1 year ago (1 children)

I've used all 3 although, not very much Angular so I don't have much to say on it. Vue is the easiest to learn imo. It bundles in routing and state management so you don't have to worry about picking supporting libraries for this. It's a pretty standard template style with lots of helpers and some magic going on behind the scenes. React is better if you want to write JavaScript. I prefer it for this reason.

[–] [email protected] 2 points 1 year ago (1 children)

Curious if you've used next with react. React itself has a scope rendering design goal and leaves the rest of the app to the community, and next sets up all the stuff around it for you and I think they did a really great job with the defaults they close, and it's still fully extendable.

[–] [email protected] 1 points 1 year ago (1 children)

Yup! Next is the most mature and complete framework for React. If I need SSR and/or SSG with hydration, it's my go to for now. It adds some complexity, so it can be overkill if you don't need these things. My experience working with it has been excellent.

[–] [email protected] 1 points 1 year ago

It can be overkill if you need something simple that doesn't match next's defaults, but if the default settings of next work for your use case I found the base project setup very simple to use.

[–] [email protected] 3 points 1 year ago

The main issue is that frontend is complicated and it can do a lot of very different things. Frameworks exist to solve some issues that may or may not exist in your project.

[–] [email protected] 2 points 1 year ago (1 children)

Where'd you get your time machine, that you obviously would've needed to set to 2008 to find anyone actual recommending jQuery?

[–] severien 1 points 1 year ago (1 children)

It's still the best API for imperative access to DOM.

[–] [email protected] 1 points 1 year ago (2 children)

Do you need to support 15 year old browsers? Practically all the jQuery features I used (which was a lot) are now available in standard js

[–] [email protected] 2 points 1 year ago

Even if you do, you can still use most modern js features with transpilation.

[–] severien 1 points 1 year ago (2 children)

Yes, the features are there. Just the API is still horrible.

As an example, make a hidden element visible (extremely common imperative operation).

jQuery:

$("#element").show();

Native JavaScript:

document.getElementById("element").style.display = '';

I hope you'd agree that the native JS is certainly not an example of good API.

[–] [email protected] 1 points 1 year ago (1 children)

Why would you not want to be using a rendering library? Your code is basically storing your application state in the dom which will turn into a horrible mess as soon as you reach any actual level of complexity. I know first hand. I'm traumatized from having to maintain large jquery code bases in the 00s. No serious professional writes code like this anymore.

Also, your vanilla code isn't modern. It should look more like this:

document.querySelector("#element").classList.toggle("hidden")

I could see not wanting to use a rendering library if you're building a simple site on top of basic static HTML, but that's not a serious discussion for industry professionals, and even still, jQuery is such a heavy dependency for saving some characters. If you find yourself using it so much you need the extra convenience then your site is already complicated enough that you should be using a rendering library with state management instead.

[–] severien 1 points 1 year ago* (last edited 1 year ago)

Why would you not want to be using a rendering library?

Because it's just not very useful in some contexts. I've seen web extensions which mostly query the current page, and it doesn't render much or even anything.

Not all pages are SPAs either. Many apps are the old request-response with some dynamic behavior sprinkled on top. jQuery covers that well.

This model is also quite compatible with the rising HTMX where the state/rendering is driven from backend and you just insert few dynamic pieces with JS.

document.querySelector("#element").classList.toggle("hidden")

There's no difference between document.querySelector("#element") and document.getElementById("element"), they're both same level clunky.

Also, what you wrote is not functionally identical. $el.show() is idempotent, the el.toggle("hidden") is not (as the name suggests, it toggles a class). It also needs an extra boilerplate class.

I could see not wanting to use a rendering library if you’re building a simple site on top of basic static HTML, but that’s not a serious discussion for industry professionals

There are plenty of non-professionals doing web stuff and I think it's great!

jQuery is such a heavy dependency for saving some characters

jQuery is 24 KiBs (minified, gzipped), that's a good price for the egonomics it provides. If you're constrained, there are API-compatible alternatives like cash which go down to 6KiBs.

[–] [email protected] 1 points 1 year ago (1 children)

That's actually a great example of the shortcomings of jQuery. There are multiple ways to hide an element yet they standardized on one that often wouldn't work.

Also you're using an ancient method getElementById... I think visuals should still be controlled with css. So what is the right way to do that in modern js? document.querySelector('.some-name').classList.add('hidden') with that class defined in the css, with whatever makes sense, including maybe a css transition.

[–] severien 1 points 1 year ago* (last edited 1 year ago) (1 children)

There are multiple ways to hide an element yet they standardized on one that often wouldn’t work.

It's the most common one. And it's not like you can't hide the element with some other mechanism with jQuery.

Also you’re using an ancient method getElementById…

And? What's the difference from document.querySelector() when querying for ID?

So what is the right way to do that in modern js?

What is the right way is context dependent. I don't see how having extra .hidden { display: none; } boilerplate is somehow modern or superior.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

What's the difference

Your code reads like it's from 1992 mainly, which makes sense I guess, given that you still find jQuery better than modern vanilla js. jQuery was created as a way to account for browser support challenges but is now obsolete. Anyhow, if I read "getElementById" in recent js code I would assume something was weird about that code. It's old hat and there is rarely a reason to use it.

What is the right way is context dependent

Precisely my point. Which is why I think it's opinionated in a bad way to arbitrarily pick one of them as the defacto. I often had trouble with jQuery's .hide() method because while it felt natural to use it, it often conflicted with what actually needed to happen for good UX.

What you're missing is that the hidden class can contain anything you want. Animations or whatever else. In other words, the idea that there is a "right" or "most common" way to hide an element is flawed at its core.

[–] severien 0 points 1 year ago* (last edited 1 year ago) (1 children)

Your code reads like it’s from 1992 mainly

Lol. You write a lot of text to mask the fact there's no good reason why getElementById should be bad. It's the same groupthink as with the jQuery, you're told it's bad, so you just follow the crowd.

jQuery was created as a way to account for browser support challenges

That was one of the reasons. The other was that DOM API was and still is crap. There were many such libraries to abstract away browser differences back in late 00s (Dojo, script.aculo.us, Prototype.js, MooTools), and the main reason jQuery "won" was that it provided the nicest API.

Which is why I think it’s opinionated in a bad way to arbitrarily pick one of them as the defacto.

You're missing the fact that jQuery does not prevent you from hiding the element in other ways. It's just optimizing for the most common case, which is one of the principles of good API.

What you’re missing is that the hidden class can contain anything you want. Animations or whatever else.

Sure, and when I just want to ... hide it, without any animations? Then this hidden class is boilerplate only.

[–] [email protected] 0 points 1 year ago (1 children)

I mean you're coming across like more of an old man than I am and that's saying a lot more than you know. For the first 2 years people shit talked jQuery I didn't agree with them. And then I got the opportunity to work without it and it seriously took like 3 days to completely change my mind. And all my pages were I believe about 100KB lighter.

jQuery is trash. And that doesn't mean it wasn't a great tool for its time. It's truly obsolete now though. If you hate the native JavaScript stuff so much.. I dunno maybe go work with Java or something?

[–] severien 0 points 1 year ago (1 children)

Just fluff, no real arguments, ok.

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago) (1 children)

I sure am glad I don't work with a moron like you who would ship a fuckton of JavaScript to users because they're too much of a pussy/old fuck to use modern practices

[–] severien 0 points 1 year ago* (last edited 1 year ago) (1 children)

Lol, so angry :-D jQuery hating must be a real passion for ya.

[–] [email protected] 0 points 1 year ago (1 children)

we know that being a pain in the ass is your passion -- your coworkers definitely have noticed

[–] severien 1 points 1 year ago* (last edited 1 year ago)

So far they didn't complain. My manager is all praise too ;-) It's kinda weird that I'm supposed to be the asshole for not being hateful of a technology. But you the hater are the nice guy?

The things is, I don't diss on technologies without arguments. I've grown to recognize that they are tools, not a subject of passion, at least in a professional context.

[–] [email protected] 1 points 1 year ago

Best practices are pretty straight forward in the typescript community. Frankly I think all the serious professionals from the JavaScript community just went to TS so the people left over that didn't migrate are well...

[–] [email protected] -1 points 1 year ago

React and typescript. If anyone tells you otherwise, ask them where they work.