Wow! JavaScript is 25....

https://www.theregister.com/2020/12/05/javascript_25_anniversary/

Funny thing is....I currently work with people who are younger than JavaScript.  Raises a smile and reminds me of when I was first introduced to JavaScript...

Back in 1997-ish I was writing some simple little C code apps to do file/data transformations whilst working at Ford Motor Company.  I was also helping to design and implement a FOAK system that was basically eBay for Ford dealerships (FOCALpt / NDSDB), it was mostly based around Oracle (as that was Fords standard) running on SCO Unix.  It was Oracle on the bottom, middle and front-end... I recall going to an Oracle DBA course in Richmond for 2 weeks, after which I was a certified Oracle 7.3 DBA. yay!  what it taught me was that Oracle wanted you to write all your business logic inside stored procedures as that was "faster" and closer to the raw data and you can just up the spec of the Servers running everything as you need more performance.  I got to meet up with "the people from Sun" and they were attempting to get "Java everywhere"... again, I recall using one of the very first versions of Java, porting my C code over to do the same thing, but in Java code.  I wasn't won over as my brain was fighting the fact I needed a JVM to be installed/setup just to run my 50lines of code.  I didn't need that for my C code.  I recall arguing with the Sun engineers as they were trying to sell me on the idea that "you can write this code once and deploy it everywhere"....but I could already do that with my C code.  Don't get me wrong, I liked the idea of Java, but it didn't win me over....and funny enough I've had to dabble/drop back to using it many many many times over the past 25 years.  As I was battling with the end to end Oracle-ness....I really disliked having write PSQL that had hard-coded HTML content, that built out things like drop-down select boxes with data server-side and then just output the HTML for it to render in the web-browser, if you wanted to do something "client-side", ie. in the web-browser, you couldn't you had to send the request back to the server and basically re-make/re-render the whole page to handle the change - think multi-step dependent drop-down boxes, something as simple as selecting a car Make / Model / Type etc...  There must be a better way.  

Fortunately, we were using Netscape that had early support for JavaScript, after doing some investigation work, getting myself on a 2 week course to get the basics under my belt and then working with a team of coders who "knew their stuff", I learnt the basics of JavaScript, mostly the perils of coding with it, ie. the "what no to do's".  I learnt about running the code through your own brain before letting it running through the web-browser, yes, that took mental effort, but it made sure that a lot of the bugs were ironed out way before it was executed.  I suppose that was one of those "moments in time", where a small mental change occurred that then led along a path of a change of mindset.  I've always "walked the code", no matter how large the software program, if I was touching an area of code, debugging, fixing or even adding new, I would always run through it to ensure that it did what it should.  Then I'd run through it for real and handle the very tiny edge cases of exceptions. I suppose that is why I've always shy'd away from people who are reliant on testing tools, yes, I see their purpose, but really...now we could have a very long debate about the "you can't do that for a system that has millions of lines of code, that's not realistic, you're talking out of your ar$e...".  had that discussion quite a few times over the past 25 years too!  funny enough most of those people now work in middle-management or are delivery service managers... I guess the point I was making here was that because the language was relatively new it was simple to work with, you were also more cautious and made sure that you understood the code, you understood what data was going into variables, you wrote more robust code.  There was no stack-overflow at this time, so you had to figure it out yourself and/or rely on sharing with a smaller community of coders/work colleagues.  You couldn't just cut&paste your way through the day.  After working for Ford, I made my way through a whole variety of industries and technologies (LinkedIn.com can show you more)

But, what I will say is that, what has paid my mortgage(s), household bills and put food on the table over the past 25 years has been: JavaScript.  It has been my core go-to, my comfort code.

Whilst back in the early days it was all about writing JavaScript to run in the web-browser, when I worked at AvantGo (mostly ex-Netscape engineers creating a mobile web-browser & server-side web-site crawler) we were using JavaScript server-side, that was back in 2000/2001, that was great, you could use the same coding front-end and back-end...without the need for a JVM or PSQL!  Then, as time moved on, I worked at Lombardi Software and within the BPM software, we could write JavaScript code server-side, I was in familiar territory, same as when I was acquired by IBM and moved into the MobileFirst division, we used JavaScript on the device and server-side....then the emergence of nodeJS came about, meaning I could write/run JavaScript completely server-side.  It was now looking like the early days of the Oracle model, but without the "lock in".

