Converters in Dart

In 2001 I was writing my first open source 'ZATreeX' which is a GUI to manipulate data regardless of what data structure is underneath. a tree Data structure was expressed though an interface (DataObject if my memory is good), and operations were also expressed through an interface that received that data and processed it. The "reference implementation" was made on the io file system...

As you expect, I'm not going to talk about that old product, but rather about generic concepts. "Making operations on data" is all what IT is about. Data differs, the operations differ, but this pattern is always there. So a language that includes this concept already in its core libraries is a language that is ready for the IT needs and this is perfect for programming efficiency:

Usually when you begin a mission (or revisit an old project), you have to spend a lot of time understanding how a given problem is solved (expressed) in that particular project. Usually there are some different possible ways, so you end up "decrypting" which of the ways the programmer chose (because you expect is somehow in one of the possible ways). Then comes the naming  issue: each person gives different names to his classes/methods and you have to understand which names correspond to the concepts you expect to find in the code. Documentations are useful for that, but frameworks are even better.

With a framework, you have a ready naming "convention" that everybody understands: when you say "Session Bean", "Struts Action", "Spring Prototype Bean", everybody understands what you're talking about and you can start explaining at a higher level...

But frameworks are many, and they compete. Therefore Sun microsystems, created the JSR to specify "standard ways" for the many existing frameworks: handling XML, database persistence, server communication (servlets)... but also more deep subjects such as transactions (JTA), connectors (JTC), extensions (JMX).

This way, a newcomer can immediately start working on a project without dealing with the specifics of a framework...

The earlier a language comes with "standard" libraries, the easier it is for the community to adopt it, since there are no time losses trying the different framework solutions and learning given solutions in the context of a project.

Converters and codecs are a central part of IT as explained in the introduction, so it's a very good news that it was addressed from the very start. here is a blog talking about the technical part of the subject

How to write efficient conversions

Written by Florian Loitsch 
February 2014

Converting data between different representations is a common task in computer engineering. Dart is no exception and comes with dart:convert,...

Dart is becoming a js libraries ambassador

We could have thought that dart will position itself as an alternative to js libraries like Node.js, Angular, JQuery etc...

In fact, those libraries exist for some time already and propose rich functions that could be reused directly instead of having to write them in another language, test, debug, and maintain. So in short, people who are used to a js library will hardly want to learn a new language that will bring them troubles and hand work.

The issue with raw Js libraries is that you have to write your own js code to use them, and if you have complex tasks, you can find your self solving browser incompatibility problems, dealing with the js development tools that are limited since it's a script and there are too few assumptions the tools can make for you.

Because of that need, and because dart is a well thought language "that needs fewer lines to say the same things". Projects like AngularDart will inevitably emerge for the most active existing Js libraries.

More complex js "plaforms" will have to adapt: The more the platform was bringing services, the more it will have to do gymnastics to delegate some services to dart or parts of services.

Some blog posts still compare dart with js technologies like this interesting comparative table but this hard choice to do -especially if you have to learn a new language- cannot be left as a statu quo, there are too many things to win in joining instead of competing those technologies.

I'm sure the direction it is taking is not a concurrence but answers to real life problems like "How could I bring that feature to my project without being hardly tied to the library"

We will soon see a competition on who will adapt the first to dart, because dart is still making announcements for new js libraries that become compatible with it, it will fast become a sort of marketplace for new "club members". Especially because js libraries were needed for a long time, and many hundreds of js libraries emerged during that long long period, today if you search for a ready js gallery, you will find a plethora of solutions, some more buggy than others, if you have any kind of need, there are chances you will find your solution already working and tested on the web.

Dart will be the next way for these js libraries that are already in competition to become "visible" on the web, that's why the article says it's becoming an ambassador. I think it is not a good idea to create a "Dart play" website since Dart will surely be there at the right time, but on this specific point I could be wrong, and even this statement could influence the course of things: if some referee website will be born before, maybe they could also be then "bought" by dart with their already existing public...

Do you think I forgot an aspect of the js development world seen by dart aware developers? your comments will be welcome...