Skip to content

The Original Coder blog Posts

The Future of JavaScript

I’ve been coding for a very long time. I’ve seen languages and industry paradigms come and go. JavaScript is all the rage currently, its even getting into the backend; But a decade from now it will be fading fast if not completely gone.

In the early years there was BASIC. It was everywhere and everyone knew it. It was designed to teaching programming concepts and not for wide spread production. Because it was so popular it was adopted for writing business applications and some sizable, complex systems were written in it. Those systems were hard to maintain because BASIC allowed programmers to write very messy code with little structure and many did. The term “spaghetti code” came to describe the very many BASIC applications who’s code was a complete mess. But because it was so popular a lot of programmers thought it was the end-all-be-all language. They even clung to it (aka Visual Basic) as the house of BASIC fell.

Then there was C. The language had been around but it took awhile for it to take hold in the world of personal computers. C was designed for low level system programming, was terse with few constraints on structure and had no type safety at all. It was never intended for widespread use as an application programming language. Yet it became the go-to language for writing large, complex business applications. Those systems were hard to maintain because C programmers used the lack of constraints to write messy code or code that was so “clever” others couldn’t understand it. Lint was created as an attempt to deal with some of these issues. Yet many programmers believed it was the be-all-end-all language.

Then there was C++. It was created to address some of C’s shortcomings and problems. It was an evolution of C so programmers mostly accepted it and moved over. C++ attempted to be better for application development by adding more structure and constraints to the language. But in trying to remain mostly compatible with C it still allowed for spaghetti code with very little type safety. Messy and very “clever” code was still pervasive and so Linters became even more important. Many programmers believed it was the be-all-end-all language. Some even clung to it (still do) as C++ was replaced by more modern languages.

Now there is JavaScript. In the beginning no one took it seriously, because it wasn’t intended for doing serious work. But it ended up in every web browsers and as the web became more important for business many developers were forced to use it. This made it “popular” and many libraries and frameworks were created to try and make it more suitable for business applications. Complex and sizable business applications are now written in it. Those systems are hard to maintain and typically get completely rewritten every few years to support a newly popular framework. Because it is so widely used programmers who have spent a lot of time in it are starting to believe it is the end-all-be-all language. It is even being used on the back end (Node.js) to write even larger, more complex systems.

See a trend? Very few programmers work professionally in BASIC or C today. Programmers used to more modern languages would likely find them antiquated and lacking if forced to use them. But at the time they were heralded as being great.

The writing is now on the wall that JavaScript will be joining them and fading away. That writing is Web Assembly. For the past couple of decades developers were literally forced to work in JavaScript because it was the only thing that ran client side on browsers. There was no choice. So a huge community has sprung up to support it. BASIC, C and C++ also had massive communities at their peek.

Once Web Assembly is mature and broadly adopted it will become possible to write client-side browser applications in many different languages. Web applications using Web Assembly will download and run faster on the browser than JavaScript. That alone would kill JavaScript client side. But many of those other languages will also be more modern and intended for writing business applications making them more productive and maintainable.

Some programmers will cling to JavaScript but most will end up moving to other languages. Once client-side JavaScript is dead server side will quickly follow and JavaScript will slowly fade away.

Its worth noting that there is a significant difference between BASIC, C/C++ and JavaScript though. BASIC was designed to teach programming concepts to students and it is still workable for that purpose. C/C++ were intended for low level systems programming (OS kernels, device drivers, embedded hardware, etc) where it is still used today and makes sense. JavaScript was created just to be used client side on web browsers. Once it is replaced in that domain its purpose to exist will be gone. Once it is no longer used in web browsers I expect it will completely disappar with no one using it for anything. It will just be a footnote in the history of the web.

Comments closed

First impression of EF Core is very poor

Based on my experience with prior Framework versions of Entity Framework I set off to implement the new EF Core version using Database First. What I ended up finding is nothing like the experience I expected. This was the most frustrating experience I’ve had with Microsoft development tools in quite a long while.

TLDR: If you’re trying to do Database First with EF Core go get the EFCorePowerTools extension. This is what Microsoft should have provided and it will save you a lot of time and grief.

The .NET Framework versions of EF were both powerful and user friendly. Plus they gave the developer lots of options and capabilities so that they could use it the way that best made sense for the project. Tasks like generating or updating the data classes were very easy to accomplish using GUI windows. Sure the EDMX file could (rarely) get corrupted, but you are using version control, right? Just pull a known good version.