As with all things, they should evolve, they should move on.  Yes, some people have been dicking around adding new bits inside the internals of JavaScript and good old Microsoft have tried to get TypeScript in place to stop newbie mistakes from being written - okay, I get it... you want to define a variable as a specific type, numeric, string, array, etc..etc... and JavaScript just says, yep, you can just declare that variable as coming into existence and when you decide what you want to do with it, you use it for whatever you need.  A numeric, a string, an array, an whatever you want....  Personally, I have always like that freedom.  The issues that arise and created the existence of TypeScript, I blame it on sloppy coders.  There I said it.  This also has more to do with issues elsewhere along the supply chain...move back through the process from the coder.  It goes back to the application architect, the project manager, the project stakeholder, even the customer.  They set unrealistic expectations for delivery/creation of the code.  Someone along the chain will have decided in their infinite wisdom that an "estimate" of X time to build a feature has now become a "fixed price / fixed time box" and then probably shaved off 25% to fit within the unrealistic budget.  So, now you have usually (not always) inexperienced coders being pushed to a time window to do a massive amount of work, it's a luxury if you managed to get some coders who come along with libraries of code in their tool box, proven, tested, deployed, managed and maintained code they've written over the years (that is still relevant and updated) that can help accelerate the coders to hit those deadlines...those original coders will do their best.  That is what they do, that is all you can ask them to do.  Their best.  In the time frame you have given them.  

Funny thing about the software industry is that you would never work in they way that we do in any other industry, it just wouldn't be acceptable.  For instance, if you were in the car making or plane making industry, there is absolutely no way you would accept the way the software industry operates.  Well, you could but you'd have a lot more cars with faults and planes developing major faults....oh wait, hang on... actually a better comparison would be the "building industry".  You would never let a brickie who had made a couple of small garden walls in their mums back garden loose on building houses in a new housing estate? no...but you are fine with that brickie being a coder building a solution that you are going to run your core business processes that can make or break your business.....I digress.

Back to your coders, yes, you've agreed that the best option was to use JavaScript as you scan through some skills assessment system that says every person & their dog is an expert - they may have only done a few examples from w3schools.com - but hey, they sounded smart and they have a degree in something, so we're sure they'll pick it up and it'll all be fine... then you start to see a lot of "NaN" outputs as well as "transaction date: 167892754" because someone didn't understand the infamous Date() object properly.

I guess what I'm saying is... yes, blame the coders, yes, blame the technologies, yes, blame the people who estimate time/effort for software projects, blame them all....but then, sit back and accept the blame.  Is there something that you can do differently to make it better?  wherever you fit in the supply chain process - can you help to make it better?  

As I say, I like the idea of TypeScript, it's trying to help the coders to not make the silly mistakes, but it's a double-edged sword, it's Microsoft, we know they don't do anything to help the masses without their own interests being met first, they'll do what they always do, they'll start with small changes, get adoption from their massive developer community and then change it a bit here & a bit there and then slowly it'll become J++ (didn't they attempt that once before around '97/2000? I have a vague memory of a Microsoft Javascript? oh, it was their version of Java, my mistake), you get my point though, you'll end up going full loop back into a "locked in" environment where you'll need to have a Microsoft bottom, middle and front-end.... we're now looping back to Oracle in '97 :-)

With all of the above in mind....and if you recall C code is my "other" constant over the past 30years and because I was a little sick & twisted in the early days, I also did love a bit of ASM - although writing 200 lines of code [albeit very short lines] just to output the letter "A" on the screen did push me back to writing code in C as printf() was so much simpler.  Dipping into ASM was only ever needed when there was a real need for performance and I mean real performance. C was awesome, but there were just times you needed to drop a gear and have some serious number crunching going on that ASM did so much better.  The times were few, but it made the real difference.  That was one of the reasons that the AvantGo (very smart ex-netscape coders) web-browser was so awesome, they knew when to drop down to a lower level to get awesome stuff done.

