Cross-Platform-Blog.com

Electron.NET – Create a minimal MusicPlayer App with ASP.NET Core 2 for the Desktop

2017-10-27T00:00:00-00:00

Actually, this blog is addressed to Cross-Platform development with JavaScript. But this time, I have a very special treat for you: Electron.NET! A new open source project which I developed in cooperation with my Microsoft MVP colleague and friend Robert Muehsig.

As the name confirms, we developed an Electron derivation for .NET Core. This allows to develop Cross-Platform desktop applications with C# and ASP.NET Core. We haven´t reinvented the wheel. The runtime is based on Electron. So Electron.NET is build on an advanced and solid platform.

This article shows on a plain sample how easy it is, to develop Cross-Platform desktop software with Electron.NET and ASP.NET. We will develop a MusicPlayer, which has access to the music list to play any song we want.

Preperations for the start:

A new ASP.NET Core 2 project

First of all, we create a new ASP.NET Core Web Application. Then choose the empty template and make sure you got ASP.NET Core 2.0 selected.

Picture 1 – Create a new ASP.NET Core 2 project

Next, we need to install MVC via NuGet Package Manager:
Install-Package Microsoft.AspNetCore.Mvc -Version 2.0.0

Once installed there is a little work to do, before we can start. We will need to add a little something to the Startup.cs. At first we need to configure the app to use the MVC framework.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
}

In the next step we have to configure the app to use the MVC request execution pipline (routing), with a default route.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{ 
    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });

    // ...
}

Now that the MVC framework has been added we can add a Controller and a View to the project. Therefore we add a new folder, which we call Controllers. Then, right click on it to add a new Controller.

Picture 2 – Add a new Controller

The HomeController will be added with a default method called Index. To add a view we need to right click on View() and select AddView.

Picture 3 – Add a new View

A new views folder including the Index.cshtml has been created automatically. The ASP.NET MVC Core project is now ready to implement some logic.

Add Electron.NET

There are just a few more things to do, so we can run the ASP.NET MVC Core 2 application with Electron.NET. Of course we´ll need to install Electron.NET API through the NuGet Package Manager:
PM> Install-Package ElectronNET.API

The UseElectron WebHostBuilder-Extension will be added to Program.cs then.

public static IWebHost BuildWebHost(string[] args)
{
    return WebHost.CreateDefaultBuilder(args)
        .UseElectron(args)
        .UseStartup<Startup>()
        .Build();
}

That´s it! Now Electron.NET can be used in our project. So far, nothing would happen, if we would run the project now. The application would just run in the background. Because we do not want to develop any background processes, we´ll add some bootstrap code to Startup.cs, so an MainWindow will appear. Additionally we want the security option to be disabled. This will allow us to get access to the music list.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });

    Bootstrap();
}

public async void Bootstrap()
{
    var options = new BrowserWindowOptions
    {
        WebPreferences = new WebPreferences
        {
            WebSecurity = false
        }
    };

    await Electron.WindowManager.CreateWindowAsync(options);
}

Access to the file system

We will need access to the file system within the HomeController now. To do so, the Electron.NET API gives us the opportunity to detect the path of the current platform of the music list. With .NET Core we get access to the filenames within the list. We´ll pass the results to the view then.

using ElectronNET.API;
using ElectronNET.API.Entities;
using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;
using System.IO;
using System.Threading.Tasks;

namespace MyElectronMusicPlayer.Controllers
{
    public class HomeController : Controller
    {
        public async Task<IActionResult> Index()
        {
            string musicPath = await Electron.App.GetPathAsync(PathName.music);
            string[] mp3Files = Directory.GetFiles(musicPath, "*.mp3", SearchOption.TopDirectoryOnly);
            string[] mp4Files = Directory.GetFiles(musicPath, "*.mp4", SearchOption.TopDirectoryOnly);

            List<string> musicFiles = new List<string>();
            musicFiles.AddRange(mp3Files);
            musicFiles.AddRange(mp4Files);

            return View(musicFiles);
        }
    }
}

The View