My goals for this project:

  • Use Database First because Code First doesn’t generate quality (DBA approved) schema unless you put in a lot of effort to hand code SQL DDL statements in the C# code. That’s a nightmare, so no.
  • Put the POCO classes in a .NET Standard library with minimal dependances so that they can be reused if ever needed (plus this keeps things clean)
  • Create a separate .NET Core library to contain all the Entity Framework specific code for implementing the data repository including the DbContext.
  • Reference both of those libraries from an ASP.NET Core MVC project to verify it works.

Seemed simple enough. I’ve done this numerous times with the old non-core versions of Entity Framework and it was easy. To get started I searched the Internet for instructions on how to do Database First with EF Core and I found quite a few walkthroughs. Unfortunately, none of them worked.

First problem I found is some of the walkthroughs assumed you were targeting an ASP.NET Core MVC project so they skipped steps. Found others that targeted a library but the first couple I tried failed because the list of EF Core packages has changed someone in the recent past. Finally got the library ready which included adding design and tool packages to the library because the POCO generator requires them. This library will end up getting used in production, it should not have dependencies on developer tooling and aids. Sloppy.

To generate the POCOs you have to execute a Scaffold-DbContext command in the Package Manager Console. This is not obvious and not user friendly. It also doesn’t work. I spent at least an hour and a half trying it with different arguemnts or even via the Command Prompt along with more Internet searching. It seems lots of developers have trouble with this because there are lots of pages dealing with various errors. Oh and there were multiple errors, every time I thought I fixed one thing a different error came up. It simply refused to work.

Then I got very lucky! Buried down in the comments on one of the many web pages was a link to the EFCorePowerTools Visual Studio extension. It adds GUI support for doing common tasks related to EF Core. One of those tasks is generating POCOs. Plus since its part of the GUI it doesn’t care what packages are added to the target library, so no need to add design and tooling to production libraries! Installed the extension, restarted Visual Studio and within 2 minutes I had the POCOs generated no problem.

Its worth mentioning that EFCorePowerTools is not from Microsoft! We have Erik Ejlskov Jensen to thank. Why in the world Microsoft didn’t do this themselves is beyond me. Very poor.

Before finding that extension I was keeping notes so I could write up my own web page on how to try and deal with Scaffold-DbContext. But after finding the extension I realized who cares and tossed them. Time will tell if it has any maintenance shortcomings, but for now it makes life so much better.

Comments closed

JavaScript == Spaghetti Western

The world of JavaScript is the like the Wild West in that there are few constraints and nearly anything goes. Some frameworks are trying to make it better, but regardless a whole lot of JavaScript I’ve seen is Spaghetti_code (a mess).

Random thought that I had while I was writing something else. I hadn’t heard the term “Spaghetti code” in years but it popped into my head when thinking about JavaScript.

Comments closed

Adventures in .NET Core

I’ve been slowly moving towards .NET Core for awhile and have decided now is a good time to try and take the full plunge.

Initially it was just too new and incomplete to be of use. When .NET Standard reached v2 I started writing most library code in that instead of .NET Framework. By targeting .NET Standard those libraries could then be used by not only .NET Framework and .NET Core applications but also Mono, Xamarin, etc. Plus there are some other advantages to the way .NET Standard library projects work that I won’t go into here. But beyond libraries I only dabbled in .NET Core applications mainly because of Entity Framework.

Entity Framework has become an awesome, almost indispensable ORM in no small part due to the integration of LINQ. Entity Framework 6 is very capable and mature; It works. Entity Framework Core is a complete rewrite and lacks some of the capabilities present in EF6. Plus I personally find the emphasis on Code First and at best limited support for database first rather alarming. As someone with strong experience in both Software Engineering and Database Administration I’ve always suspected Code First would lead to compromises in the database. EDMX files may not be fun but they allow for a very productive workflow and don’t require any compromises.

Given the above and the fact that .NET Core has reached a good level of maturity I’ve decided it is time to set off on an adventure to explore what it can do, can’t do and how it works. In addition to .NET Core I’ll use this adventure to also try out some of the other new Microsoft technologies such as Xamarin.

To do this I’m going to come up with a small but meaningful (non-trivial) application to build. I’ll use SQL Server 2017 for database storage and make sure that the database schema includes important capabilities such as keys, indexes, GUIDs, etc. On top of that I’ll use ASP.NET MVC Core to build a RESTful API backend which will provide all the capabilities clients require. Then I’ll build multiple client applications using various technologies that access the backend API.

