Programming thread

Yeah, the more I work on javascript the more niggerlicious it seems.

Is it bad practice to use an anchor element to change inner.html

for example
JavaScript:
let niggerlicious = document.getElementById("about-us-anchor");
niggerlicious.onClick = myFunction
let divineProvidence = document.getElementById("container-div");

function myFunction(){
    divineProvidence.innerHTML = "html here"
}

I'm just making a basic website template for my portfolio. I was thinking a basic landing page for a business can be really simplified by just using javascript to change the html of the page instead of redirecting you to another webpage that looks practically fucking identical.
UNORGANIZED RANT INCOMING BECAUSE THIS WAS JUST THAT NIGGERLICIOUS

Think about what you're doing. You might be creating an absolute CURRENT YEAR WEB2.0.34532.7b.alpha.commit4af2b6ee.niggerfaggot.prod-1.retardedversionstring-20240521.patch2-1 JavaScript soydev usability nightmare right here. Always be extremely careful with JavaScript and never use it more than absolutely necessary. Look into generating all of your redundant HTML on the server side instead of shitting it onto the client for no fucking reason. I've heard Hugo is good for that, I've never used it though. You could also use this as an excuse to learn PHP or something, which means you get to have fun making shit run on the server. You could even make your own forum! And if you do it right, it wouldn't require JS for almost all of its functionality.

I don't think the anchor tag being for things like that is too bad, though. The anchor tag is used for navigation, and overriding it with JS without a JS-free option is fucking retarded but it's still a thing that commonly happens. If I was doing some niggerlicious dynamically-loading modern webapp shit, I would somehow make it simultaneously work with JS enabled and disabled, which is very possible and requires a bit of extra server API. You can do that by setting the href attribute but also having an event handler that does whatever AJAX bullshit but then suppresses the default behavior of navigating to the link. Obviously it also needs to properly handle URLs for permalinking and use the History API to make the back/forward buttons in browsers work right. You're doing that, right? Because if you use JS for navigation you have to be very careful or you will make a niggerlicious shitapp with a broken back button and no permanent links. Nobody likes that.

Summary: At least you aren't also using a JS framework on top of everything else. Don't worry, you'll figure it out some day: Using JavaScript in the first place is a mistake 99% of the time. It's really good for that 1%, don't get me wrong, but this isn't that 1%.

Also, maybe this is just an example instead of something you would actually do in real life. If so, only the following criticism is valid:
It is absolutely super niggerlicious to use element.innerHTML. Setting that property causes the browser to parse the element again as HTML and set up the DOM nodes again, and it gets worse when there are tons of extra nodes in there. It even fucks up event listeners too. It's probably fine in this case because you're actually changing the entire page instead of 1 element, but be very careful with innerHTML. Always try to create DOM nodes entirely with JS and add them as children of another DOM node instead of setting innerHTML for that node and causing retarded shit to happen for no good reason.
 
I've heard Hugo is good for that, I've never used it though. You could also use this as an excuse to learn PHP or something, which means you get to have fun making shit run on the server. You could even make your own forum! And if you do it right, it wouldn't require JS for almost all of its functionality.
Basic Flask templating is very useful to learn and isn't especially difficult to get up and running. With that, you can easily limit your JS to dynamic changes to the DOM.
 
  • Like
Reactions: ${Sandy}
easily limit your JS to dynamic changes to the DOM.
That's literally one of the only things that JS is useful for IMO. Certain programs would simply require too many page reloads if it was done server-side, such as WYSIWYG editors or fancy graphs or web chats. Certain widgets are also impossible without JS.

My opinion is that if you can find a way that doesn't use JS, it's probably better, unless it involves truly niggerlicious CSS or something.
 
That's literally one of the only things that JS is useful for IMO. Certain programs would simply require too many page reloads if it was done server-side, such as WYSIWYG editors or fancy graphs or web chats. Certain widgets are also impossible without JS.

My opinion is that if you can find a way that doesn't use JS, it's probably better, unless it involves truly niggerlicious CSS or something.

I'll definitely have to learn more about working with servers and php. I'm still really new at this shit and it only seems to get more and more complicated as I go on.

The stuff I'm doing right now is entry level shit, right now all I'm doing is just fucking around in vscode and trying to make a webpage template that's for small businesses. Its good practice, and I learned some new things throughout the day. So far I've just been experimenting with making the header and footer look nice and I haven't even touched javascript all day lol.

