Home > Delphi, JavaScript, nodeJS, Object Pascal, Smart Mobile Studio > Understanding Smart Pascal

Understanding Smart Pascal

January 15, 2017 Leave a comment Go to comments

One of the problems you get when working pro-bono on a project, is a constant lack of time. You have a fixed amount of hours you can spare, and every day you have to make decisions about where to invest those hours. The result is that Smart Mobile Studio has a wealth of technical resources and depth, but lacks the documentation you expect such a product to have. This has been and continues to be a problem.

Documentation really is a chicken and egg thing. It doesn’t start out that way, but once the product is launched, you get trapped in this boolean dynamics: “Few people buy it because it lacks documentation; You can’t afford to write documentation because few people buy it“. Considering the size of our codebase I don’t blame people for being a bit overwhelmed.

Despite our shortcomings Smart Mobile Studio is growing. It has a slow but steady growth as opposed to explosive growth. But all products needs periods of explosive growth to build up resources so that future evolution of the product can be financed. So this lack of solid documentation acts almost like a filter. Only those that are used to coding in Delphi or Lazarus at a certain level, writing their own classes and components, will feel comfortable using it.

It has become a kind of elite toolkit, used only by the most advanced coders.

The benefit of true OOP for JSVM is unquestionable

The benefit of true OOP for JSVM is unquestionable

Trying to explain

The other day I talked to a man who simply could not wrap his head around Smart Pascal at all. Compile for JavaScript? But.. how.. How do you get classes? He looked at me with a face of disbelief. I told him that we emit a VMT (virtual method table) in JavaScript itself. That way, you get real classes, real interfaces and real inheritance. But it was like talking to a wall.

In his defence, he understood conceptually what a VMT was, no doubt from having read about it in context with Delphi; but how it really works and that the principle is fundamental to object orientation at large, was alien to him.

var TObject={
  $ClassName: "TObject",
  $Parent: null,
  ClassName: function (s) { return s.$ClassName },
  ClassType: function (s) { return s },
  ClassParent: function (s) { return s.$Parent },
  $Init: function () {},
  Create: function (s) { return s },
  Destroy: function (s) { for (var prop in s) if (s.hasOwnProperty(prop)) delete s.prop },
  Destroy$: function(s) { return s.ClassType.Destroy(s) },
  Free: function (s) { if (s!==null) s.ClassType.Destroy(s) }
}

Above: In object orientation the methods are only compiled once while the instance is cloned. This is why methods in OOP languages are compiled with a secret first parameter that is the instance. Inheritance never duplicates the code inherited from ancestors.

In retrospect I have concluded that it had more to do with “saving face” than this guy not understanding. He had just spent months writing a project in JavaScript that he could complete in less than a day using Smart Pascal – so naturally, he would look the fool to admit that he just wasted a ton of company money. The easiest way to dismiss any ignorance on his part, was to push our tech into obscurity.

But what really baked my noodle was his lack of vision. He had failed completely in understanding what cloud is, where the market is going and what that will mean to both his skill-set, his job prospects and the future of software development.

It’s not his fault. If anything it’s my fault for not writing about it earlier. In my own defense I took it for granted that everyone understood this and knew what was coming. But that is unfair because the ability to get a good overview of the situation depends greatly on where you are.

JavaScript, the most important language in the world

It may be hard for many people to admit this, but it is none the less true. JavaScript has become the single most important language on the planet. 50% of all software written right now, regardless if it’s for the server or the browser, is written in JavaScript.

I knew this would happen as early as 2008, all the signs pointed to it. In 2010 Delphi was in a really bad place and I had a choice: drop Delphi and throw 20 years of hard-earned skills out the window and seek refuge in C++ or C#; or adapt object pascal to the new paradigm and try to save as much of our collective knowledge and skills as I could.

Even before I started on Smart I knew that something like node.js would appear. It was inevitable. Not because I am so clever, but because emerging new technology follows a pattern. Once it reaches critical mass – universal adoption and adaptation will happen. It follows logical steps of evolution that apply to all things, regardless of what the product or solution may be.

What is going to happen, regardless of what you feel

Ask yourself, what are the implication of program code being virtual? What are the logical steps when your code is 100% abstracted from hardware and the underlying, native operative system? What are the implications when script code enjoy the speed of native code (the JavaScript virtual machine uses LLVM to the point that JavaScript now runs en-par with native code), yet can be clustered, replicated, moved and even paused?

