HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dart-archive
dev_compiler
JavaScript2015–2017
dart-archive / dev_compiler · Archived

dev_compiler

DEPRECATED - Moved to main SDK

Languages & CompilersLibraries & SDKs
Explore on GitHubRead Hacker News discussions
9Distinct people
15Mentions
0Explicit recommenders
131GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

DEPRECATED - Moved to main SDK

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month15 dated mentions

Observed mentions: 2015-03-25 20:29:19 UTC to 2017-03-31 21:32:44 UTC.

01232015-03-01 00:00:00 UTC to 2015-04-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsMar 20152015-04-01 00:00:00 UTC to 2015-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-05-01 00:00:00 UTC to 2015-06-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015-06-01 00:00:00 UTC to 2015-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-07-01 00:00:00 UTC to 2015-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-08-01 00:00:00 UTC to 2015-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-09-01 00:00:00 UTC to 2015-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-10-01 00:00:00 UTC to 2015-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-11-01 00:00:00 UTC to 2015-12-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2015-12-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2016-02-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2016-02-01 00:00:00 UTC to 2016-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-03-01 00:00:00 UTC to 2016-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMar 20162016-04-01 00:00:00 UTC to 2016-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-05-01 00:00:00 UTC to 2016-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-06-01 00:00:00 UTC to 2016-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-07-01 00:00:00 UTC to 2016-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-08-01 00:00:00 UTC to 2016-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-09-01 00:00:00 UTC to 2016-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-10-01 00:00:00 UTC to 2016-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-11-01 00:00:00 UTC to 2016-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-12-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2017-02-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-02-01 00:00:00 UTC to 2017-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-03-01 00:00:00 UTC to 2017-04-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsMar 2017

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 20152015-03-01 00:00:00 UTC2015-04-01 00:00:00 UTC202
Apr 20152015-04-01 00:00:00 UTC2015-05-01 00:00:00 UTC000
May 20152015-05-01 00:00:00 UTC2015-06-01 00:00:00 UTC202
Jun 20152015-06-01 00:00:00 UTC2015-07-01 00:00:00 UTC101
Jul 20152015-07-01 00:00:00 UTC2015-08-01 00:00:00 UTC000
Aug 20152015-08-01 00:00:00 UTC2015-09-01 00:00:00 UTC000
Sep 20152015-09-01 00:00:00 UTC2015-10-01 00:00:00 UTC000
Oct 20152015-10-01 00:00:00 UTC2015-11-01 00:00:00 UTC000
Nov 20152015-11-01 00:00:00 UTC2015-12-01 00:00:00 UTC303
Dec 20152015-12-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
Jan 20162016-01-01 00:00:00 UTC2016-02-01 00:00:00 UTC202
Feb 20162016-02-01 00:00:00 UTC2016-03-01 00:00:00 UTC000
Mar 20162016-03-01 00:00:00 UTC2016-04-01 00:00:00 UTC000
Apr 20162016-04-01 00:00:00 UTC2016-05-01 00:00:00 UTC000
May 20162016-05-01 00:00:00 UTC2016-06-01 00:00:00 UTC000
Jun 20162016-06-01 00:00:00 UTC2016-07-01 00:00:00 UTC000
Jul 20162016-07-01 00:00:00 UTC2016-08-01 00:00:00 UTC000
Aug 20162016-08-01 00:00:00 UTC2016-09-01 00:00:00 UTC000
Sep 20162016-09-01 00:00:00 UTC2016-10-01 00:00:00 UTC101
Oct 20162016-10-01 00:00:00 UTC2016-11-01 00:00:00 UTC101
Nov 20162016-11-01 00:00:00 UTC2016-12-01 00:00:00 UTC000
Dec 20162016-12-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
Jan 20172017-01-01 00:00:00 UTC2017-02-01 00:00:00 UTC101
Feb 20172017-02-01 00:00:00 UTC2017-03-01 00:00:00 UTC101
Mar 20172017-03-01 00:00:00 UTC2017-04-01 00:00:00 UTC101

What Hacker News says