The view and functionality is easy and not that much spectacular in this example. So there will just be shown a list of the music files which will play by button click. To do this, the HTML5 audio class will be used.

@model List<string>

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>My Electron Music Player</title>
    <meta charset="utf-8" />
</head>
<body>
    <h3>My Music</h3>
    <ul>
        @foreach (string musicFile in Model)
        {
            <li>
                 @System.IO.Path.GetFileNameWithoutExtension(musicFile)

                <button onclick="playMusic('@musicFile.Replace(@"\", "/")')">Play</button>
            </li>
        }
    </ul>

    <script>

        function playMusic(musicFile) {
            let audio = new Audio(`file:///${musicFile}`);
            audio.play();
        }

    </script>
</body>
</html>

Start of the Electron.NET Application

The Electron.NET CLI is necessary to execute the Electron.NET application. Unfortunately, we need to install the CLI by adding a reference to .csproj file instead of an installation via NuGet as usual.

<ItemGroup>
       <DotNetCliToolReference Include="ElectronNET.CLI" Version="*" />
</ItemGroup>

Then run dotnet restore in the console.

If it´s a new Electron.NET project, it is necessary to run dotnet electronize init once. For that there will be a electron.manifest.json file generated an a new debugging profile will be provided.

The command dotnet electronize start will start the ASP.NET MVC Core 2 application as a desktop software.

Important! The first start may take a while. We are working on a solution to speed this up.

Picture 4 – The Electron MusicPlayer application

Building the application

The Electron.NET CLI also makes it possible to build an executable application for Windows, Mac and Linux. Every platform does this with the dotnet electronize build command:

dotnet electronize build win
dotnet electronize build osx
dotnet electronize build linux

Important! A Mac or Linux device is required to build Mac applications.

Summary

We´ve seen in this sample, how easy it is to create a desktop software using ASP.NET MVC Core 2. We get access to the files by using C# and send those information to the MVC view, which is actually not possible through a Web-Browser.

You´ll find additional examples in the API demo app. You can try to access an OpenFile dialog so the sample application can read other files as well, if you want to. And maybe there could be a little shortcut to select songs randomly. Just as a little extra 😊 Leave a comment below if managed it.

Here´s the MusicPlayer on GitHub
Here you´ll find the Electron.NET API Demo App on GitHub

How do you like Electron.NET? I´m excited about your feedback in the comments.

Electron.NET – Create a minimal MusicPlayer App with ASP.NET Core 2 for the Desktop was originally published by Gregor Biswanger at Cross-Platform-Blog.com on October 27, 2017.

Interview with webpack founder Tobias Koppers

2017-03-04T00:00:00-00:00

Tobias Koppers is a freelance software developer and consultant from Nuremberg. He became famous as author of webpack, which is used by millions of developers worldwide. His focus is on JavaScript development and open source projects. I had him in an exclusive interview, which I would not want to keep away from you. Have fun while reading it.

Gregor: Hello Tobias, the whole JavaScript world talks about webpack. Even Google is based on it and has integrated it directly into the Angular CLI. I am also particularly proud of the fact that webpack comes from Nuremberg, so close to my hometown Ingolstadt (Germany). Tell us the story, how you came up with the idea and how webpack could spread so quickly.

Tobias: Hi Gregor. In fact, Google was also involved in the development, if only indirectly. Before I was addicted to JavaScript, I also worked with Java. There is a tool from Google that allows to develop a client-side web application in Java: Google Web Toolkit (GWT). This is a Java-to-JavaScript compiler for SPAs, which is also based on some Google applications.

At the GWT there was one feature which I was totally into: Code Splitting. This allows, among other things, rarely used code to be loaded later. This feature is especially important for large applications to keep the initial load time small. I missed this feature in existing JavaScript-Tooling (2012) and this was when the idea of webpack was born.

That means, webpack was created with the focus on code splitting, and in my opinion that was the reason why it was so common. With the growing size of web applications and the increased use of mobile devices (with weak network connectivity), they have grown the relevance of code splitting over time. Otherwise the desired performance is difficult to implement.

