Now is the Winter of my discontent.

I may never be a professional web developer again. It’s not because I don’t love doing it; I’m always looking at ways to make interesting and practical websites. The eleven years as a professional software engineer is what people see on my resume. What they don’t see is that I don’t want to go back to those years when most of what I did was Java back-end and full-stack development. I don’t want to work with Java anymore. What I learned and experienced as a Java web developer is still in me. It can be applied to other programming languages. Before I went professional, I did voluntary and personal web development with Java, PHP, Python, Perl, and plain old HTML. If I can go back to the old way and get paid for it, great. But my past may be hindering me. It may be time to look for something else. Here is what I do and don’t love in web development.

I love WordPress because it uses PHP. In the world of full-stack web development, too many websites take far too long and cost too much money too produce. They cite enterprise-level access as the reason. Unless there’s a need for hundreds of thousands of concurrent users on a website, these measures don’t need to be taken. PHP and other template engines like Python’s Jinja2 allow for logical code to be embedded in the HTML code. They cannot run on your browser, so the web server has to process the HTML files and send the pure HTML to the browser. This is something the end user never sees, but for the developer it provides a fast approach to making rich websites and web-based content-management tools like the WordPress editor. I love having the HTML written with the logic code, where I can visually imagine the result before testing. I wrote a web application for my community’s Wii Bowling league before my first season as official scorekeeper, with just two week’s notice. Testing and debugging wasn’t completed before the season, but I was able to collect the data from my phone and a week later it worked fine.

Does every website have the traffic like Facebook, Google or Twitter? I don’t know the back end coding for Facebook, but I’ve read that it was originally written in PHP. Today, Facebook touts some of its available development technologies such as React JS and Graph QL. React is a JavaScript framework. JavaScript is key to enterprise websites. Have you ever wondered why websites crash on your tablets? In order for a normal web server to handle more traffic, much of the load has to be distributed. If that website doesn’t have the budget for a huge server farm, JavaScript provides a way for much of the load to be handled by your web browser on your computer. Your web browser has what is called a JavaScript engine built into it and all JavaScript written into the front-end code is processed on your computer, whether it’s a desktop, tablet or smartphone.

What makes it worse is that most websites are monetized. Many throw in some code that allows ads to pop up all over them. These ad snippets are pure JavaScript. All of these ads are processed on your machine. Older tablets can’t handle them well. My wife likes MSN but complains when her tablet freezes or her browser crashes. JavaScript is the reason, but good coding makes a difference. Facebook works fine on her iPad 2. Well coded websites like Facebook minimize the issues while poorly-coded ads can cause load and security issues.

Any code that runs on your computer can have security flaws. When Netscape introduced JavaScript, its concern was having features such as printing options. Since it could allow for bad actors to run devices in your home, those features were kept out. This is the opposite of the Internet of Things approach to Big Brother monitoring in every home (and car with 5G) coming soon. But I digress. Despite JavaScript taking a limited access approach, cross-site scripting and other hacking methods could make your computer a target for becoming part of a bad guy server farm. Applications on your phone can turn on your microphone and camera, and you may never know it. A good (decent) website doesn’t want you to experience bad things. How much do they consciously know that that’s what they might be doing?

The non-HTML back-end languages like Java allows for HTML to never be written there. The whole idea is to use the back-end to provide data, make RESTful API calls from the front end to the back end, then generate the HTML using the response from the back end. This is much more lightweight than you would expect, but it is costly to develop and implement, and most websites don’t need it. My favorite Java front-end tool is Java Server Faces, but I don’t think the Model-View-Controller method of coding works well with JSF. Java Server Faces allows for using XHTML to make more of a template approach using Java.

Currently, I’m experimenting with the static website generator Pelican, designed with Jinja2 to generate static web pages using templates. This approach allows for the web pages to be static going to the browser, thereby keeping user interactions from happening. This approach works with blogs, but may not be suitable for people used to having remote access for writing. Static generation is a security approach being tested. I am also experimenting with designing HTML/CSS pages with no JavaScript. These two approaches won’t work at all for interactive social media or shopping cart sites. Most websites don’t have abundant server loads, negating the need for dynamic sites and JavaScript. Another approach is integrating MongoDB, a NoSQL database, that would avoid possible SQL injections from overlooked flaws in the code.

I’m having fun learning and growing with using simpler approaches to building websites than using Java. I’ve using online recruiting sites like Monster and Zip Recruiter and have been unsuccessful. I want to remain local and work on site. Remote working would be too non-productive. Also, I don’t want to be a Java developer anymore. I would rather be a Unix/Linux system administrator and write code with my all-time favorite programming language, Perl. Python is a close number two and something I’m more familiar with currently. The biggest problem I found with the online recruiters is the AI machine learning algorithms. They don’t read resumes well and us guys don’t feed in enough data to get a better outcome. The bottom line is that my matches are always Senior Java Engineering positions.

I wish I can retire.