I did figure out another way to do things that's not so niggerlicious. It still involves manipulating the dom with javascript, but its just a short simple script that stores the header and footer as variables and inserts it into the page when it loads up.

This way you can make changes to the header and footer and it stays consistent across the whole site.
And you don't have to do something niggerlicious, like copy and pasting it onto every page.

I suppose the idea I posted earlier would be more useful for something like electron-js but I haven't touched that in awhile.
 
I did figure out another way to do things that's not so niggerlicious. It still involves manipulating the dom with javascript, but its just a short simple script that stores the header and footer as variables and inserts it into the page when it loads up.

This way you can make changes to the header and footer and it stays consistent across the whole site.
And you don't have to do something niggerlicious, like copy and pasting it onto every page.
Better than your first post, but it still has a few minor problems. What if the HTML loads but the JS doesn't? What if the user has JS disabled? You'll have a broken site. Also you'll have to pay close attention to how loading works because on slower connections you might have the main shit load and then the header and footer just randomly pop in out of nowhere. Suboptimal.

Templates and server-side scripting can both do the equivalent of copy and pasting it onto every page without the niggerliciousness of doing that yourself. Setting up something like PHP on an HTTP server is quite quick, and many web hosts will even do it for you. You can do this later, though. It seems like you already have a lot on your plate.

I suppose the idea I posted earlier would be more useful for something like electron-js but I haven't touched that in awhile.
Yes. If you're already committed to making an unholy JS abomination things like that are acceptable in my book.
 
What if the HTML loads but the JS doesn't? What if the user has JS disabled? You'll have a broken site.
Yeah, I was thinking that might be a problem. But for the purposes of my current project, I think using javascript to manipulate the DOM will be suitable. The biggest thing that I'm trying to do is just get some entry level html shit onto my portfolio so I can pick up freelance work doing frontend stuff and get some income from coding.

So I think, I'll use javascript to finish my project, but I appreciate your input and I'll be sure to put php and server side divineProvidence on my todo list. I'm banking my entire future on freelance coding so niggerlicious code is not an option.

unholy JS abomination
I'm gonna make that my new custom title.
 
Yeah, I was thinking that might be a problem. But for the purposes of my current project, I think using javascript to manipulate the DOM will be suitable. The biggest thing that I'm trying to do is just get some entry level html shit onto my portfolio so I can pick up freelance work doing frontend stuff and get some income from coding.

So I think, I'll use javascript to finish my project, but I appreciate your input and I'll be sure to put php and server side divineProvidence on my todo list. I'm banking my entire future on freelance coding so niggerlicious code is not an option.
Honestly you can do however much Melanin Magic® (patent pending) you want and your clients won't notice because they are computer illiterate retards who can't be assed to take a week to figure out how HTML and CSS work. It just has to kind of work. However, I appreciate your dedication to understanding how things work and making things cleaner. It is truly the mark of a good programmer in my opinion. Your future self, assorted schizos who disable everything, and potential other people who work on or interact with the under-the-hood details of your code will also all appreciate it.

I'd like to say that if you want to do freelance web design and make pretty pages for people, you could do well with a bit of learning about graphics design. Nothing much, just shit like which colors work together and how composition works. Normies will rank a shitty JS-laden two-framework 45MB shitsite with 3 CSS frameworks fighting for dominance above a completely unstyled HYPERTEXT-EMBEDDED DIVINE PROVIDENCE CONTAINER™ because they lack the ability to see the beauty in how things work as opposed to how they look. They look at things and say, "pretty colors oooooooh," using 99% of their primitive language faculties. It sucks and goes against all forms of rational logic, but it is what it is. Don't feel bad because a CORRECTLY MADE webpage can easily look just as good as, if not better than bootstrap slop.

I'm gonna make that my new custom title.
You're welcome. Maybe you could rotate it out with "Melanin Magic® (patent pending)" or "HYPERTEXT-EMBEDDED DIVINE PROVIDENCE CONTAINER™" (which is probably too long (:_( joah plsfix) as well if you ever get bored of that one.
 
If I have several webpages for my project. Is it a good practice to create multiple css files to make my code more organized?
for example

HTML:
<!--index.html-->
<link rel="stylesheet" href="./styles.css" />
<link rel="stylesheet" href="./welcome-page.css" />

<!--about-us.html-->
<link rel="stylesheet" href="./styles.css" />
<link rel="stylesheet" href="./about-us-page.css" />

