Showing posts with label Chrome Browser. Show all posts
Showing posts with label Chrome Browser. Show all posts

Wednesday, June 24, 2020

SVG JS/ES Asteroids Video Game for Modern Chrome Browser

Browser-Based Asteroids-clone Video Game

Using 2020 JavaScript features available in Chrome browser

Earlier this year, during the beginning of the major social-distancing requirements (due to COVID), I finally decided to spend a few weeks of my free time writing a video-game clone that would make use of some of the newest features of JS / ECMAScript.   I ended up writing a clone of the famous 1979 Asteroids video game, but with all sorts of extra features and improvements (as I deem them).

JavaScript Features Used

  • requestAnimationFrame / cancelAnimationFrame  — which keeps the game frame-rate flowing nicely even as many Space Rocks and UFOs are threatening your existence.
  • Asynchronous code — a nice bit of async function and await / Promise usage!
  • JS Classes  — including plenty of encapsulation, inheritance, static variables and such
  • Game-pad support  — in addition to keyboard controls, I used the standard JS gamePad object to implement Xbox (or similar controller) support
  • Sound — without any extra files, but rather using audioCtx oscillator features

CSS / SVG Features

  • Animation — CSS animation of fills, strokes, etc.
  • SVG Symbol and Def — for maximum re-use via SVG use.
In the end, I was able to achieve a LOT of interesting visual-effects without the need to resort to a lot of custom animation code. 

UFO-Infested Space Rocks Video Game

I placed my UFO-Infested Space Rocks Video Game online at Github for anyone that wants to play with it.  The game play evolves as you go, presenting "smarter" aliens and an ever more frenetic pace.  The game works wonderfully in modern Chrome browser on the PC.  There are issues with it in Firefox.  I have not even tried to use it on a phone or whatever (no idea how keyboard controls or game controller logic would make any sense there).

Further Software and Technology Reading

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, NVIDIA CUDA, VMware, Typescript, JavaScript / ECMAScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Tuesday, July 15, 2014

How to Include an HTML File in another HTML File Without a Server or Code

Include HTML Files In HTML by Reference Without Any Server Technology

I have meant to write a blog about this for quite some time, and the newest Chrome 36 Beta release notes reminded me to do so now that yet another way of including HTML files within HTML files (without any particular server requirement and without JavaScript) exists —  i.e., you do not need ASPX and you do not need PHP or other server-side technology, and you do not need JavaScript.

The first method I will discuss is one I have used since as far back as Chrome 24, Firefox 17, and even Internet Explorer 9 (IE9) — "seamless IFrames". The second technique is the one that Chrome 36 Beta has implemented — "HTML Imports". Until all browser vendors support the new HTML imports, my "old" way will still work fine.

"How to" Include HTML Files — using Seamless IFrames

This technique is probably best described by way of example code. This way to implement "include" files in HTML5 without ANY "server" works to include any file referenced by "file:\\..." addresses or relative URL addresses.

In the “container” document (i.e., the “outer” document into which you would like to import / “include” content from another HTML file):

<div class="content">
   <iframe id="top-nav" seamless="seamless" src="include.top.nav.html" ></iframe>
</div>

Then, inside that external / referenced HTML file (in this example, “include.top.nav.html”), we simply include the HTML that we want to appear inside the iframe — in this case a simple reusable section of HTML with my navigation HTML code in it:
<div id="topnav">
   <a href="some-page-to-navigate-to.html" target="_top">link to home page</a>
</div>

Note the use of “_top” to indicate that our navigation is going to affect the outermost document; if we omit this, the contents of the iframe will be what changes during navigation instead of the contents of the outer container document.

Let us also assume we perhaps we want to style this iframe, so in our referenced CSS file we do so  — in this case I simply want to make sure it sizes to 100% of the container div's width and height:

     /*Set the seamless iframe properties; size as needed to fit embedded content*/
     #top-nav {
          width: 100%;
          height: 100px;
     }


A more complete view of the outer HTML document that includes the reusable HTML by way of the seamless iframe looks something like this:

