Showing posts with label Firefox. Show all posts
Showing posts with label Firefox. Show all posts

Saturday, 19 July 2025

Five Reasons to learn Web Development in 2025

Recent events such as the rise of generative A.I, have made tech work a little less attractive than it used to be. Web development, in particular, has suffered. That's probaby because a large chunk of web development is automatable, and even before A.I came on the scene, there had been numerous tools such as Content Management Systems and Low-code development platforms.

Thus, web development being automated by A.I was par for the course.

Robots writing websites.

Still, not all is lost. While web development might have lost much of its luster, there are still good, strong reasons to pick it up in ones tech career. Unlike the tech reporters and HR executives who write listicles like these, I have actually been a web developer before. I speak from experience, my dudes. And following are some of the most compelling reasons I had, in no particular order of importance, for going down this path.

1. No complicated installation

Ever tried to learn a language like PHP or Java? Every single one of these languages requires you to set up some kind of compiler or interpreter environment. PHP requires an Apache server. Java needs the Java Runtime Environment. You can write all the code you want, but until the code gets compiled or interpreted by the environment that you have to install and set up, you're not getting even a Hello World program done.

All you need is a browser.

HTML, CSS and JavaScript, however, do not. All of them already run in any major browser - Firefox, Chrome, and so on. In effect, the environment is right there for you.

This is not to say that you will never need to do any complicated installation. But for the basic building blocks - again, HTML, CSS and JavaScript - of web development, you don't. You will need to do that when you want to pick up a server-side language and maybe databases and definitely for the NodeJS style of development. But for basic stuff? Even the slightly more advanced stuff? Nope, not even a little bit. That is a lot more than you could ever say about other programming languages or platforms.

2. Good skill spread

When you learn web development, you learn HTML, CSS and JavaScript as a base starting point. That's already a good spread right there.

HTML and CSS are where you learn front-end and possibly even design. When you learn JavaScript, in addition to all the things you pick up when learning a programming language such as operators, arrays, branching and iterative logic, you also learn asynchronous operations and DOM manipulation.

A good spread of tools.

That's not to say that other tech disciplines don't have their own unique perks. But where it comes to the skill spread, web development wins. I don't think anything else even comes close.

Once you get past the basic toolset of HTML, CSS and JavaScript, back-end programming and databases will come into play. It's never just web development. Even if you are averse to the thought of being a humble web developer for the rest of your career, there are far worse places to start.

3. Resources

Now, when I say "resources", I don't just mean documentation, references and learning materials, though there's plenty of that, yes. But web development is not special in that regard because any other tech discipline boasts plenty of learning resources and a community dedicated to helping each other learn.

A good learning
community.

Though, in this case, web development has something extra.

You see, every humble HTML page on the internet can have its source viewed and played with in the browser, reverse engineered, and so on. Every URL on the internet is potentially a resource for learning, much like how I learned to cobble together JavaScript widgets decades ago.

In contrast, it's not possible to just take any desktop application and reverse-engineer the code, because the code has already been compiled and is no longer human-readable.

4. Ready use case

Often, when learning a programming language, it's helpful to be able to use newly-acquired skills to build something, so as to really hammer home the muscle memory. Something both relevant and useful, preferably. Not that Hello World programs don't have their place, but if one wishes to level up, better use cases are the order of the day.

And with web development, those use cases are almost too easy to find. Web development creates web pages, at the minimum. And after that, at varying levels of complexity, web applications. One does not have to stretch too far to find something worth building... and because it already exists, you know that it is both worth building and possible to build.

Applying what you learn.

My larger point is that what you learn can readily be applied. Not just in creating and editing websites, but in general software development. This also means that your chances of landing a job with that skillset cannot be understated. In this day and age, web developers are perhaps not nearly as in demand as they were a decade ago, or paid nearly as well, but the skillset goes beyond just web development.

For example, a lot of existing software already leverage things like REST API endpoints. These are basically URLs, which are pretty much the backbone of the web. REST is an almost inescapable part of the whole web development deal. Ergo, if you deal in web development, at some point you are going to be dealing with REST endpoints, which overlaps a large part of software development regardless of discipline.

Or even mobile development. In case you weren't aware, a large chunk of mobile tech is basically HTML, CSS and JavaScript.

I could go on... but do I really need to?

5. No gatekeeping

In the legal profession, there's the Bar Exam. In the medical profession, there's the Medical Regulatory Authority. In tech? Other than job interviews which exist at almost every industry, there's almost no gatekeeping in tech. Even the requirement for Degrees of Diplomas is not a really hard one.

When I say "no gatekeeping", I don't mean that nobody tries to gatekeep. The fact is that many people try to gatekeep, but it just doesn't work because to gatekeep, one needs a unified set of standards. It's almost impossible to establish said standards in a landscape as varied as tech, whose goalposts shift constantly.

The gatekeeper.

And while this inability to gatekeep exists in many areas of tech, none moreso than web development. HTML, CSS and JavaScript are fairly stable at this point, but these are just the base technologies. Their offshoots - frameworks, libraries and the like - keep springing up like mushrooms. And when you consider databases and backend programming languages, the possibilities multiply even more.