If I put all of the styling for the whole site in one css document, I feel like I'll have one big bloated document that is hard to sift through.

I was thinking it would be best to have a css file for all the stuff that stays consistent across the entire site, and other css files for things that are specific to each page.
 
I was thinking it would be best to have a css file for all the stuff that stays consistent across the entire site, and other css files for things that are specific to each page.
You could do that. If these page-specific CSS rules are really for specific pages and will never be used elsewhere, I don't really see anything wrong with putting styles directly in a <style> element. It's slightly unclean but having a bunch of extra CSS files is also slightly unclean.
 
You could do that. If these page-specific CSS rules are really for specific pages and will never be used elsewhere, I don't really see anything wrong with putting styles directly in a <style> element. It's slightly unclean but having a bunch of extra CSS files is also slightly unclean.

Most of the css is gonna be pretty consistent across the site, but I was thinking having a second document or two just for page specific shit will make it easier to sift through my code. You guys are really helpful and you know way more about this shit than me so I figured I should ask if it's a common practice.

One of the goals of my current project isn't just to add stuff to my portfolio but I'm also trying to make the code easy to sift through and edit because I'm hoping I can sell it to small companies to use as a template that's easy to work with.
 
Man, if you can figure out how to get freelance work with a beginner's portfolio, tell me too, I'm struggling here

You can look around for entry level stuff on freelance sites.

I haven't gotten anything yet but I've been looking around to see what I need to learn to start getting some work doing basic front end stuff while I'm learning how to do more difficult tasks. I've only been at this for 6 months and it seems daunting at times, but I don't entertain the idea of giving up. I'm gonna keep trying until I'm dead in the fucking ground.

Also, Companies will pay to get royalty free webpage templates and save themselves some time. That's why I decided to work on that for the time being because it seems like its gonna take awhile to learn the more complicated back end stuff.
 
A really nice thing about personal projects is you can do all the work for fun, then put the repos for them up on git(hub|lab|gud) and use them to demonstrate ability, effectively as a portfolio. Hardly feels like work when it's for your own enjoyment.

Just don't do what I do and only focus on projects you can't associate with your real name lol. I have more github accounts than I can keep track of :\
 
My favourite piece of trivia about Javascript is that it's so cobbled together, it was considered easier to accommodate its eccentricities at the assembly level than it was to fix the language (https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS).
evenorodd comes to mind as well.

Basically it is a package that allows you to read the bits of a number and based on the last bit you can tell if it is even or odd.

This was done because modulus and division are extremely slow.

I might have got the details slightly wrong but I'm basically correct. I try to avoid Javascript and have only touched it once to help someone debug something simple.
 
evenorodd comes to mind as well.

Basically it is a package that allows you to read the bits of a number and based on the last bit you can tell if it is even or odd.

This was done because modulus and division are extremely slow.

I might have got the details slightly wrong but I'm basically correct. I try to avoid Javascript and have only touched it once to help someone debug something simple.
What, is bitwise AND too good for JavaScript developers?
 
What, is bitwise AND too good for JavaScript developers?
That would be the sane option, but what you forget is that you're talking about JavaScript. All numbers in JavaScript are floating point so the conventional bitwise AND trick will tell you nearly all whole numbers are even.

It is the bitwise & trick I paraphrased it so that if someone didn't know that trick they would still be able to understand.
 
  • Semper Fidelis
Reactions: Safir
Man, if you can figure out how to get freelance work with a beginner's portfolio, tell me too, I'm struggling here
My advice would be to build a moderately sized project on the side that incorporates the majority of the things you've learned and your general skillset. Like when I was in college everybody had more or less the same portfolio barring the self directed stuff and whatever game they created for one of the classes. I got away from that by creating a fully functional dating site on the side. Mostly because it showed the ability to come up with something original based on things that weren't really covered in any of the classes, shows the ability to design and implement systems and to build something practical that wasn't a school project. Had a really good mail system, matching system, admin backend, login system, automatic email notifications and pretty much most of what you'd expect a modern dating site to have functionality wise. Just as importantly it showed I could do something larger scale without having to rely on someone else to oversee or manage it. It made a pretty decent difference and made a great portfolio piece

So really what i'm saying here is its a good idea to have at least one larger project that shows off your entire skillset that you can keep improving as you go rather than just smaller simpler projects. Those are good too but being able to show the end result of a practical, planned out and implemented app can do alot for your portfolio and ability to get freelance stuff
 
Back