<!DOCTYPE html>
<html>
<head>
    <title>DEFAULT DOCUMENT TITLE</title>
    <link rel="stylesheet" href="my_styles.css">
    <meta charset=utf-8>
</head>
<body>
    <div class="content">
        <iframe id="top-nav" seamless="seamless" src="include.top.nav.html" ></iframe>
        <h1 class="document-name">DOCUMENT NAME HERE</h1>
        <p>Paragraph...</p>
    </div>
</body>
</html>


Hopefully this was somewhat easy to follow.  Try it out.  This technique came in super-handy for a local HTML-Based WIKI I created that did not require any web-server to run.  I can access the WIKI pages from Chrome, Firefox, and IE and the included HTML file(s) work just fine with no web server and no dynamic language or dynamic web-page technology.


"How to" Include HTML Files — using HTML Imports (rel="import" directive)

This is an alternative serverless "include HTML file" method that has just recently come available in browsers like Chrome 36 (note: it has existed since Chrome 31, but you had to enable the experimental feature; now it is "on" by default).   If you took a look at the Chromium Blog release notes link (above), you will see a quick overview of this new technique, and I have pasted their description and example here for quick reference:

HTML Imports
HTML Imports, part of the Web Components standards umbrella, offer a way to include HTML documents in other HTML documents using <link rel="import">:
<head>
  <link rel="import" href="/path/to/imports/stuff.html">
</head>
An HTML Import can contain CSS, JavaScript, HTML, or anything else an .html file can include. This means they provide a convention for bundling related HTML/CSS/JS (even other HTML Imports) into a single package, making them a fantastic tool for delivering Web Components to users.

The first technique I showed (seamless iframes) can accomplish the same thing to an extent, but this new rel="import" technique is certainly the preferred way to go in the long term.  I look forward to this being widely adopted (hopefully sooner rather than later), but it seems Chrome is the only game in town today.  There are much "bigger picture" reasons why the rel="import" implementation is important as it is quite handy for web components packaging (something I plan to use in my SVG Dart Widgets, eventually).  Search the web for more examples and have fun with either, or both, of these ways to import HTML file contents into another HTML file without the need for server-side technologies.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Saturday, November 16, 2013

Google Dart Programming Language Milestone: Version 1.0 Released

Google Dart Reaches Stable 1.0 Release


Exciting times for web-developers frustrated by JavaScript!

I have been following the Google Dart language and associated software development APIs / Libraries since very early in the Dart life-cycle.  My early Dart-related blog postings began over a year and a half ago, and as impressed as I was with Dart and its objectives back then, I am even more impressed by Dart and the software development ecosystem that has emerged since.

The Dart language itself is but a small part of the story here.  In addition to the class-based object-oriented modern programming language, one of the greatest things about Dart is the included libraries for things like Collections, Asynchronous operations, and much more — just check out all the available standard Dart API libraries for common web software development tasks.  In addition to those, there are a growing number of community-sourced projects and libraries available on Github or the Dart "Pub" Package repository.

I have published my own open-source Dart / SVG Widgets on Github [UPDATE: I removed these after Google eventually created something similar, and eventually far more advanced, called Flutter!], and just finished updating them to be compatible with the 1.0.0 release of Dart.  These are only "experimental" or "alpha" stage UI Widgets, and require more work to make use of some of the newer features of Dart that were not around when I first wrote this code (e.g., Streams and such).  But, writing that open-source proof-of-concept SVG-UI-Framework in Dart definitely provided good experience and helped maintain my interest in Dart while the product made its march toward "stable 1.0" release.

The down-side of Dart...

After using Dart for web development work, I simply cannot stand to code JavaScript!  That is the biggest "down-side" or Dart for me... it has further eroded my ability to tolerate the (normal) hideous and unmaintainable JavaScript that usually accompanies any substantial web applications these days.  I am spoiled now!  And, any time I look at the source-code behind large JS libraries, I can barely stand it. Dart is just so fantastically better designed for building modern robust web functionality than JS.  Give it a try, you'll like it.

[NOTE: Dart can *output* JS code that runs on any modern browser, and the code runs fast!  So, why subject yourself to the typical maintenance nightmare of working directly in JS when you do not have to?]

