The Languages

The most important part of Elements are of course the programming language themselves. Elements gives you the choice of five languages. While of course these languages are different, and each has its own strengths and benefits, in general they are the same to the compiler, and any language can be used for pretty much anything you want to do with Elements, and on all platforms. It comes down do a choice of which syntax you prefer, or what language you might have existing code in.

One interesting fact: because language is really just syntax, and Elements handles all languages in the same compiler, you can freely mix languages within a project – the compiler will pick the right front-end by the file extension. All code in a project lives within the same "space", and can freely interact, regardless of language.

• Oxygene – our own language, based on Object Pascal and modernized for the 21st century. Read more.

• Hydrogene – also referred to as "Remobjects C#" this is our version of Microsoft's C#, fully compatible w/ Microsoft's dialect. Read more.

• Silver – our implementation of Apple's new(ish) Swift programming language. Read more.

• Iodine – adds support more the Java language (not to be confused with the Java platform). Read more.

• Gold – the latest addition to the Elements family, this brings support more the Go language. Read more.

Target Platforms

Elements lets you compile your code for for different target platforms. A target platform can be an operating system (such as Windows, or macOS) or a more virtualized multi-platform runtime environment (such as Java or .NET)

The same languages are available on each platform and (especially with some of the libraries discussed below) it is really easy to share code between platforms. But first and foremost, Elements is a great native fit on each individual platform, giving you full access to all the native APIs, frameworks, UI widgets, and so on.

• .NET – The .NET platform included the regular .NET Framework, as well as Mono, .NET Core, ASP.NET, WinRT and Universal Windows Projects). .NET is a great target for writing Windows GUI apps, cross-platform servers (to deploy with .NET Core or Mono), command line tools, and websites. Read more.

• Cocoa — Build apps for Apple's macOS, iOS, iPadOS, tvOS and watchOS, based on the Cocoa frameworks. Code interacts directly with Objective-C runtime classes and APIs, and also has full access to lower-level C and POSIX APIs. Read more.

• Android — Build applications for Android, both using then regular Java-based Android SDK as well as extensions using the native Android NDK (using the same language!). SDK applications give you full access to the standard Android APIs, while Android NDK extensions are great for high-performance or low-level code in Android apps that cannot easily be achieved on the Java level. Read more.

• Java – Build projects for the Java Runtime and related platforms. Your code will be compiled to Java byte code that can run anywhere the Java VM is supported. Read more.

• WebAssembly — Build modules that can run in the browser and interact with JavaScript and the HTML Document Object Model. Read more.

• Windows (native) — Build CPU-native Windows projects against the lower-level Win32 API or using Delphi RTL/VCL. Read more.

• Linux — Build CPU-native Linux projects against the low-level libc and POSIX APIs. Read more.

IDEs

• Fire – Fire is our native integrated development environment (IDE) for the Mac. It is fast and lightweight, yet powerfully and provides you with all the tools you need to work productively on your Elements projects, von macOS. Read more. Watch Video.

• Water – Water then is our IDE for Windows. It too is designed to be fast and efficient and not get in your way, and you will find it a joy to work in, if you develop on Windows. Read more. Watch Video.

• Elements in Visual Studio – for developers on Windows who prefer using Microsoft's Visual Studio IDE, Elements also integrates with Visual Studio 2015, 2017 and 2019 to work seamlessly alongside Microsoft's Visual C# and Visual Basic and to give the same developer experience as for those languages. Read more.

The Compiler

You can think of the compiler as the central "brain" of the Elements tool chain.

It's at the heart of the build process and it is what takes your source code (no matter what language it is in) and turns it into excitable code for a specific platform.

Roughly speaking, the compiler is divided in two half, the front-end and the back-end, which work independently. This is what allows Elements to support different languages and different platforms in a free mixture.

There is a separate front-end for each language. This is the part that understands the language syntax, and can process the code you write into something the compiler can understand. The different front-ends can be mixed in a single project – for each source file, the compiler will pick the right front-end that knows to handle the specific language – Oxygene, C#, Swift or Java, based on the file extension. The compiler also treats .XAML files (used by the .NET platform) as source files of sorts.

All source files in a project get processed into a single language-agnostic code tree. This is what allows you to freely mix and match all four languages in the same project, and code written in different languages to interact seamlessly.

There is a separate back-end for each platform, and each project (or rather each target within a project) uses one specific back-end, depending on the output platform.

The back-end takes all the code processed by the front-ends, and – without knowing what language it came from, compiles it down to excitable code for the target platform. The result can be byte code (for the .NET or Java platforms) or CPU-native executable code as "object" files (for the Cocoa and Island platforms).

Compiler Backends

• Echoes – the Echoes back-end compiles projects for .NET platforms (including Mono, .NET Core, ASP.NET, WinRT and UWP). Code will compile to IL code, same as Microsoft's Visual C# or Visual Basic compilers, and your code will run everywhere there's a Common Language Runtime. Read more.