15 sources
kjksf·Mar 31, 2017
Even the original, untyped, Dart was designed to be easier to optimize that JavaScript (e.g. it's class based, not prototype based, so the runtime doesn't have t work as much to optimize object access). Recently Dart has added a strong mode (https://github.com/dart-archive/dev_compiler/blob/master/STR..., http://news.dartlang.org/2017/01/sound-dart-and-strong-mode....). One of the reasons for strong mode is to enable better optimizations (https://www.dartlang.org/guides/language/sound-faq#why-stron...).
In Fuchsia: a new operating system
munificent·Feb 15, 2017
TypeScript has some really cool type system features. Union and intersection types are fun and really handy when interacting with dynamically typed code. (If you go back through history, you'll find almost every language with union types also has a mixture of static and dynamic typing. See: Pike, Typed Racket, etc.) Self types (the "this" in the return type) is handy. I can see us adding some of those to Dart eventually. Non-nullable types are great, which I've said for a very long time[1]. We are finally working to try to add them into Dart[2]. It's early still, but it looks really promising so far. It kills me that I've been saying we should do them for Dart since before TypeScript even existed and still they beat us to the punch, but hopefully we can at least catch up. The main difference between TypeScript and Dart's type systems (and
Read the rest
by the latter I mean strong mode[3], not the original optional type system) is that Dart's type system is actually sound. This means a Dart compiler using strong mode can safely rely on the types being correct when it comes to dead code elimination, optimization, etc. That is not the case with TypeScript and at this point will likely never be. There is too much extant TypeScript code and JS interop is too important for TypeScript to take the jump all the way to soundness. They gain a lot of ease of adoption from soundness, but they give up some stuff too. In addition to the above, it means they'll have a hard time hanging new language features on top of static types because the types can be wrong. With Dart, we have the ability to eventually support features like extension methods, conversions, etc. and other things which all require the types to be present and correct. [1]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-... [2]: https://github.com/dart-lang/sdk/pull/28619 [3]: https://github.com/dart-archive/dev_compiler/blob/master/STR...
In Google’s not-so-secret new OS
munificent·Jan 18, 2017
> Part of the intended contract for error reporting in Go > is that functions include relevant available context, > including the operation being attempted (such as the > function name and its arguments). I know the Go folks don't like exceptions, but this is an example of them learning the hard way that about one useful thing they lost by deciding to not do exceptions. Exceptions give you stack traces automatically. All of that context (and more) is there without library authors having to manually weave it in at every level of calls. > Today, there are newer attempts to learn from as well, > including Dart, Midori, Rust, and Swift. For what it's worth, we are making significant changes to Dart's generics story and type system in general [1]. We added generic methods, which probably should have been there the entire
Read the rest
time. Generics are still always covariant, which has some plusses but also some real minuses. It's not clear if the current behavior is sufficient. Our ahead-of-time compilation story for generics is still not fully proven either. We don't do any specialization, so we may be sacrificing more performance than we'd like, though we don't have a lot of benchmark numbers yet to measure it. This also interacts with a lot of other language features in deep ways, like nullability, whether primitive types are objects, how lists are implemented, etc. [1]: https://github.com/dart-lang/dev_compiler/blob/master/STRONG...
In My Go Resolutions for 2017
labrador·Sep 21, 2016
I've been a long time fan of Dart but I've recently (this week) given up on it for my purposes, which are write browser SPA's that need to run in different browsers. My sense is that after the Chrome team decided not to include the Dart VM in Chrome, Dart started looking for a new story. That story is Flutter, which is Dart running in the Dart VM on mobile devices [1] It is not Dart converted to JavaScript so it can run in any browser, despite the awesome work of the dart2js authors and the relatively new dev_compiler project [2]. The latter will be awesome when done, because the goal is to convert Dart to ES6/ES2015. However, it is my impression that Google really doesn't care that much about transpiling Dart to JavaScript. I was willing to put up with the huge file size dart2js produced, because Dart made my life easier and something be
Read the rest
tter was coming. However, it's been a long time and the pace of Dart transpiling work is too slow. I converted my Dart app to TypeScript (size dropped from 650kb to 60 kb) and am happy for that, but sad that Google does not put more people on the dev_compiler team to keep long term enthusiasts like me on board. I'm sure Flutter is fantastic and will take a look when I have a need for that kind of solution. I can't really blame Google, because the JavaScript community turned it's back on Dart, but I wish they would just state the new goals and not leave us hanging. [1] https://flutter.io/faq/ [2] https://github.com/dart-lang/dev_compiler
In If TypeScript is so great, how come all notable ReactJS projects use Babel?
munificent·Jan 11, 2016
A number of people on the Dart team are working on strong mode[1], which is very close to what you're asking for. I say "very close" because "No optional types" is ambiguous. Type annotations are still optional in strong mode because in most cases it will infer the static type for you. Strong mode still also supports a dynamic type—much like C# does—because that's useful for things like interop or working with data. Strong mode was initially created because it helps produce cleaner JS (unsurprising that static types help with static transpilation) but what we're hearing from customers is that they like it for better type safety and tooling. Even many of the Flutter[2] folks, who don't compile their Dart code to JS at all, are using strong mode because they get better static checking. [1]: https://github.com/dart-lang/dev_compiler/blob/mas
Read the rest
ter/STRONG... [2]: http://flutter.io/
In Why I'm joining the Dart Team
munificent·Nov 6, 2015
> I hope that you built around the Dart Tooling of IntelliJ Dart's IntelliJ tooling is built on top of a reusable analysis library written in Dart[1]. It exposes a service-like API so that it can be integrated into lots of different editors/IDEs without each having to reinvent the world. Just to be clear, this is full-featured, rich static analysis, not just parsing and syntax highlighting. The entire static type system of the lanugage, including the new stronger type checking[2] is in there. The Atom plug-in uses that too. [1]: https://pub.dartlang.org/packages/analyzer [2]: https://github.com/dart-lang/dev_compiler/blob/master/STRONG...
In Flutter – Cross-platform mobile framework from Google
michaelwww·Jun 27, 2015
It wasn't that long ago the Brendan Eich was still hostile to Dart [https://news.ycombinator.com/item?id=9266599] but now he seems to have softened. "Ideally we’ll get things in JavaScript like big integers/bignums that Dart has that JavaScript doesn’t yet" Historically, Mr. Eich has been critical of Dart, and if you follow that thread above he has nothing good to say about Dart, so this is a change, probably brought on by the everyone concluding that the Dart VM has no future in browsers and therefore is not a threat to Javascript. Dart (dartlang) has a lot of nice features, is easy to work with and can increase productivity greatly in some cases. Dart still has a future if they improve the Javascript output as this project is attempting:[https://github.com/dart-lang/dev_compiler] I'm glad Mr. Eich has opened his mind to some of the good
Read the rest
things in Dart.
In Why We Need WebAssembly: An Interview with Brendan Eich
tosh·May 10, 2015
The Dart team is working on a compiler called 'ddc' (Dart Dev Compiler) https://github.com/dart-lang/dev_compiler It currently targets ES6 and also comes with a more strict type checker. Project goals: * Effective static checking and error detection. * A debugging solution for all modern browsers. * Readable output. * Fast, modular compilation of Dart code. * Easy use of generated code from JavaScript.
In Dart's Macro Language
skybrian·May 4, 2015
Dart has static analysis as well. There is a server that reports errors and warnings in an IDE, and you can also run it as a batch job using the dartanalyzer command if you like. You can run dartanalyzer in a test, parse the output, and treat warnings as errors, and some people do. The question is whether the existing static analysis is enough. Some people think it isn't, and the Dart team has a couple of projects to improve on it. See the Dart Development Compiler [1] and linter [2]. The DDC project in particular plans to implement a subset of Dart that makes it easier to check types statically. This is all supposed to be integrated into the analysis engine using a plugin architecture so that these errors will show up in IDE's and anywhere else you want to display errors. It's work in progress, as are some of the other type checkers. [1]
Read the rest
https://github.com/dart-lang/dev_compiler [2] https://github.com/dart-lang/linter
In Consider Static Typing in Ruby

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.