There is also always Microsoft TypeScript if you prefer their approach to improving JS.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Friday, June 14, 2013

Google Dart Language Status / Popularity 2013

Google Dart Language Progress 2013


Time Flies: Dart, one year later...

In May of 2012, I wrote a blog about how Google's Dart Language ranking / usage was on the rise. I was watching the Github language-popularity rankings for Dart quickly move from 70th position to 55th ranking between May 2012 and October 2012. Now I just took another look today, and one year later Dart is showing up in 56th position on Github. So, Dart's Github rank has essentially gone nowhere since October of 2012. So, what does that mean?

Well, I believe some of the early excitement over Dart wore off as developers (including myself) have been waiting for the Dart language and APIs to stabilize. I switched from heavy-development mode to "just keep code working with latest Dart SDK / APIs" mode for much of the past year (not to mention the fact the Dart team destroyed my ability to have standalone SVG-docs using Dart for interactivity - which previously worked).  In addition, I think a lot of people are waiting for projects like the Dart Web UI (Web Components) stuff to mature so it can be put to use in projects without heavy re-working later.

It is worth noting that the free Dart Editor has come a long way since last year, if you use it.  I personally use JetBrains WebStorm / PHPStorm product (which has a nice Dart plugin), but I can certainly appreciate the effort Google is putting into creating a free editor.  Though, I cannot help thinking that some of the time spent working on the editor would be better spent getting the language features, APIs, and libraries completed and stabilized.

In addition, Dart's code execution-speed / performance is fantastic now!  This is certainly worth noting, and keeps my interest in Dart.  When Dart is running twice as fast as JS (in V8 engine, which is quite speedy JS to begin with), that is impressive, which is partly why...

Dart Language is Getting Noticed Yet

I just took a look at the TIOBE Programming Community Index (June 2013) site (FYI, the TIOBE Programming Community index is an indicator of the popularity of programming languages), were I encountered this (quoted material) in their monthly summary, which notes Dart's progress / presence:
...there are also some threats for JavaScript. The JavaScript language is generally regarded as a programming language in which it is easy to make mistakes. It is interpreted, so most errors show up only at run-time. That's why Google designed Dart (currently at position 80) as JavaScript's successor. But also other programming languages were designed to generate JavaScript code instead of writing it manually. Examples of this are CoffeeScript (position 139) and TypeScript (position 207).
Yes, Dart is more than holding its own compared to Microsoft's own Dart-like language, TypeScript.  But, it is nowhere near the well-entrenched JavaScript (which was in 10th place this month).  Google has done a decent job of talking Dart up at developer conferences and so froth, but much more will have to change before Dart truly threatens Javascript...

What is needed for Dart Language adoption to increase?

Now, that sure is an open question subject to all sorts of debate.  As I mentioned, I want/need the language features and APIs and libraries to stabilize before I commit much more heavy development time into Dart projects.  Furthermore, Google needs to really embrace Dart (internally) in such a way the shows us developers that we are not investing in something that is going to just fade away.  And, I mean more than just *talk*.

I find it frustrating that projects like the (native, not js-interop) Dart-based Google Visualization API / Google Charts projects have just stalled out and appear, essentially, abandoned (if anyone can even find these anymore).  What's up with that?  For a while, it looked like the Dart team was going to produce native Dart-language layer for products like Google Visualization, which I'd love to see.  I recently needed to use Google-Viz / Charts with some Google Table data, and I looked everywhere for native Dart stuff.  In the end, I just gave up and used JavaScript for the project, and hated every minute of it (I find Dart coding productivity to be much higher than JS, as I really enjoy class-based OOP as natively implemented in Dart).

There there is always the question about: when will Google's cloud (Google App Engine) support native Dart-based hosted web applications?  Seems like a very popular topic/question that remains as yet open. Or, how soon will the Dart VM be included in Chromium / Blink browser?