Let me say it like this: The next generation rapid application development wont deliver executable files or single platform installers. You will deliver entire eco-systems. Products that can be scaled, moved between hosts, replicated -that runs and exist in the cloud purely as virtual instances.

Norwegian developed FriendOS is just one of the purely cloud based operative systems in development

Norwegian developed FriendOS is just one of the cloud based operative systems in development right now. It will have a massive impact on the world

Where Delphi developers today drag and drop components on a form, future developers will drag and drop entire service stacks. You wont drop just a single picture on a form, but connectors to international media resource managers; services that guarantee accessibility across continents. 24 hours a day, seven days a week.

You think chrome-book is where it ends? It’s just the beginning.

Right now there are 3 cloud-based operating systems in development. All of them with support for the new, distributed software model. They allow you to write both the back-end and front-end of your program, which in the new model is regarded as a single entity or eco-system. Things like storage have been distributed for well over a decade now, and you can pipe data between Dropbox, Google drive or any host that implements the REST storage interface.

Some of the most powerful companies in the world are involved in this. Now take a wild guess what language these systems want you to use.

I’m sorry, but the way we make programs today is about to go extinct.

Understanding the new software model

As a Delphi or Lazarus developer you are used to the notion of server-side applications and client side applications. The distinction between this has always clear, but that is about to change. It’s still going to be around, at least for the next decade or so, but only for legacy purposes.

To backtrack just a second: Smart introduced support for node.js applications earlier, but it was on a very low-level. In the next update we introduce a large number high-level classes that is going to change the way you look at node completely.

Two new project types will be introduced in the future, giving you a very important distinction. Namely:

  • Cloud service
  • System service

To understand these concepts, you first have to understand the software model that next generation cloud operating systems work with. Superficially it may look almost identical to the good old two-tier model, but in the new paradigm it is treated as a single, portable, scalable, cluster capable entity.

In the new paradigm this is now a single entity

In the new paradigm this is now a single entity

The thing about clustering and scaling is what tends to confuse traditional developers. Because scaling in a native language is hard work. First you have to write your program in such a way that it can be scaled (e.g work as a member in a group, or cluster). Secondly you have to write a gate-keeper or head that delegates connections between the members of the cluster. If you don’t do this from the very beginning it will be a costly affair to retrofit a project with the required mechanisms.

Node.js is just awesome because it can cluster your code without you having to program for that. How? Because JavaScript is virtual. So you can fire up 50, 100 or 10.000 instances of the same process and the only thing you need to worry about is the gate-keeper process. You just park the cluster in another IP range that is only accessible by the gatekeeper, and that’s pretty much it.

When a software eco-system is installed on a cloud host, the entire architecture described by the package is created. So the backend part of your code is moved to an instance dedicated for that, the front end is installed where it belongs, same with database and so on. Forget about visual controls and TComponent, because on this level your building blocks are whole services; and the code you write scales from low-level socket coding to piping terabytes of data between processes.

Running your Smart Pascal server as a system-level daemon is very easy once you know what to look for :)

PM2 is a node.js process manager that gives you clustering and pooled application behavior for free out of the box. You don’t even have to tailor your code for it

Services that physically move

While global accessibility is fine and good, speed is a factor. It goes without saying that having to fetch data from Asia when you are in the US is going to be less than optimal. But this is where cloud is getting smarter.

Your services will actually physically move to a host closer to where you are. So let’s say you take a business trip from the US to Hong-Kong. The service will notice this, find a host closer to where you are, and replicate itself to that server.

This is not science-fiction, it’s already implemented in Azure and Google’s APIs take height for this behavior. It’s pretty cool if you ask me.

Is node.js really that powerful?

Let me present you with a few examples. Its important to understand that these examples doesnt mean everyone have to operate on this scale. But we feel it’s important to show people just what you can achieve and what node is capable of.

netflix-amazon-cloudNetflix is an online video streaming service that has become a household name in a very short time. Cloud can often be a vague term, but no other service demonstrates the potential of cloud technology as much as Netflix. In 2015 Netflix had more than 69 million paying customers in roughly 60 countries. It streams at average 100 million media hours a day.

Netflix moved from a traditional, native software model to a 100% clustered Node.js powered model in 2014. The ability for Netflix to run nearly universally on all devices, from embedded computers to Smart TV’s is largely due to their JavaScript codebase.