Gregor: Many compare webpack with task tools such as NPM scripts, Grunt and Gulp. Some have really found their replacement with webpack. I will use NPM scripts and webpack in future on. What’s your opinion on this and do you use a task tool in addition to webpack?

Tobias: NPM scripts are enough for me. In fact, it is not really correct to call webpack as a substitute for Grunt / Gulp. Grunt and Gulp belong to another category of tools like webpack. Grunt, Gulp and NPM scripts are task runner.

Webpack is a Module Bundler. These are tools with different objectives. But it is true that webpack simplifies the necessary “tasks” to build a web application so far that it is possible to use an overkill TaskRunner like Grunt and Gulp and NPM scripts are sufficient. NPM is the replacement for Grunt and Gulp.

However, task runner still have their own reasoning for other tasks besides the pure building of the web application: deployment, linting, version management, etc.

Gregor: With my JavaScript trainings, my participants are telling me over and over again, how difficult it is to start with webpack. Did you get similar feedback already? If so, do you already have ideas on how to improve that?

Tobias: Yes, indeed, this feedback comes. However, many users also say that once it has “clicked”, it is actually quite simple to use. Anyone who can “web” even says that it is easier than the previous tools.

I believe this feedback is due to the fact that the concepts of webpack differ significantly from the concepts of other tools. Especially when migrating from Grunt / Gulp to webpack. Task runner have a more imperative configuration, that is describing the steps to be performed by the task runner. Webpack, on the other hand, has a declarative configuration, that means, it does not describe the steps to be executed by webpack, but only describes the way in which these steps are to be executed or how the result has to look.

Gregor: What’s on your agenda? What features are planned for the next webpack version?

Tobias: That’s not quite clear yet. There are so many things that are possible. Just to mention a few exciting points:

Scope Hoisting: small and more powerful way to connect the modules
WebAssembly: Support for binary code in the WebApp
Persistenter cache: Faster initial compilation
CSS (and HTML) as first-class citizen: More support for stylesheets (and HTML)
And many exciting little things

The users and sponsors decide in which order they will be targeted. We have a voting page, where you can vote for the next points. Everyone gets an influence every day and sponsors and contributors get golden points of influence for donations and contributions. This happens from the motivation of sponsors and contributors, because they wanted to give something back. In addition, it is of course interesting what users want the most.

Gregor: Can you give us a top best practice tip on webpack?

Tobias: Use On-Demand-Loading. It is super easy to use and it works out incredibly.

Gregor: What are your personal goals? Will we all soon read, that you’re going to work at Google in Mountain View? ;)

Tobias: I don’t think so. I will be working as a freelancer soon. I will try to work as much as possible on open source and finance the whole thing through donations. Since donations are usually not enough, I will finance the rest through commissioning or consulting. I’m already curious how this works. Maybe there is a sponsor for me, who will finance a few additional weeks Open Source (hey Google ;)).

The effort to maintain an open source project is often underestimated. Currently, Code Reviews and Issues take 80% of my time. I neither have enough time to write code myself, nor to refactor. I even have to leave pull requests behind for a while. I need to find the time to look at them in detail. This is not really motivating the contributor of course. I think this will change, as soon as I work on webpack full time. Hopefully I have more time to write more code.

Gregor: Thank you very much for taking the time for the interview! Thanks also for webpack, which supports us as JavaScript developers extremely. I love your tool!

Tobias: You’re welcome. My thanks goes back to the community. Webpack is not “my” tool, it is designed by more than 500 contributors. Webpacks success is also because of its great ecosystem.

Interview with webpack founder Tobias Koppers was originally published by Gregor Biswanger at Cross-Platform-Blog.com on April 03, 2017.

JavaScript Coding Dojo: The DictionaryReplacer Kata

2017-03-02T00:00:00-00:00

A dojo is the exercise room of Japanese martial arts. The exercises itself are called kata. The coding dojo is about mastering an exercise (kata). According to the motto “Learning by doing”. The cross-platform blog will now regularly publish JavaScript Katas.

The DictionaryReplacer Kata