• Cooper – the Cooper back-end compiles projects the Java Runtime, and related platforms, including Android. Your code will be compiled to Java byte code that can run in the JVM, and possibly post-processed from there for Android and other sub-platforms. Read more.

• Island – the Island back-end, supports building CPU-native projects for Window, Linux, Darwin (Apple macOS, iOS, tvOS and watchOS) and the native Android NDK, as well as WebAssembly projects that run in the browser. Read more.

• Toffee – the legacy Toffee back-end compiles for Cocoa platform and the Objective-C runtime employed by Apple's operating systems. In time, it will be fully replaced by the Island/Darwin back-end. Read more.

Note that while the compiler is the core piece of technology that generates your final product, it does not work alone. There are steps that need to be taken both before and after compilation to arrive at the final distributable for you project – and that's where the EBuild tool chain comes in:

EBuild

There are a lot of steps involved in taking your project (which can consist of source code files, but also other files and settings) and turning it into a final deliverable you can run or distribute to your users.

The EBuild tool chain is what brings it all together; it analyses your project, performs all the tasks necessary to build it int the right order (including, at some stage, running the compiler), and packages up your final executable.

Before compilation, a lot of housekeeping needs to be done in order to know what and how to compile everything. It needs to be determined what version of a platform SDK your project should build against. External references, including platform libraries, third party components and packages might beed to be located, and so on.

After compilation, additional steps might be needed, as well. On Cocoa and Island platforms, compiler output needs to be linked. Resources might need to be converted or processed. For Android, macOS and iOS applications, the executable and other files need to be "bundled" together.

EBuild takes care of all of these tasks, smartly keeping track of which ones can be skipped for incremental builds (if relevant parts of the project have not changed), and gathering and reporting back any errors or warnings that might be encountered. See the "Other Platform Build Chain Tools" section below for more details on some of the tasks.

EBuild is used under the hood, when you perform a build inside the IDE. But there is also the ebuild command line tool you can use (manually or in automated scripts) to build your projects.

Read more.

The Libraries

Elements comes with a few optional code libraries you can leverage in your projects (in addition to the standard platform APIs provided as part of the operating system, and in addition to any of your own or third party libraries you might want to use). These libraries split into two categories, platform-specific support libraries, and other optional "convenience" libraries.

Platform Support Libraries

For each platform, Elements has a small support library that provides helper functionality that the compiler needs to support certain language features on the platform (for example, to bring support the LINQ language feature of Oxygene and C# on Java, Cocoa and Island). For Island, which cannot rely on high-level vendor APIs on its platforms, this library also provides the basic object model and common base types such as Object, String, Lists, etc.

These libraries are named after the platform, and will be referenced in new projects automatically, as needed:

• Echoes.dll – Read more, Source on GitHub
• cooper.jar – Read more, Source on GitHub
• libToffee.fx – Read more, Source on GitHub
• Island RTL – Read more, Source on GitHub.

There also is an (optional, but recommended) support library for Swift that provides common types and APIs that are considered part of the Swift language (such as the [T] array type, or functions such as print()).

• Swift Base Library – Read more, Source on GitHub
• Go Base Library – Read more, Source on GitHub

Other Optional Libraries

While the above libraries are essential for using (some) of the compilers functionality on the platforms, the following libraries are entirely optional, and merely provide convenience functionality that you may or may not choose to use in your projects.

• Elements RTL – Elements RTL provides platform-independent implementations of many base classes and base functionality, in many cases toll-free bridged to platform specific APIs. Elements RTL is great to write code that is platform-agnostic by letting you use common base types that behave consistently across platforms.
  Read more, Source on GitHub, Tutorials.

• Delphi RTL and VCL – Delphi RTL provides a cross-platform port of common types and APIs provided by Embarcadero's Delphi compiler. It is intended mainly for Delphi developers looking to port or shared code from Delphi to Oxygene. Read more, Source on GitHub.

• Internet Pack – Internet Pack provides a platform-independent API for creating TCP/IP client and server applications using various standard (or custom) protocols. Source on GitHub.

• EUnit – EUnit is a cross-platform unit testing framework for Elements. It allows you to easily write tests classes for your code, run the tests and get test results reported inline in Fire or Water.
  Read more, Source on GitHub.

Other Elements Tools

• CrossBox – CrossBox connects the IDE with remote servers for build tasks and/or debugging. For example, perform code signing on a Mac while working on Windows, or debug your projects on a target environment different than the computer you work on. Read more

• Oxidixer – Oxidizer lets you import code written in a variety of languages and convert it to supported Elements languages. Read more

• FXGen – FXGen generates .fx files to import external APIs such as core operating system libraries or third party libraries written in C for use with Elements. Read more

• CodeGen4 – CodeGen4 is a library used to generate source code in arbitrary languages (both Elements-supported languages and others) from an abstract syntax tree generated in code.

Other Platform Build Chain Tools

• Linker
• Resource processing
• Code signing
• Bundle packaging (Cocoa, Android)

...and more