PayPal is a long-standing online banking and payment service that was first established in 1998. In Q4 of 2016 PayPal had 192 million registered customers world-wide. The service’s annual mobile payment volume was 66 billion US dollars in 2016. More than triple that of the previous year. Paypal moved from a traditional, native server model to Node.js back in 2015, when their entire transaction service layer was re-written from scratch.

Uber is a world-wide taxi company that is purely cloud and web-based. Unlike traditional taxi companies Uber owns no cars and doesn’t employ drivers; Instead its a service that anyone can partake in – either as a customer or a driver. In 2016 Uber operates in 551 cities across 60 countries. It delivers more than one million rides daily and have an estimated 10 million customers.

Uber’s server technology is based purely on Node.js and exists purely as a cloud based service. Uber has several client applications for various mobile devices, the majority of these are HTML5 applications that use Cordova Phonegap (same as Smart applications).

Understanding Smart

While the RTL and full scope of the technology has been a bit of a “black box” for many people, hopefully the idea and concepts around it has matured enough for people to open up for it. We were a bit early with it, and without the context that is showing up now I do understand that it can be hard to get the full scope of it (not to mention the potential).

With the cloud and some of its potential (and no, it’s not going away), a sense of urgency should start to set in. Native programming is not going away, but it will be marginalized to the point where it goes back to its origins: as a dicipline and part of engineering.

Public software and services will move to the cloud and as such, developers will be forced to use tools and languages better suited for that line of work.

We firmly believe that object pascal is one of the best languages ever created. Smart pascal has been adapted especially for this task, and the time-saving aspects and “edge” you get by writing object pascal over vanilla JavaScript is unquestionable. Inheritance alone is helpful, but the full onslaught of high-level features Smart brings takes it to the next level.

The benefits of writing object oriented, class based code is readability, order and maintainability. The benefits of a large RTL is productivity. The most important aspect of all in the world of software development.

The benefits of writing object oriented, class based code is readability, order and maintainability. The benefits of a large RTL is productivity. The most important aspect of all in the world of software development.

Hopefully the importance of our work will be easier to understand and more aparent now that cloud is becoming more visible and people are picking up the full implications of this.

The next and obvious step is moving Smart itself to the cloud, which we are planning for now. It will mean you can code and produce applications regardless of where you are. You can be in Spain, France or Oklahoma USA – all you will need is a browser, your object pascal skills and you’re good to go.

Things like “one click” hosting, instance budgets for auto scaling; the value for both developers and investors should be fairly obvious at this point.

Starting monday we will actively look for investors.

Sincerly

Jon Lennart Aasenden