This kata is about making a simple string replacer. It is inspired by Corey Haines Lightning talk about practicing. Create a method that takes a string and a dictionary, and replaces every key in the dictionary pre and suffixed with a dollar sign, with the corresponding value from the Dictionary.

Tests:
input: “”, dictionary: empty, output: “”

input: “$temp$”, dictionary: [“temp”, “temporary”], output: “temporary”

input: “$temp$ here comes the name $name$”, dictionary: [“temp”, “temporary”] [“name”, “John Doe”], output: “temporary here comes the name John Doe”

Difficulty: Simple
Duration: Ca. 5-20 Minutes
Source: http://codingdojo.org/kata/DictionaryReplacer/

Preperations for the start

The following is required for the project:

Node.js (runs on Windows, Mac and Linux)
TypeScript
type npm install typescript –g in the terminal
Visual Studio Code (runs on Windows, Mac and Linux)

There has already been deposited a complete exercise project on GitHub for you:

git clone https://github.com/GregorBiswanger/KataDictionaryReplacer.git

Then install all necessary modules within the project with npm install.

You have never worked with TypeSript before? Don`t worry! TypeScript == JavaScript, and you can use your existing JavaScript knowledge without problems. The advantages? Go and find it out by yourself in the code exercise. ;) A significant difference is that the file ending is * .TS. The TypeScript created javascript and source map files are hidden for this exercise. This provides a better overview. In the file system, however, these exist.

The start

Open the project with Visual Studio Code
Start the TypeScript compiler with the key combination [ctrl] + [shift] + [b]
At the terminal, write npm test within your project

Now the testrunner Jasmine is running. It notices file changes automatically. If you have a second monitor, there is the ideal place for the terminal. This allows you to observe the current status during development.

The process

Important with Coding Dojos is, to solve every task step by step. This principle is not easy for many developers. But exactly this is, what coding dojos are teaching us.

Which tasks have to be performed step by step can be found in the spec directory. The actual programming takes place in the src folder.

Debugging

The project already has all the necessary Visual Studio Code settings, so you can easily debug within the tests or your own code. Simply set the breakpoint with the [F9]-key and start the debugging with [F5].

Rules

Solve the kata until all tests are green
Then copy your solution here on jsfiddle.net:
https://jsfiddle.net/GregorBiswanger/n6zm9wz7/
Click on the “Update” button in the upper left corner and comment on your link here at this blog post
Not till then, you are allowed to compare your solution with already commented solutions

Let’s get ready to rumble!

With my JavaScript Workshops I always like to do Coding Dojos with my participants. I love to evaluate the different solutions afterwards. I`m excited about how you will solve the task. And now: Let’s get ready to rumble!

JavaScript Coding Dojo: The DictionaryReplacer Kata was originally published by Gregor Biswanger at Cross-Platform-Blog.com on February 03, 2017.

Node.js: A REST Web-API with Express.js and TypeScript

2017-30-01T00:00:00-00:00

There is one Web-Application Framework, which has been strongly enforced with Node.js: Express.js. It has been inspired by the Sinatra-Framework, known of the Ruby world. It extends the Node.js Build-In modul http, so developing a modern web-app will be simplified:

Comparable to the Microsoft Web-API (just better :))
Communication with REST (HTTP) is norm
Request/Response-Handling
Routing
View Templating
Session Support
Static Files Support
Middleware
- e.g. functions, which are able to log between request and response (Logger etc.)
and many more…

The installation

At first we need to create a new Node.js project with a TypeScript compiler configuration and the appropriated Visual Studio Code build and debugging configuration. Those steps have already been explained in detail in the following article:

Visual Studio Code: Node.js with TypeScript and Debugging

In addition to that, Express.js and the associated TypeScript declaration is needed. To include them, you just need to write following in the terminal within the project:
npm install express –save
npm install @types/express –save-dev

The first Express.js „Hello World“

We create a new index.ts file or replace the existing file with this code:

import express = require('express');
let app = express();

app.get('/', function (request, response) {
    response.send('Hello World');
});

