Theory
Write Dart before you install Dart
New language, and the lab machines have no Dart SDK, no Flutter, and a queue for the one admin password.
No obstacle at all: open a browser, visit dartpad.dev, and you are writing and running Dart in 10 seconds, on anything with a screen: lab PC, your phone in the bus.
And hiding inside that convenience is a genuine puzzle worth marks: browsers only run JavaScript: so HOW is your Dart running in one? The answer is the second tool of this lesson.
Theory
DartPad, formally
DartPad is Dart's free online editor at dartpad.dev:
- zero installation: the editor, compiler and console all live in the page
- instant feedback: type, press Run, output appears in the console panel; errors underline as you type
- shareable: snippets get URLs: how classmates swap experiments
- supports the core libraries (and Flutter samples in its Flutter mode)
Its honest limits: no dart:io (no reading or writing files: a browser page is sandboxed away from your disk: the same law behind BCA405-01's browser rules) and no arbitrary packages. A practice ground, not a build tool.
Practical
Paste this into dartpad.dev and press Run
void main() {
var events = ['Garba Night', 'Coding Contest', 'Robo Race'];
int day = 2;
print('TechnoUtsav, day $day');
for (var e in events) {
print(' $e');
}
// Console shows the header and 3 indented event names.
// No install, no SDK, no admin password.
}
Theory
dart2js: the translator browsers require
Browsers natively execute exactly one language: JavaScript (BCA405-01's whole world). They have no Dart engine.
dart2js closes the gap: a compiler that translates Dart source into optimised JavaScript:
dart compile js app.dart (the modern CLI; the classic tool name is dart2js)
Out comes a .js file any browser runs: your Dart web app, delivered in the only currency browsers accept. The output is lean: dart2js analyses what your code actually uses and drops the rest (dead-code elimination).
And the pleasing loop: DartPad itself works this way: your snippet is compiled to JS behind the scenes, which is how Dart "runs" in a JS-only browser.
Quiz
Why does dart2js need to exist at all?
- To make Dart programs run faster than native Dart
- Because browsers natively execute only JavaScript, so Dart must be translated to reach the web
- To convert JavaScript projects into Dart automatically
- Because DartPad cannot run loops without it
Show the answer
Because browsers natively execute only JavaScript, so Dart must be translated to reach the web
The browser is a JavaScript-only runtime: no Dart VM lives inside Chrome or Firefox: so Dart's road to the web is translation, and dart2js is the translator. This mirrors Unit 1 of BCA404 (many languages, one MSIL) inverted: one language, compiled to whatever the target runtime speaks: AOT for phones, JS for browsers. Option A misreads direction and purpose: compiled JS aims to match hand-written JS, not beat native Dart. Option C reverses the arrow: no tool un-translates JS into Dart. Option D invents a dependency: DartPad uses dart2js because of the browser law, not for loops.
Think first
Why can't DartPad read a file?
In DartPad, import 'dart:io' fails, and no snippet can open events.txt. Connect this limit to WHERE DartPad's code actually executes and a rule you met in BCA405-01, then tap.
Show the answer
Your snippet runs (as compiled JS) inside a browser page, and browser pages are sandboxed: no reaching into the visitor's disk: the same security law that shaped everything in BCA405-01. dart:io is Dart's file-and-process library for programs running on a real machine (command line, servers); a browser tab is not that place, so DartPad cannot offer it. The practical consequence: file-handling Dart practice needs the real SDK on a real machine: exactly the command-line route next lesson formalises.
Watch out
Tool-boundary confusions
DartPad is not "Dart lite": the language is full; the ENVIRONMENT is sandboxed. Loops, classes, functions: everything core works.
dart2js is for the web target only: phones get AOT native code (last lesson); do not write that Flutter apps ship as JavaScript.
Compiled JS is not for hand-editing: dart2js output is machine-optimised; you maintain the Dart, never the generated .js: the same source-vs-output discipline as every compiler you have met.
Theory
One language, three destinations
Draw Dart's shipping map once: JIT while developing, AOT native for phones, dart2js for browsers: one source, three runtimes, each getting what it can execute. That map answers this unit's why-questions in one figure. Next lesson completes the tooling story: the 3 WAYS to execute Dart (command line, DartPad, IDE) and when each earns its place in your week.
Summary
Key takeaways
- DartPad (dartpad.dev): zero-install browser editor: type, Run, console output, shareable snippets.
- Its sandbox limits: no dart:io (no files), no arbitrary packages: practice ground, not build tool.
- Browsers execute only JavaScript: dart2js translates Dart to optimised JS for the web.
- Modern spelling: dart compile js app.dart; output is lean via dead-code elimination.
- DartPad itself runs your code by compiling it to JS behind the scenes.
- Phones get AOT native code; the web gets JS: one language, per-target delivery.
- Memory hook: the pad practises, dart2js translates, the browser only speaks JS.