As usual, I've taken 10 times longer than I should have, and given a walkthrough story of history and waffled about "me", I mean if I don't, who is going to? But, I am getting to the point....

and the point is - what comes AFTER JAVASCRIPT?

Well, there are no real contenders...(I flip a V sign to the youngsters who have just said "Python")...so, JavaScript is going to stay around for a while longer...so it's not such a case of what is going to REPLACE JavaScript, it's more a case of what can we do to ENHANCE it further (without it being hijacked as mentioned earlier)...Well, the best way to do that is to carve up JavaScript and look at areas where certain components could be "cut out" and improved.

I have kind of pointed towards this in the past - there are  few previous mentions of this and I've been keeping  sideways glance at what has been going on and I have a gut-feel that 2021 might just be the year when this will come to light.  I predict Java code can just go away now, we've had enough of the bloat and the chaotic mess of OOP patterns and rubbish (discussion for another day!), C#, well, see points above about Microsoft... so, the old skoolers out there and the clever coders who see the power of C and are not afraid of a few pointers are going to be the "engine crew".  JavaScript is still going to be king of the web-browser scripting I have no doubt about that, but there are times where you just need an adrenaline injection and I believe this is what is going to give you that shot.  (Again, back to AvantGo days, this is what we did using PODS - you recall? when you needed to do something either directly with the mobile device or needed to do it 1000+ times faster, you'd drop to writing a POD in C and get the job done)

Next years background learning, maybe not for the masses - and certainly not for the cowboy coders who are sloppy with their variable casting - I reckon this is one to study up on and get yourself familiar with as it's going to be a subtle game changer.   Now, just think....I wonder if I could execute my AI/ML training module within the web-browser and use the power of that huge spec of a laptop that is just executing a web-browser, rather than running it on (expensive) server-side "cloud" servers...get the consumer to pay for the processing.... now there's a train of thought that could lead to mass adoption ;-)

WEB ASSEMBLY

https://www.tutorialspoint.com/webassembly/index.htm

WebAssembly is a new programming language for the web. WebAssembly code is low level binary format, that is compatible with the web and can easily run in modern web browsers. The file size generated is small and it loads and executes faster. You can now compile languages like C, C++, Rust, etc. to binary format and it can run on the web just like javascript.

https://www.tutorialspoint.com/webassembly/webassembly_useful_resources.htm

Goals of WebAssembly

The open standards for WebAssembly are developed in a W3C Community Group that includes representatives from all major browsers as well as a W3C Working Group.

The main goals of WebAssembly are mentioned below −

• Faster, Efficient and Portable − WebAssembly code is meant to run faster on different platforms taking advantage of the hardware available.

• Easy to read and debug − WebAssembly, being a low level assembly language, has text format support, that allows you to debug the code for any issues and also to rewrite the code, if necessary.

• Security − WebAssembly is safe to run on the web browsers, as it takes care of permissions and same-origin policies.

Advantages of WebAssembly

The following are the advantages of WebAssembly −

• Run is Modern Browsers − WebAssembly is able to execute without any issues on the modern web browsers which are available.

• Multiple Language support − Languages like C, C++, Rust, Go can now compile the code to WebAssembly and run the same in web browsers. So, the languages which were not able to run in a browser will now be able to do so.

• Faster, Efficient and Portable − Due to the small size of the code, it loads and executes faster.

• Easy to understand − Developers don’t have to do much stress in understanding WebAssembly coding, as they don’t have to write the code in WebAssembly. Instead compile the code in WebAssembly and execute the same on the web.

• Easy to Debug − Though the final code is in low level assembly language, you can also get it in text format, that is easy to read and debug.

• 
  

Also....a freebie give away thought here..... now read the above and replace JavaScript with "conventional computing devices" and WebAssembly with "Quantum computing".... Did I hear an, "Ohhhhhhh!"?  yes, the same sort of pattern, now you're starting to think along my wave lengths.... :-)