app.listen(3000);

The code is very similar from the usual “Hello World” example for Node.js. The differences: Express.js creates a web server automatically in the background with the listen function. The query for REST is given explicitly, like in this example with get. Routing is then set with a string value. When the request is processed, an anonymous function is executed as usual, but no stream has to be explicitly terminated here. This is why Express.js takes care of itself automatically.

The GET function with parameter

A REST GET action is stored using the get function. Routing is defined by string and parameters are additionally marked with a colon and variable names. As the following example shows:

app.get('/api/sayhello/:name', (request, response) => {
    let name = request.params.name;

    if (!isNaN(name)) {
        response
            .status(400)
            .send('No string as name');
    } else {
        response.json({
            "message": name
        });
    }
});

In Visual Studio code, start the TypeScript compiler [ctrl] + [shift] + [b] if it is not already running. Next, execute the application with [F5].

Then type http://localhost:3000/api/sayhello/John in the browser. The Web service should now return the following JSON value:

{
    "message": "John"
}

The following return functions are possible with the Get function:

render for HTML content using View Engine
send for text content
json for JSON content
redirect for forwarding

Queries

Ordinary query parameters can also be queried. These are located under request.query.PARAMETERNAME. Additional routing is not required.

app.get('/api/sayhello/', (request, response) => {
    let name = request.query.name;

    let result = {
        message: name
    };

    if (!isNaN(name)) {
        response
            .status(400)
            .send('No string as name');
    } else {
        response.json(result);
    }
});

Next, execute the application with [F5]. Then type http://localhost:3000/api/sayhello?name=NodeJS in the browser.

The post action

Provide a post action by a post function. In order to process regular Form-Submit POST requests, however, two additional packages are required:

npm install body-parser multer --save

These are relevant for parsing multipart/form-data and application/x-www-form-urlencoded. As a single-middleware, upload.array() is also included in the post function. Forms sent data are queried through request.body.VARIABLENAME.

import express = require('express');
let app = express();

// For POST-Support
let bodyParser = require('body-parser');
let multer = require('multer');
let upload = multer();

app.use(bodyParser.urlencoded({
    extended: true
}));

app.post('/api/sayHello', upload.array(), (request, response) => {
    let name = request.body.name;

    if (!isNaN(name)) {
        response
            .status(400)
            .send('No string as name');
    } else {
        console.log('Hello ' + name);
    }

    response.send('POST request to homepage');
});

app.listen(3000);

Tools such as Postman are suitable for testing. At Postman select “POST” first and type in the URL field http://localhost:3000/api/sayhello/. The following query comes directly below:

Now click on the next button and directly below the response data will appear. In Visual Studio Code you can debug the post request.

Conclusion

With Express.js you can quickly and easily provide web services and much more. In other articles I will go even deeper and further into this great Web Application Framework. The source code for the examples is based on GitHub:

Code on GitHub

How do you like Express.js? I’m looking forward to read your opinion in the comments.

Node.js: A REST Web-API with Express.js and TypeScript was originally published by Gregor Biswanger at Cross-Platform-Blog.com on January 30, 2017.

Visual Studio Code: Node.js with TypeScript and Debugging

2017-27-01T00:00:00-00:00

Visual Studio Code is a free code editor of Microsoft with an excellent TypeScript and Node.js development support. This blog post describes how easy it is to create a new Node.js project with TypeScript support. And at the end, we will also debug a small “Hello World” example.

The example in this article provides to setup the following:

Node.js - http://www.nodejs.org (runs on Windows, Mac and Linux)
TypeScript
type npm install typescript –g in the terminal
Visual Studio Code - http://code.visualstudio.com (runs on Windows, Mac and Linux)

A new project