Until more "core" and "mainstream" libraries exist natively in Dart (starting with Google's own various public libraries and APIs), I just do not see how Dart's adoption will surge.  Sure, it will slowly grow, but it would grow a LOT faster if there were some substantial popular libraries and APIs out there that were written in native Dart.  Dart's execution speed is fantastic, but that alone is not quite enough for me to commit fully to Dart.  That's my opinion for now at least.  I remain a Dart developer, but a software developer that is also waiting for signs that I will not be investing my time into something that becomes the next Delphi (i.e., technically superior, fast, but low market adoption niche language/product).


Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Wednesday, October 17, 2012

Google Dart Language Milestone Reached: M1

Dart Language :
Mature Enough to Invest In


Dart Language / SDK "M1" Version Released

If you have read any of my prior blog entries about Google's Dart language, you already know that I am a fan of this fantastic alternative to coding JavaScript (JS) for web-based applications. Dart can be compiled into JS code, and the gory details of writing large-scale JS-based applications are hidden behind the Dart-to-JavaScript compiler (Dart2JS) which enables you to focus on writing your applications in Dart's modern, clean, Object-Oriented, "typed" language implementation that also includes a rather decent base framework (with things like collections built in).

Check out the latest Dart Language information and get a copy of the free Dart Editor and Dart SDK and try things out for yourself.  There are quite a few emerging projects on GitHub and elsewhere now, and Dart's "pub" project package-repository has gone live too.  If you experience the same web-development productivity gains I have, you will thank yourself for checking Dart out!  I find myself incredibly more productive (feature-points implemented per hour of development time) using Dart to write applications  as compared to writing native JS code...  and, I see enormous savings multiple further as I need to add additional features and functionality to my code.  Dart is simply more maintainable, cleaner, etc.  You get the idea.  Check it out.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Tuesday, August 28, 2012

Google-Dart / SVG Widgets Released on Github as Open-Source

Dart-Squid UI SVG / Dart Components


SVG / Dart GUI Widgets Initial Release

I have written a couple blogs about the potential for Google's Dart language to improve browser-based software applications development. In that previous posting, I also mentioned that I was working on my first open-source software (OSS) Dart language library: a set of Dart / SVG UI Development components, controls, and framework.

2018: UPDATE

I removed the Github Repository where I had this code.
I have not had time to update my SVG/Dart Widgets to make use of the latest Dart features, but perhaps sometime in the future I will do so. 

Introducing: dart-squid

The moniker I arrived at was simply a pseudo-acronym that pulled first letters from Svg, Quick, User Interface, and Development / design: i.e., "SQUID", or as the new github repository is named, "dart-squid". I have now pushed an initial commit of these open-source widgets to my Github dart-squid SVG / Dart UI Components project site under the MIT license (for freeware).

These components work in the Dartium browser (Chromium with Dart VM). To use the normal Chrome browser (JavaScript version), you would have to have the Dart Editor installed, download the widget code from github, and launch as a JavaScript project (the editor uses dart2js compiler to make this possible).

These Google-Dart/SVG UI Widgets are my first solo open-source release to Github. They are not quite as far along as my original JavaScript-based ones, but it sure was a lot easier developing the same functionality in Dart vs. JS! Dart allowed me to completely refactor the hideous JS code (prototype-ridden ugliness, etc.) and write rather decent OO (Object-Oriented) code that looks quite a bit like Delphi (i.e., object-Pascal); always a plus for Delphi aficionados like me. And, the widgets are generally pretty functional for a mid-alpha-stage release.

Dart has been rather stable for me during development, and I have worked to keep up with the latest Dart language and VM changes that emerge as Dart moves toward its "M1" release (milestone 1). E.g., today I quickly fixed a few "breaking changes" that just hit the Dart VM including the movement of the Math.(various routines) into their own dart:math library (previously such routine were in core lib). I also renamed the XMLHttpReq to the new non-XML-prefixed version. Getters are all using the latest adopted syntax (i.e., those without parens). I will try to ensure the existing functionality remains able to execute as the Dart language progresses (with, hopefully no more than a few days delay).

Future Plans for these Dart / SVG UI Widgets

As time permits, I plan to continue work on implementing new functionality and additional widgets (sub-classes). I have yet to port all my original JavaScript widgets (that included fully-native-SVG scrollbars and checkboxes), but those should be coming in the future. I am also working on getting some documentation wrapped up (though comments in the code are somewhat in-depth already).

If you happen to try these widgets out and want to ask questions, feel free to post comments here and I will do my best to answer. And, just to be clear up front: I do not expect everyone will find these components to be of use... especially right now; they are as much of a "proof-of-concept" as anything and a demonstration of what is possible in Dart/SVG. I will try to make them useful to as many people as possible, but only time will tell whether they will ever be a logical part of any real software applications. They require optimization and much more testing for sure, and until certain browser bug(s)/issue(s) are resolved (that impact rendering in some instances), they will definitely not be production-quality. Stay tuned.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Wednesday, May 02, 2012

Dart Language: Rank / Popularity Increasing Daily

Dart Language Rankings Rise

Dart Language on GitHub: Climbing Quickly

As I work on getting the first "public" release of my Dart Language SVG UI-Components/Widgets set ready, I have been contemplating whether I will self-host or push the source-code to GitHub or such. And, one thing I have noticed over the past couple weeks is that nearly every day I look at the GitHub Top Languages page for Dart Language, its popularity is increasing.

As of this writing, GitHub shows: "Dart is the #70 most popular language on GitHub".
[UPDATE: as of the "M1" Dart release-date (October, 2012), Dart ranks as #55 most popular language on GitHub; not bad considering my long-time-favorite development language - Delphi - is currently #40 on that same list after many years in the market].

Although this ranking many not sound very impressive, Dart has moved upward in the ranks quickly since its initial public release.  And yes, I understand that this early rank-movement pace is partly due to the fact that the lesser-used languages are going to be easy to overtake. But, for a language that is in "alpha" stage along with "alpha" stage Editor and "developer" stage Dartium (browser), I see this early popularity increase as a good sign for Dart.

More JavaScript being ported to Dart Language

Another thing I have noticed recently is that in the daily Dart news (a la "Abridged summary of misc@dartlang.org") and on GitHub, there are ever more announcements from fellow Dart enthusiasts that are creating ports of popular JavaScript libraries, wrappers, etc in Dart. I have not had the opportunity to check each one out in detail, but there are projects that target JSON stuff, Redis.io, MySQL, and all sorts of other things.

Given my experience with many projects on GitHub, most (regardless of language) will never (statistically) survive to become mature projects, but I expect that with time, some of these Dart projects will become solid enough to use and/or build applications upon — just like some very popular JS code has emerged over time. Hopefully my own Dart/SVG components will prove to be useful enough to survive or become the foundation for something useful — though, I am not kidding myself into thinking what I am building will fit anyone's needs aside from my own. Time will tell I guess.

It will be interesting to see if Dart can keep up its programming language rank rise in the coming months and years. I sure hope so, as I detest JavaScript for any "real" applications I need to develop. Now, back to programming...

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Sunday, April 22, 2012

Dart Language for Interactive SVG Documents

Dynamic SVG Documents using Dart
(Scalable Vector Graphics files)



I am deep in the midst of migrating a Javascript and SVG UI-Components/Widgets set to Dart Language SVG / CSS. As I prepare to publish my rather experimental Dart/SVG widgets source code and examples, I figured I would start with a super-simple example of how to replace JavaScript with Dart (as used in SVG).
UPDATE: I have pushed an initial release of my Dart/SVG GUI Components to github — see my newer blog post about "Introducing dart-squid: Dart/SVG UI Controls" for details — the source-code there will much better demonstrate the potential of Dart / SVG.

Note: the easiest way to run any Dart code, from my experience, is to download the latest Dart-enabled Chromium Browser build — Dartium (from its continuous-build directory) — I use the Dartium-Win version and it is amazingly stable for this early in a development cycle.

A Simple SVG document with Dart-Language

This example is going to be perhaps way too unsophisticated to cause much excitement, but the idea is simply to get you to consider trying Dart Language (instead of JavaScript), as I believe Dart Language has fantastic potential for browser-based business applications among other things. 

Coming from a Delphi, C#, and JS development background, I find Dart to be much closer to Delphi for development productivity than JavaScript.  I.e., I can write much more functionality in the same time using Dart than I could ever do with JavaScript; and, the code quality is immensely improved, more maintainable, extensible, and polished.

Step 1: create a .SVG file — name it whatever you want... perhaps SVG-using-external-Dart.svg or something similar. Copy and paste the following into that file and save it.


<svg    xmlns="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        id="testContainer"
        width="1000"
        height="800"
        xml:space="preserve">
    <script type="application/dart" xlink:href="external-code.dart"/>
    <svg id="testSVGCanvas">
        <rect   id="MySVGRectID" x='10' y='10' width='300' height='150'
                fill='tan' fill-opacity='1' stroke='black' stroke-width='3'/>
        <text stroke='black' x='100' y='100' >Click on Rectangle</text>
    </svg>
</svg>


Step 2: create a .dart file in the same directory — name it to match the xlink:href value we specified in our SVG file — in this case, external-code.dart. Copy and paste the following dart code into that file and save it.


#library("Test");
#import('dart:html');
void setSVGAttributes(SVGElement svgEl, var attributesPairs) {
    attributesPairs.forEach((attr, value){
        svgEl.attributes[attr] = value;
    });
}


//***********************************************************
//********** MAIN FUNCTION CALLED FROM SVG ONLOAD ***********
//***********************************************************
main() {
    SVGElement rectReference = null;
    void MouseDown(Event e) {
        setSVGAttributes(rectReference, {
            'fill': 'purple',
            'opacity': '0.6'
        });
    }
    void MouseUp(Event e) {
        setSVGAttributes(rectReference, {
            'fill': 'tan',
            'opacity': '1'
        });
    }
    print("main loaded");
    
    rectReference = document.query('#MySVGRectID');
    rectReference.on.mouseDown.add(MouseDown);
    rectReference.on.mouseUp.add(MouseUp);
}


Now, you should be able to open that .SVG file using the Dartium browser and you will see a very simple demonstration of using Dart to manipulate the SVG DOM at runtime for some simple interactivity.

In this example, a rectangle will change from tan to purple (while the mouse button is depressed).  You can get a taste for how the dart:html library exposes element events and such here at least (I suggest looking at the APIs on the dart language site; even that base dart:core library is enough to get exited about with real, and quite handy and functional, built-in collections for starters).

Notice that the code I provided here is just one approach, and ridiculously simplified.  Here is another very simple variation on that code, placing the event callbacks within main() if we want.


#library("Test");
#import('dart:html');


void setSVGAttributes(SVGElement svgEl, var attributesPairs) {
    attributesPairs.forEach((attr, value){
        svgEl.attributes[attr] = value;
    });
}


//***********************************************************
//********** MAIN FUNCTION CALLED FROM SVG ONLOAD ***********
//***********************************************************
main() {
    SVGElement rectReference = null;


    void MouseDown(Event e) {
        setSVGAttributes(rectReference, {
            'fill': 'purple',
            'opacity': '0.6'
        });
    }


    void MouseUp(Event e) {
        setSVGAttributes(rectReference, {
            'fill': 'tan',
            'opacity': '1'
        });
    }


    print("main loaded");
    
    rectReference = document.query('#MySVGRectID');
    rectReference.on.mouseDown.add(MouseDown);
    rectReference.on.mouseUp.add(MouseUp);
}



Although I am not demonstrating Dart's full potential here, keep in mind that Dart is a fully object-oriented class-based development language with a very useful optional typing system that make RAD (Rapid Application Development) possible unlike anything you'll experience with JavaScript.  Try it, you may like it!

This super-basic example demonstrates how a dart application can be built within an SVG document. And, trust me, the component set I am programming goes well beyond such simplicity. Stay tuned for more about that...

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Saturday, April 14, 2012

Dart Language in; JavaScript and Delphi out.

Dart Language Fills a Void

Dart Language may become my primary development language!

In a previous blog, I mentioned how Google's Dartium browser for Windows — essentially the Chromium "Chrome" browser with a Dart-Language Virtual Machine (VM) buit in — was made available to developers. Since then, I have been using the regularly-updated builds of Dartium to run my native Dart-language applications (HTML and SVG User-Interfaces with Dart for the business-logic), and I must say, I am absolutely thrilled with the productivity improvements I am seeing when developing with Dart (instead of JavaScript)! Words alone can hardly express the potential this language has for improving web-based software application development.

Dart Language: Web Pages are just the Beginning

Did you catch my use of the term "applications" a bit ago. Dynamic Web content (pages) is just the beginning of what I will be using Dart for. Sure, you can replace your JavaScript code with Dart, and realize the benefit of a much nicer OOP (Object-Oriented Programming) approach to web-development, and realize it NOW, but Dart holds more promise.

Dart's True Potential: Business Applications

I have read a quite a few anti-Dart articles recently, mostly from proponents of JavaScript (ranging from JS evangelists to simply average developers that have used JS for a long time). It has been argued that Dart cannot succeed for various reasons: e.g., concerns that Dart will simply not reach more than a certain percentage of users (if other browsers fail to adopt the Dart VM), that the current JS code base is just too big to migrate to Dart, etc. Although these points may have a bit of validity, the arguments make little sense for any business-internal applications where the browser-choice can be 100% guaranteed to include Chrome (if it remains the only browser to include Dart support). And, really, what is the big deal with installing multiple browsers IF it was needed?

There are millions of software applications that run only "internal" to a business, and many of these internal applications are either "browser-based" or are in need of a transition to "browser-based" form. And, if Dart makes developing such applications a more efficient — and perhaps all-importantly: less-costly — endeavor, then the choice to write applications in Dart will be a simple one. It is not like Dart is difficult to learn if you know JavaScript already; in fact, if you have any OOP background along with some JS experience, you are going to take to Dart Language very quickly, and find yourself incredibly productive compared to JS!

I can't emphasize this point enough: true software applications (not simply public customer-facing web pages) are perfect candidates for Dart. The productivity and re-use of object-oriented development, coupled with a Dart's wonderful core libraries (which are getting better all the time), are a huge leap forward for browser-based applications development. And, this is rather platform-agnostic development too — we're still dealing with a browser that will run on quite a few platforms. And, I have not even touched on the server-side potential (e.g., compared to the spaghetti-code mess of Node.js and 10-level-deep nested javascript closures -- eek!)

Dart: included Libraries = Huge Savings

Ah... the simplicity of instantiating a new List<> object to store references to instances of my custom classes and iterate through them! List is just one of the included Collection types. And, these collections include a nice set of methods for working with the items contained therein. The HTML library provides a somewhat nicer way to work with the DOM than standard JS method too. Overall, Dart is making my life so much simpler and more productive thanks to the language features and the libraries included.

Perhaps more important is how simple it is to create your own libraries. And, unlike JS, you should not worry about global-namespace-pollution; that should be a thing of the past. And when you start writing your libraries, you have all the benefits of a modern typed-language with solid OOP features.

Sure, JS has what is called "prototypical inheritance" and you can achieve *some* encapsulation with closures, but the fact is, for someone with C#, Java, Delphi, or C++ experience, Dart offers "real" inheritance and encapsulation in a much simpler way (i.e., REAL way). Did I mention how wonderful it is to be able to quickly test the Type of an object using "is" when I need to (class / interface testing)! And, you have polymorphic method/constructor signatures, optional parameters, etc. I am a long-time Delphi developer, and I am really taking to Dart in a hurry thanks to all these familiar OOP features.

My first Dart Library: Dart-Based SVG Widgets / Components

I had previously attempted to create a robust SVG (Scalable Vector Graphics) component library using JavaScript, and I got rather far along with it before I hit a wall thanks to JavaScript. JS was simply making my intended component-hierarchy nearly impossible to implement — surely impossible to implement as a formal, strongly-typed, class library as I had envisioned. But, using Dart, I have already surpassed (in little time) the functionality of my previous JavaScript-based SVG widgets and have seen my vision become reality. Dart has provided a much better OOP foundation for building a true software component set / library with!

I have written previously about my desire to replace desktop Embarcadero Delphi-based development with HTML5/CSS3, and I had tried to do so using JavaScript as the underlying language, but simply put: JavaScript sucks compared to Delphi (or C#). Now that I have Dart at my disposal, my transition from Delphi to HTML5/CSS3/Dart is well underway. I have that familiar high-productivity I am used to with Delphi (object Pascal), now nicely coupled with to browser UI technologies of choice (HTML5/CSS3/SVG), and I am moving forward quickly.

Stay tuned for some source-code and samples using Dart! I plan to release my Dart-language SVG Components / Widgets as open-source in the not too distant future. UPDATE: I have pushed an initial release of my Dart/SVG GUI Components to github — see my newer blog post about "Introducing dart-squid: Dart/SVG UI Controls" for details.  Those should demonstrate quite nicely what productivity can be achieved with regards to developing component sets that will run in a browser. And, perhaps people will find the SVG components useful for something I have not even imagined yet. In the meantime, check out Dartium and Dart: this is a language/framework you do not want to overlook.

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Tuesday, October 18, 2011

SVG onload event not firing : Firefox bug / feature with Shortcuts

FireFox not firing SVG onload event

(Windows) Shortcut handling to blame...

I do a fair amount of work with SVG (Scalable Vector Graphics) images / files that contain embedded JavaScript for various event-driven interactive-SVG components. The onload() event, within SVG files, is something I regularly use too. Today I ran into a strange "feature" or "bug" that shows up in Firefox but not in the Google Chrome / Chromium browser — related to this onload event in an SVG document.

I use Chrome as my default browser, especially because I like the included Developer tools a lot, so most initial testing of my web-page HTML, SVG, and JScript code takes place in Chrome before I move onto testing in other browsers (like FireFox). I have been working on my custom SVG RAD Components (tis' what I currently call them), and because I use one particular .SVG file for the main "test rig", I kept a Windows Shortcut on my Windows 7 desktop for a quick reference to that .SVG file.  I just click the shortcut to launch my SVG "application" (in Chrome) or drag the shortcut into a Chrome tab, and that works just fine.  Ah, but not in FF!

FireFox apparently does not resolve shortcut properly if dragged into browser

Being a creature of habit, when I was ready to test my latest SVG file and Javascript code within Firefox (using version 7 currently), I dragged my Windows shortcut (to my SVG file) onto the FF browser and poof... it seemed to load the SVG file, but my onload() event code simply failed to run.  I would have sworn I did this exact same drag-to-load (my SVG) with prior versions of Firefox successfully, but either way, it is not working now.

So, I loaded the page again via drag-and-drop of my Windows-shortcut to my SVG file, but this time with Firebug running (debugger / developer tool).  I quickly see that an error is being generated whereby the event-code referenced in the onload() event was shown as "myOnloadFx is not defined" within the onSVGLoad() code in FireFox (evt=SVGLoad). Clearly something strange was going on here, as this code "works" and has worked in Firefox before.

I played around with the code inside the SVG file a bit, and moved the onload() code from the opening SVG tag's onload="myOnloadFx()" to an inline-script (using <script> tags) just before the SVG's closing tag... and, the problem persisted.  So, what the heck?  After wasting more time on this than I ever should have, I then decided to go to the directory in which the SVG file really existed (vs. using the Windows shortcut to open it), and I dragged the .SVG file onto the Firefox window where it opened fine and ran the onload() event code just as Chrome did.  So, the shortcut-dereferencing/resolution is apparently to blame.


FireFox : want your SVG Javascript onload to fire? Do not open the SVG by dragging a shortcut onto FF


Now I know.  Note: the code executed in my onload() event was in an external Javascript file that is "included" in the SVG by way of code like this: <script type="text/javascript" xlink:href="myExternalSVGcode.js"/>  

Firefox is not properly converting, storing, and subsequently referencing the proper file-locations for included-code like this, but is instead looking in the directory where the shortcut appears (in my case, the desktop).  I confirmed this to be the problem simply by moving a copy of the Javascript (referenced) file onto the desktop along with the Shortcut (.lnk) and voila!  It "fixed" the issue.  UNREAL. 

I have not tested other types of scenarios where this could be a problem, and it is unlikely most people will ever encounter this unless they do software development (and perhaps even just SVG/Javascript with included external javascript files).  But, just in case, I figured I would post my notes here for anyone else that may encounter this weird onload behavior in Firefox.