JSConf.eu opening song - JavaScript Will Listen - Bella Morningstar
- Plask - Dean McNamee
- Plask
<!doctype html> | |
<html> | |
<head> | |
<meta charset="utf-8"/> | |
<title></title> | |
<!--[if lt IE 9]> | |
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script> | |
<![endif]--> | |
</head> | |
<body> |
// Copyright (c) 2011, the Dart project authors. Please see the AUTHORS file | |
// for details. All rights reserved. Use of this source code is governed by a | |
// BSD-style license that can be found in the LICENSE file. | |
// Simple test program invoked with an option to eagerly | |
// compile all code that is loaded in the isolate. | |
// Compiled using frog, the in-progress self-hosted compiler: | |
// dart/frog$ ./frogsh --out=hello.js --compile-only samples/hello.dart | |
class HelloDartTest { | |
static testMain() { |
(-> | |
assertCssBoolean = (msg, selector, el, boolean) -> | |
if !el | |
[selector,el] = [msg, selector] | |
msg = "Unexpectedly #{if boolean then "didn't find" else "found"} '#{selector}' in #{$(el).html().truncate(400)}" | |
unless boolean == !!($(el).find(selector).length > 0) | |
fail msg | |
assertHasCss = (msg, selector, el) -> | |
assertCssBoolean msg, selector, el, true | |
assertHasntCss = (msg, selector, el) -> |
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.
I'm going to cover a simple, but effective, utility for managing state and transitions (aka workflow). We often need to store the state (status) of a model and it should only be in one state at a time.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
The goal of the style guide is foremost to promote consistency and reuse of pattern from other languages in order to improve readability and make Elm easier for beginners. This includes moving Elm away from Haskell’s indentation style and even making some parts look closer to JavaScript. These decisions are intentional.
We would like Elm to look friendly and familiar to users of any language — especially JavaScript — so they can discover Elm’s powerful features without being overwhelmed. This does not intend to weaken or discourage any features of Elm, but instead to make them more accessible.
A secondary goal of the style guide is to encourage short diffs when changes are made. This makes changes more clear, and helps when multiple people are collaborating.