To create a new project, the only thing we need is a new folder in our file explorer. Afterwards, we open the created folder in Visual Studio Code File | Open Folder. As project file the packages.json file is needed. To include it, we just have to write npm init –y in the terminal. You can open the integrated terminal in Visual Studio Code using the keyboard shortcut [Ctrl] + [`].

Install Node.js declaration files

To ensure that Visual Studio Code can solve Node.js features within IntelliSense, the TypeScript declaration files for Node.js are required. They will be installed with the node package manager (npm) since TypeScript 2. The command npm install @types/node --save-dev will have it done. To install other packages like jQuery for example, you would have to call npm install @types/jquery --save-dev.

TypeScript compiler configuration

For a proper Node.js support with TypeScript, a compiler configuration file is absolutely necessary. It will be created as tsconfig.json in the root directory. Thanks to the JSON IntelliSense feature of Visual Studio Code, which automatically provides an autocomplete on the basis of the filename. So you just need to write the first curly braces and IntelliSense will autocomplete it with the shortcut [Ctrl] + [.]. The IntelliSense support only works with an existing internet connection. In this case you need write the following compiler configuration:

{
    "compilerOptions": {
        "module": "commonjs",
        "sourceMap": true,
        "watch": true
    }
}

Module: In a typical web application, the browser obtains the JavaScript files via the Script tag. With Node.js, the JavaScript code will be executed irrespective of the website. This is the reason, the modul system CommonJS has been developed. It allows to load JavaScript files within the JavaScript code. Because of that, TypeScript needs to know which modul system is used, so the “import” and “export” code will be generated automatically.
Source Map: As the name suggests, debugger-service maps will be generated here. They support the debugger to solve a code area of the TypeScript file to the generated JavaScript file. So it is possible to debug right within the TypeScript file.
Watch: The watch option helps to prevent to start the TypeScript compiler before each debugging. It monitors all TypeScript files for changes. If a file changes, the compiler is automatically activated. So the compiler has to be started only once.

The first Node.js „Hello World“

Now we create an index.ts file. The following code is required for a “Hello World” example:

import http = require('http');

http.createServer((request, response) => {
    response.write('Hello from Node.js!');
    response.end();
}).listen(3000);

The first line begins with a TypeScript-specific keyword import. Thus, TypeScript knows that there must be a declaration for this module. If there is no declaration file or a TypeScript code in the project, let is written as usual. Then we access a Node.js build-in module called http. The first line is comparable to a using, import or include from other high-level languages.

From line 3, a Web server is already being created. When calling, the anonymous function is triggered and a streaming to the client is active. Here we get all client request information with the request parameter. We can use the response parameter to append data to the current stream. The simple write function was used to send a simple string value. To terminate the current stream, the end function is required. With the listen function, the current web server is activated for the defined port. That’s it!

Start the TypeScript compiler with Visual Studio Code

The TypeScript file was written, but a JavaScript file is needed to run it. The key combination [Ctrl] + [Shift] + [b] prompts Visual Studio Code to build the project. Alternatively, you can open the command line with [F1] and type Build. Now Visual Studio Code does not know what exactly it should do. So it will ask you, what exactly you want. We choose TypeScript - tsconfig.json here.

A new directory is created with .vscode and a tasks.json file is created. The pleasant thing about this template is that all relevant settings are already stored. So we can close this file and call the build process again with [Ctrl] + [Shift] + [b]. Left below we can see a rotating character and in File Explorer we can see two new files for our TypeScript file. One is the generated JavaScript file and the other is the SourceMap file which is required for debugging.

Debug the Node.js application

There are different ways to run the application. One way is to start from the terminal using node index.js, regardless of Visual Studio Code. The only bad thing is, we have no debugging comfort here. Therefore we use the second option: We press the [F5] key within Visual Studio Code to debug. Again, Visual Studio Code does not know what exactly it should run. We select node.js.

A further JSON file is created in the .vscode directory. It is important to note that the JavaScript file name corresponds to what we have created and that the option SourceMaps is activated. Otherwise, we can only debug within the JavaScript file. Then press the [F5] button again. The server has now been started. If we press the [F9] key in the response.write line, or alternatively next to the line number, we get a red breakpoint. Now go to the browser and call your web server with http: // localhost: 3000. Visual Studio Code then stops at the breakpoint and you can check all the parameter values as you are used to debugging other high-level languages.

If there are problems, it is mostly because you have forgotten to start the TypeScript compiler once. Therefore, check whether your JavaScript and SourceMap files were generated.

Conclusion

Visual Studio Code is a great tool for development with Node.js and TypeScript. With just a few lines of code, we have created a web server and a REST Web service. Completely without IIS, Tomcat or Apache HTTP Server. The example I have deposited here on GitHub:

Code on GitHub

Did the article help you? Do you have any questions? Then write me a comment!

Visual Studio Code: Node.js with TypeScript and Debugging was originally published by Gregor Biswanger at Cross-Platform-Blog.com on January 27, 2017.

Welcome, beautiful new world…

2017-22-01T00:00:00-00:00

…which I get to know for more than 3 years with JavaScript. After more than 10 years as a .NET expert, it was definitely not an easy step to change my focus. I started as a developer in the business by using PHP. Back then, JavaScript was just a means to an end. I was glad, the lesser I had to use it.

As excited and ideal platform I got attracted to .NET and C#. I have to admit, in between I gave Visual Basic a try, but it didn’t really made me happy. I was thrilled by Microsoft and .NET, so I organized a great community in my hometown Ingolstadt. I visited communities and conferences around the world and talked about my experiences. I initiated the biggest community roadshows with thousands of attendees. I also wrote books and articles for technical magazines. To make a long story short: I worked hard on my carrier and to be known in the Microsoft developer world.

Moving in a new direction

Time changes everything, also the customer requirements. At numerous meetings with customers the most recent topic was „bring your own device“. There were Managers in front of me using their Windows, Mac or Linux computers. Everyone wants to know the true promise of the new software and at the end, the final winner always was the browser. A .NET solution couldn’t pay that much attention anymore. I realized, the focus of .NET changed to the back-end and cloud development. Of course there still is Xamarin, which brings .NET to mobile devices. But it had a lot of disadvantages compared to Apache Cordova while we worked out our proof of concepts.

When I concentrated on JavaScript and LISP, I could understand Douglas Crockfords statement: „The World’s Most Misunderstood Programming Language“. Because of our customer Intel, we approached to Node.js more and more. Projects like Adobe Brackets (where I took part of) are completely developed in Node.js and JavaScript. We completely rewrote our software of CleverSocial from ASP.NET MVC4/Entity Framework/SQL Server to Node.js, Angular 2 and MongoDB. We learned and felt the power of the new JavaScript World. My conclusion has been, that the JavaScript development is way more efficient and faster. At the end you will have a high-speed Cross Platform solution. In this interview of Entwickler.de, I explained in details why I changed my technical focus. I’m afraid, the interview is in German. It’s called “Was .NET-Entwickler über Node.js wissen sollten” which means: „What .NET developers should know about Node.js“

Give up everything?

Not at all! Just a week ago, I had a workshop about the .NET development with Microsoft Azure. At the same night I had a speech at my home community, called INdotNET, about XAML. We’re working intensive with a Microservices architecture. If we need a specific strength of .NET, the solution will be exhausted. The data communication of the Entity Framework to the SQL server for example. Then we are using an ASP.NET Core Web-API with Entity Framework Core or even an elderly fully developed Entity Framework 6. Also I will continue on writing my XAML Expertise column for the Windows.Developer-Magazine. Finally I still have a lot of customers who are using WPF.

Conclusion

I worked with JavaScript for about 70% of my time and just 30% with .NET in the past 3 years. I got to know all the benefits of JavaScript and I would love to share them with you here on my new blog. You will see how simple the JavaScript development is, to this I will write generally about JavaScript/TypeScript, Tooling, Angular, Node.js, Electron, Cordova, MongoDB and many more.

Have you changed your focus to JavaScript as well? If so, I would love to hear about your story in the comments below. Apart from that, I’m looking forward to share my new knowledge with you. I’m also available for workshops, trainings or consulting. Just send me an E-Mail.

And now, have a lot of fun on my new blog.
Gregor

Welcome, beautiful new world… was originally published by Gregor Biswanger at Cross-Platform-Blog.com on January 22, 2017.