All in all, one could come in anytime in web development, and still be relatively fresh and relevant. No one can stop you from making and publishing web pages and applications, not in the same way they can stop you from practising law. You don't need a license to write code, so nobody can revoke it.

Some clarifications

The reasons stated here are in relation to those for choosing other tech fields. Why, for instance, web development when you could go for Data Analytics or cybersecurity? Reasons specific to web development.

I was inspired to compile this list because there are a lot of vague, generic and - to be brutally honest - trite lists out there on the web that extol the virtues of web development. Hopefully this is a better list.

<html>Bye for now,</html>
T___T

Saturday, 23 April 2016

Web Tutorial: Wheel of Fortune, Safari Edition

It appears that my Wheel of Fortune web tutorial met some... misfortune.

Sometime after I had released the code, I happened to test it on Safari. And this is what I got.


Oh, the horror.

Despite the fact that I had conscientiously written WebKit equivalents of the CSS classes and specifications, Safari has this bug where the overflow property does not play nice with the border-radius property. And that sucks because there are some truly interesting effects to be enjoyed when these properties are combined.

That said, I can only blame myself for not checking that the code works on Safari and Opera. Most of the time, it's Firefox and Chrome. I don't test on Internet Explorer because, well, fuck IE.

What's the Safari fix, then?

Well, I'm sure given enough time and effort, one could find a way to break through this wall. But a good developer also entertains the notion of going around this wall. Which is precisely what we're going to do today.

First, add the CSS specification for safari_fix.
            #wheel_wrapper
            {
                width:500px;
                height:500px;
                position:relative;
                margin:0px auto 400px auto;
            }

            #safari_fix
            {
                width:500px;
                height:500px;
                position:absolute;
                z-index:100;
                margin-left:-120px;
                margin-top:-120px;
                border:120px solid #000000;
                border-radius:50%;
            }


Here are what the properties do...
- width:500px, height:500px, border-radius:50%; to create a circular div the same size as the wheel_wrapper div.
- position:absolute, z-index:100 because we want to overlap wheel_wrapper.
- border: 120px solid #00000 to create a very thick black border around the div. Why black? That's so you can see it better.
- margin-left and margin-top properties have been set to -120px in order to offset the positioning effects of having a 120 pixel-wide border.

Now create a div with the id safari_fix and put in inside wheel_wrapper.
        <div id="wheel_wrapper">
            <div id="safari_fix">
       
            </div>   
            <div class="semicircle_wrapper wheel2">
                <div class="segment_wrapper semicircle2">
                    <div class="segment7 segment">


Here's what you should have. A huge black God-awful ugly border around your wheel, hiding all the even uglier jagged corners. Try your code. Make sure everything works.



Now change the border color to match your background.
            #safari_fix
            {
                width:500px;
                height:500px;
                position:absolute;
                z-index:100;
                margin-left:-120px;
                margin-top:-120px;
                border:120px solid #FFFFFF;
                border-radius:50%;
            }


Voila! A cheap and dirty fix for Safari.



Not the best solution, but...

Yep, this is not the most elegant solution you could have. If you ever change the background color, you'll have to change the color of the border of your safari_fix div as well. But if it works, it works. Until I have a better solution, this stays.

Seeya around,
T___T

Saturday, 25 July 2015

An Eventful JavaScript

Cross-browser compatibility can be a real pain. Front-end specialists, especially those who aren't making use of some framework or other, can attest to this. The inconsistencies from one browser to another are numerous - sometimes almost overwhelming.

In fact, today I want to talk about one such inconsistency - the Event object. The Event object is what holds information about JavaScript events such as onload, mouseover and so on. For a complete technical reference, follow this link.

We've used Event objects during the web tutorials. And one thing you will find when I handle JavaScript events, is that I mostly have this particular snippet:
if (!e)
{
    var e=window.event;
}


What does this do, and why is it necessary?

Glad you asked! It first checks for an event variable, and if there isn't one, it explicitly creates one.

As for why it's necessary, check out this code snippet.
<script>
document.onmousedown=mousedown;

function mousedown()
{
    alert("x:" + event.clientX + " y:" + event.clientY);
}
</script>


You can copy and paste this into a HTML file, then run it in Chrome. What happens. When you click, does it give you the x and y coordinates of your mouse cursor?

Cool. Now run it in Firefox. Not a peep, right?

That's because in WebKit-based browsers such as Chrome and Safari, event is stored as a Global variable. This isn't true for Firefox, and that's why the JavaScript in Firefox can't detect the Event object.

Here's a list of WebKit-based browsers.

Here's the tweak...
<script>
document.onmousedown=mousedown;

function mousedown(e)
{
   if (!e)
   {
        var e=window.event;
   }

    alert("x:" + e.clientX + " y:" + e.clientY);
}
</script>


Now this will make it work on Firefox in addition to Chrome.

That's all I have for now. Any... objections?
T___T