Now that Microsoft is finally playing nice with others there is literally a myriad of client possibilities! Just in the realm of web applications there is an almost daunting list of possibilities:

  • Old school ASP.NET Core with MVC, Razor, Bootstrap and jQuery
  • ASP.NET Core with Angular 2
  • ASP.NET Core with Knockout
  • ASP.NET Core with React
  • ASP.NET Core with React + Redux
  • Non-core ASP.NET MVC with Razor, Bootstrap and jQuery (for comparison)
  • Non-core ASP.NET Web Forms since they are still used in some older systems

There is also an impressive list of non-web client possibilities:

  • WinForms
  • Windows Presentation Foundation (WPF)
  • Universal Windows Platform
  • Android using Xamarin
  • iOS using Xamarin
  • Mac using Xamarin
  • Unity if I wanted to dabble in the world of game programming
  • Maybe even a Linux client using Mono

It would be really interesting (and fun) to build all of those and then compare them. That would be awesome, but in reality I probably don’t have that much time to spend on this. At least for now, maybe I’ll keep this going and get to all of them eventually.

Regarding web applications Angular 2, React, and Knockout apps on ASP.NET Core is a really interesting and helpful blog post by Steve Sanderson.
by

I’ll detail my journey through the world of .NET Core in upcoming posts.

Comments closed

What is the difference between Application Programming vs System Programming?

Low level infrastructure software (aka system programming) is what makes up the foundation of operating systems and development platforms. This type of software requires machine code that runs directly on the CPU and can effectively communicate directly with the various hardware components. The end users of software built using system programming is mostly technical people and other programmers.

The vast majority of developers working today write applicaiton code. Application programming is the practice of building software that runs on an operating system or runtime platform. Microsoft Windows, Android, iOS and web browsers are examples of platforms that applications are built on. Application code doesn’t interface directly with hardware, instead it relies upon the OS / platform to provide all the required services. Applications are built for end users and business people who may possess little if any technical knowledge.

Comments closed

Dark Style

As you can probably tell from the look of this blog and my business web site I use the dark theme in Visual Studio. The light theme with all the white backgrounds just never looked right to me for writing code.

Comments closed

Blender is pretty cool

I first played around with 3D modeling and rendering way back on the Commodore Amiga. That cool little computer was ahead of its time. Messed around with 3D Studio Max years ago while building a game engine for Cyberdyne Interactive. But haven’t given it any thought in at least a decade.

I love my OOriginal Coder logo and wanted to get a 3D version of it. My skills are way out of date and last I checked a decent 3D system was a couple thousand dollars so I hired someone to create a 3D model and render it. In the middle of that I discovered Blender. Its an extremely capable full blown 3D modeling, animation and rendering system that is completely free. This thing has way more features than the old version of 3D Studio Max I used years ago.

The 3D model I got back of my 2D logo was pretty good but I didn’t like the angles and lighting on the rendered images. So I tossed the model into Blender and rendered my own output. Took me less than 30 minutes to watch a quick YouTube tutorial, setup the scene and render it. My modeling skills still suck but now I know that if I ever want to mess around with 3D I could do it for free without having to sacrifice capabilities.

1 Comment

Now I’ve done it. I’ve gone and started a blog.

This (dreaded?) day has finally arrived. I’ve started my own blog. More than that, I’ve started a “professional blog”. Which means this is going to take work. While I find writing C# professionally fun the idea of having to write English prose as work doesn’t sound appealing.

Sure, I’ve thought about doing this numerous times over the years. I kinda feels like at my experience level I’m rather expected to have a blog. Long ago I did have a LiveJournal that I posted to regularly. That used to be a thing, if you never heard of it that should indicate how long ago that was.

On the bright side I am passionate about and do love software development. I have an insanely large amount of experience and have worked on a wide array of systems spanning the entire spectrum of scale. And I care about software development and producing the very best architectures and code possible for any given situation. So maybe having a blog won’t be so bad.

Comments closed
Featured Post

Welcome to my blog!

I’ll mostly be posting about software architecture & development since that’s what I know best. There will also be some posts about IT, the cloud, the Internet and similar stuff. Occasionally I may toss in a piece of trivia or a quote. If you have thoughts, ideas or questions please leave a comment!

Comments closed
Site and all contents Copyright © 2019 James B. Higgins. All Rights Reserved.