The Adventure Continues — Rudeness Translator
Or “Why I May Need To Solve This Problem With The EVAN Stack”
A little while ago, I read this comment:
What sort of dribble is this? Are you even qualified to write anything that remotely concerns coding and technology? So many mistakes here like, “Backend developers works closely with hardware”. Just shows you how much you know, which is NIL!
It’s simple, it’s so hard to get a software engineering job because you’re too lazy to be any good. If you were, everyone would be banging down your door.
I get headhunted at least 2 or 3 times a day and get offers from all around the world. But then again, I worked hard over the last 20 years to be the best I can be in my field.
Stop being lazy and rubbish as a software engineer and complaining why companies won’t hire you. You cannot just take 1 YouTube course in Swift and call yourself an experienced mobile developer 🤣🤣🤣🤣🤣 Joker
— Source, emphasis mine
This was the response, but it was written more defensively than anything. It was a response that more or less said, “I do TOO know the difference between frontend and backend! I just made one typo!” but didn’t quite get to the heart of why the discussion exists. Yes, it is correct to define the frontend as the client side of an application, built with the users in mind, and the backend as the side of a website users can’t see. But what does that actually look like, with code?
Below is some JavaScript code that can be run with the command node gptHelloWorld.js. In other words, I can use Node to run it and in response I get to see GPT3.5 respond. It is like ChatGPT-in-a-bottle.
What I was going for, now, was a client side. The web user cannot go to a URL and see this going on behind the scenes.
First Mistake
The next task seemed simple enough. I wrote a file called index.html, and by viewing this file in Firefox I could see the results of my new webpage.
I renamed the JavaScript file above main.js, and I tied it to index.html with this.
<script type=”text/javascript” src=”main.js”></script>
Now I could call a function
<input onClick=”testFunc()” type=”submit” value=”Translate”>
testFunc was something I wrote to call the async function generateText. This would call GPT3.5, I would have the power that makes ChatGPT at my fingertips, and all would kneel before my awesome power.
And then…errors. Lots and lots of errors.
Node.js
Node (or more formally Node.js) is an open-source, cross-platform runtime environment that allows developers to create all kinds of server-side tools and applications in JavaScript.
I used to think Node was a server-side programming language. It is not — JavaScript is a programming language — but Node is not a server-side framework, either. GptHelloWorld.js uses Node, but that does not mean it was written in Node.
OpenAI provides instructions for how to use their Node.js library. I want to take this JavaScript code, which uses their API, and I want it to appear in the frontend of a browser.
If a full stack like MEVN necessary? I am not sure, but it sounds like the most reasonable way forward. MongoDB can wait. For the time being, call this the EVN stack, and I will view the results from a Google Pixel Android as a cheap excuse to call it the EVAN stack.
More interesting question: What is the absolute minimum I would have needed for this to work?
I do not think Express is, strictly speaking, necessary. This same example from the MDN documentation, in fact, demonstrates how you can use Node to make a server without Express. You still need to run it with a Node command…expecting index.html to work statically (if that is the correct word here) seems naive in hindsight.
From that same page:
Express is the most popular Node web framework, and is the underlying library for a number of other popular Node web frameworks. It provides mechanisms to:
*Write handlers for requests with different HTTP verbs at different URL paths (routes).
*Integrate with “view” rendering engines in order to generate responses by inserting data into templates.
*Set common web application settings like the port to use for connecting, and the location of templates that are used for rendering the response.
*Add additional request processing “middleware” at any point within the request handling pipeline.
Express streamlines the process, then. Vue? Maybe also unnecessary, but I think it would be better to just try this to start, then strip things out if they prove unnecessary.