Advertisements
  1. Delphi Developer
    January 15, 2017 at 10:28 pm

    Although I agree with you in many aspects, I find somethings quite…. “interesting”. You claim that 50% of all development in the world today is primarily using JavaScript (not using it just as part of HTML/CSS package). If this is so, why jobs don’t reflect that? If you search for JavaScript developer, you will find hundreds of available jobs. But a closer look will show that most of them are Java or C# or – name other web language here – PLUS JavaScript, meaning that JavaScript is required, but it is not the core of development. Many jobs just say “JavaScript required”, but actually they are looking for someone able to play with JQuery…

    Another aspect: The problem with tooling or development languages is not related to “are you able to do this or that” (like being able to be clustered or moved in the cloud). Delphi has been able to do, since 199x, lots of things that Java and C# started to do well only in mid 2000s. Nevertheless, Delphi was swallowed by those languages, and, specially Java, is the dominant language today. So, even if one language is more capable – technically – than another, it doesn’t mean that it will be adopted in a larger scale. Lots of things come before “technical capability” and I can list a few:
    – Is that language standardized?
    – Is it open source?
    – Which big companies support it?
    – Which big companies actually use it?
    – How is the framework ecosystem? Are there plenty of frameworks available? Are they maintained/backed up by well known companies?
    – etc, etc, etc.

    SMS emits JavaScript but it is a pascal based language/dev tool. You can’t claim that SMS is a JavaScript tool just like I can’t claim that Delphi is an assembly tool.
    How do you expect to convince any developer out there that JavaScript is better when written in Pascal? Please notice that I personally can agree with you, but even Microsoft and Anders Hejlsberg haven’t being able to convince the vast majority of JS devs out there that TypeScript is superior than plain JS written in Notepad++…

    Finally, don’t get me wrong, I find your enthusiasm admirable, but you are basically saying: “Look, there won’t be a place for your “small” application anymore. The whole thing is going to the cloud, everything will be gigantic and you should be prepared to serve 1 bazzillion simultaneous users, because Netflix and Uber and bla-bla-bla are doing it. And SMS is the way to do it”.

    Don’t you see a contradiction? I mean… your product might be terrific from any point of view, but this kind of developer, that one who is worried right now whether his application can scale up to 1 billion simultaneous users is not reading this blob post. Actually, this guy probably has some IBM hotshot in the speed dial and will have dinner with Larry Ellison this week….

    • January 15, 2017 at 11:32 pm

      You are absolutely right that Java and C# are doing a lot of this (with Java losing favour). But those represent separate markets. Even the budgets for hosting large scale dot net applications vs. nodejs is different. You cant compare languages like you do here, because you would undershoot your budget. Bytecode is more expensive and requires more infrastructure to run. The moment you deal with thousands or hundreds of thousands of users a day, those tiny margins suddenly become valuable factors.

      Now I have focused on JS, which today is both with and without HTML (not to mention embeded devices). But naturally, most web applications use html as the interface in combination with js. It is largely agreed upoun that HTML5 represents the UI engine most future applications will use. No other system gives you the same level of freedom to change, update and display information.

      The reason i mentioned Netflix etc. was not because “you must do this to!”, but rather that you can. It would make little sense presenting a poorly run business or a service incapable of scaling. So these examples were added to give you some sense of what can be achieved. Call it potential.

      Smart is productive (or more productive perhaps) because it allows you to approach the JSVM on your own terms. If you already know Delphi or Lazarus, then naturally you will feel more at home in SMS than jumping face first into visual studio or eclipse. There is also a financial aspect in this. Having to re-educate your staff in a new language costs a lot of money. At least here your hard earned skills are preserved.

      And yes, we believe that object pascal is the best way to deal with this. The team behind Smart Mobile Studio are professional Delphi developers with decades of work behind us. And just like we firmly believe that Delphi is the most productive development system for desktop software, we likewise believe that object pascal is infinitely better suited than other languages when it comes to web and cloud. And we also set out to make that a fact by building sms from scratch in Delphi. Smart is a better alternative than typescript (and btw. you can also import typescript modules so its not like you are losing out on anything). But as Delphi developers we will always be biased and prefer object pascal over other languages.

      Although personally I use several languages. C++, Delphi, JavaScript and C# all being a part of my toolbox.

      So im not trying to convince anyone really. Most of the changes that I have talked about since 2010 has already happened. And it will continue to happen regardless of what you and me feel about it. It all boils down to how you prefer to write code, what is productive for you – and even more important: what will the best way for you to port your legacy applications. Moving 20 years of legacy object pascal code to C# is no walk in the park. Moving it to a platform that at the very least is source-code compatible will save you both time and money.

      >>”but even Microsoft and Anders Hejlsberg haven’t being able to convince the vast majority of JS devs out there that TypeScript is superior than plain JS”

      Smart is not written for them. It is first and foremost written for object pascal developers. Although quite a few schools have adopted SMS since object pascal is much easier to learn than plain JS or Java. Kids growing up today dont really have a relationship to the desktop. Their world is the browser, so when they learn to code it is more natural for them to see the results directly in the browser. Convincing someone of the benefits of SMS vs. JS, is no different than convincing people that Delphi is a great development suite. The benefit we have when it comes to JS is that pascal is so much easier to learn, use and maintain. And once you get the basics, moving to Delphi for native work is an obvious evolution. There is a symbiotic relationship between these two.

      We have a product and toolkit that gives you an edge over vanilla javascript, that allows you to approach and work with the latest tech using a familiar language. And that is what we set out to build and promote. If you feel java or C# is better suited for your line of work, then by all means go for that. Very few programmers use just one language these days, and SMS has already become a natural part of many developers toolbox.

      We are firmly convinced that once we take the next step, people will notice just how much we have done to pascal-ify JSVM. JS doesnt have streams or allocmem, but our RTL does. JS doesnt have interfaces, classes, partial classes and inheritance. But we do. And that matters when you are hired to deliver a high end system running on node in a cloud environment.

      • Delphi Developer
        January 16, 2017 at 12:17 am

        – “you have gravely misunderstood me”
        Sorry, but you spent most of this post talking about scalability, so I believe that you think this is a strong point of your product? However, your target audience is maybe the same small shops (or one-man-shops) using Delphi, Oxygene and FPC out there? Pascal is pascal. A C# developer won’t ever learn Pascal to write javaScript code using Pascal, will he?

        So, let’s change the question. I work for a company with 30+ developers. They use primarily Java, .NET, and also Delphi. they have never heard about SMS (even the Delphi developers, I’ve already asked quite a few). Let’s say I love your product and I would like the company to adopt it.
        Give me ONE single reason that they should adopt SMS instead of any other development tool in the market.
        My point here is simple: most companies abandoning Delphi development inevitably will give you some reasons for it, like:
        – Language is closed source, not standardized. Compiler and IDE are privately owned.
        – Hard to find fluent, experienced developers
        – Small ecosystem (questionable in case of Delphi, but I bet you will hear that)
        How would you respond to that?

        (Sorry if there was some double post. Your blog gives no visual feed back when I click on “post Comment” button).

        • January 16, 2017 at 12:51 am

          I spent most of the post talking about how node.js scales, as opposed to how a traditional two-tier model scales for native languages.

          As for a single reason? Productivity. Plain and simple productivity.

          The power of Smart Mobile Studio is not the ability to compile to JavaScript. That is ofcourse a required feature, but the real value is in the many units and classes that makes up the run-time library and control framework. A lot of people get this wrong, they think it’s the compiler alone that makes something valuable. But its not. The RTL code that gives you the ability to write custom-controls, deal with events, implement support for new browsers, handle streams, memory and disk IO, create and use databases, connect to websocket, REST, Remobjects and Datasnap servers, draw graphics and execute CSS3 effects from the comfort of daisy-chained classes — that is where you find the value. Four years of continuous problem solving and adaptation. And now you can even write the server’s and run on embedded hardware.

          Like i mentioned earliner, we use our own product and as such we have spent most of our time creating a large, rich and diverse library of pre-made solutions.

          Take something simple, like zlib compression or RC4 encryption. Have you seen some of the JavaScript stream implementations out there? Then take a close look at our classes and tell me what will serve you the best. What about other low-level tasks? Like memory allocation, blue pointers and threads? What about a concrete parent/child custom control framework that is largely compatible with Delphi and Lazarus?

          You wont find that in typescript, and you wont find that in jQuery either. People tend to roll their own “stream like” code, or fork one of the many libraries out there. A library that may or may not work when you throw real data at it. We have implemented a standard object pascal stream that is both source-code and binary compatible with Delphi and Lazarus (since you bring up standards). So what codebase would you rather maintain: The 20k lines of clear, easy to read object pascal code? or the 2 megabyte spaghetti Javascript monstrosity?

          So if you think that SMS is just a typescript clone (we released SMS a year before Typescript, so Anders have copied us, not the other way around), then please spend some time looking at our RTL units. Heck, I will even send you a copy of the upcoming update if you feel the units that ship with the current version dont meet your expectations.

          The core benefit is actually just that: object orientation. The ability to build up complex behavior incrementally in clear, readable and easy to maintain classes. The CSS3 effect classes alone should give you some idea how much time SMS saves you. Same goes for working with websocket servers, REST, Remobjects sdk, Datasnap and other third party libraries.

          And should you miss anything then just use our import-tool to convert Typescript packages, or just drop the JS file in the libraries folder and write a few declarations for it. So you are not exactly boxed in here. There are some 35.000 typescript packages to choose from, with another 350.000 packages for node.js

          So the question I will put to you is: What would you rather do? Would you rather throw six months of development cost at a project, or deliver the exact same high quality work in 1 month? And what about maintaining it? Would you rather work with 20k of readable, object orientated code – or 2 megabytes of snippets stuffed together by gulp, looking more like an assault than anything developed by human beings?

          As for learning object pascal: you also get to learn Delphi for free. So once object pascal is in your fingers, you can advance to Delphi and explore all the benefits Delphi brings to native desktop development. No extra cost.

          • Delphi Developer
            January 16, 2017 at 2:33 am

            You are preaching to the converted here. I do prefer Pascal over JavaScript, although I really enjoy JavaScript in many aspects. But this is not about me. I’m playing the devil’s advocate. I’m asking **YOU** the exact same questions that I will hear from other people, the first time I open my mouth to recommend any pascal based development tool/language, doesn’t matter if it is Delphi, SMS, Oxygene or Lazarus. Lazarus is at least open source… but why in hell the company I work for should buy Oxygene instead of using VS/C# – sometimes costing exactly ZERO dollars – like 99% of all .NET developers in the world??
            There is another point that I think you missed completely: You are saying, in your answer, that your target audience is the existing Delphi (or pascal) developer user base which, lets face it, is not big and is not growing. So, even if your tool is adopted by 50% of Delphi developers, it won’t be something that we can call “popular”, agree? So, again, how can I recommend your tool for a company if it is currently less popular than Delphi (which they already consider to be below acceptable) and having the same “defects”, i.e., closed source, not backed up by any relevant company, not standardized, etc. etc. etc?

            • January 16, 2017 at 3:08 am

              I get that, but I feel we are going in circles here. You asked me to sum it up in a single word, and I did. And that will also be my answere for this version of your question. Namely productivity. And that is also what an investor would be told and that I would gladly demonstrate. It is also what developers who use SMS as their primary devkit tell us 🙂

              I added this to the previous reply, you may have missed that part since I was a bit late:

              “The power of Smart Mobile Studio is not the ability to compile to JavaScript. That is ofcourse a required feature, but the real value is in the many units and classes that makes up the run-time library and control framework. A lot of people get this wrong, they think it’s the compiler alone that makes something valuable. But its not. The RTL code that gives you the ability to write custom-controls, deal with events, implement support for new browsers, handle streams, memory and disk IO, create and use databases, connect to websocket, REST, Remobjects and Datasnap servers, draw graphics and execute CSS3 effects from the comfort of daisy-chained classes — that is where you find the value. Four years of continuous problem solving and adaptation. And now you can even write the server’s and run on embedded hardware.”

              And there you have it:

              – Diverse and rich RTL and class library
              – Easy to maintain and learn
              – All the benefits of object orientation
              – Compiles for 9 operating systems
              – Full support for phonegap
              – Works on all browsers
              – Large collection of low level classes

              And soon: Fully evolved node.js namespace

              As for exposure, it has been estimated that there are roughly 2 million developers in the world using Delphi. Personally I think its lower, perhaps 1.3 million if we count Lazarus. If we imagine that 50% (like you point out) adopts Smart for HTML5 and cloud development, that represents a significant return on investment. Smart has so far been developed by 3-4 people working pro-bono. You can then imagine what a team of 4 or 8 people working 5 days a week on the product will be capable of producing (and what that will mean for the end user).

              As for open source and easy access. The command-line compiler is free and have been so since the beginning. So setting up build services if you own a valid license (for the RTL) has never been a problem. This also gives some degree of safety for the future. Even if a nuclear bomb went off and everyone in the group was killed, companies would still be able to use the compiler for years to come. JavaScript is a standard and as such it’s update cycles is bound to the browsers, a reality that is very fragile. But that also means the code produced today will run just fine for many years.

              Compare that to the release cycle of JS frameworks, which change every six months, forcing companies to run around like headless chickens to catch up with the “next cool thing” 🙂 Our application model and the way you build programs is tried and tested. It’s identical to Lazarus and Delphi (give or take a few adaptations). So you can take advantage of that cool, next thing but within a framework that has produced solid software for decades.

              As for language, you may be interested to learn that I created a Visual Basic to Smart Pascal parser/emitter last year, and that both typescript and C# parsers are already in “the labs”. It has been some debate around this in the consortium, but we will no doubt do so when finances permit. The reason we are seeking investors is not due to a lack of skill, but time and exposure as you have pointed out. Bringing the IDE up to speed (for example) will happen very quickly, as will documentation — but the project has now reached a size where a traditional business model must be used.

              As you might have noticed, writing parsers and compilers is not exactly alien to me: https://jonlennartaasenden.wordpress.com/2017/01/13/ldef-intermediate-language/

        • aplikmuj
          January 16, 2017 at 11:40 am

          I think Jon’s point was – let infrastructure do the job and all of sudden the hot chick around the corner looks like a rotten diva the day after.

          • January 16, 2017 at 4:35 pm

            Exactly. With new and cool JS libraries popping up every 6 months, sooner or later a company or person have to make a choice. And intrinsic to that choice will be stability, longevity and predictable behavior of code.
            Since SMS represents the same model that has fueled both Delphi and Lazarus, you can put a little faith in that model. It has produced hundreds of thousands of applications. It is easy to maintain and expand – and can also be enriched by third party libraries and “snippets” without breaking or affecting the fundamental behavior.

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

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

%d bloggers like this: