Component development decision: low level or high level techologies?

If you want to develop software components targeting other developers and their projects, you should carefully decide what technologies would you develop for and support:

  • Low level technologies, e.g. C++ or JavaScript (HTML5);
  • High level technologies, e.g. .NET (WPF/Windows Forms/ASP .NET) or Angular.

Usually if you choose a low level technology you can always develop extensions for the high level technologies on top of your core components, but the core development will be hard and the target developers that choose high level technologies for their app may feel that you didn’t develop the component natively for their development choice.

If you choose high level technologies, you will need to design the component once but then implement everything in each of the selected technologies (you will also need to know well all of them). And unless you also decide to develop components also for low level technologies, developers that build apps directly using such core frameworks will be left out.

E.g.: If you develop a C++ chart component you can easily write WPF and Windows Forms wrappers, but you’d lose the support that either WPF or Windows Forms offer for developing graphics components and target developers may notice that the component isn’t behaving exactly as other WPF or Windows Forms components they know. Similarly, if you develop a JavaScript chart you can write an AngularJS directive (and soon an Angular 2 component) on top of it, but the core code will be hard to write. On the other hand if you develop chart components for WPF, Windows Forms, and ASP .NET and/or for Angular you will need to have and maintain multiple code bases (usually one for each target technology). And what about developers who want to use pure C++ or pure JavaScript for their apps?

It’s tough. Although with .NET you have COM and Win32 interoperation (and JIT compilation to obtain higher performance), and for JavaScript you have TypeScript (as high level-low level technology mediation) and “WebBrowser” containers (to run scripted Web documents inside other types of apps), the choice is never easy. You might have already answered yourself, but you may be wrong. Looking back, I can certainly state that I was wrong too, a few times in my developer life, and it would have been a lot better if I would have just thought more carefully before choosing!

Personally, I now think that to answer correctly these three things matter the most:

  • the type of components you want to build (although this doesn’t balance much to one side or the other);
  • how much maintenance do you think it would be needed (but this is easily answered in most cases: a lot);
  • surprisingly, or not, the development trends: simply determine how many target developers would you have for each selectable low level and/or high level technology you can consider (Google Trends is a service that can help you. Below is a chart with the trends for some of the technologies mentioned in the previous examples).


Technologies.png

Advertisements

About Sorin Dolha

My passion is software development, but I also like physics.
This entry was posted in Architecture and tagged , , , , . Bookmark the permalink.

Add a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s