summaryrefslogtreecommitdiff
path: root/book/src/main/scalatex/book/handson/CrossModules.scalatex
diff options
context:
space:
mode:
authorLi Haoyi <haoyi@dropbox.com>2014-11-02 04:57:37 -0800
committerLi Haoyi <haoyi@dropbox.com>2014-11-02 04:57:37 -0800
commita33254276bd211bf33be86eeb871ddbfe36fdb47 (patch)
treeb257d473be4fa110f7846f372ea94fc6714dad90 /book/src/main/scalatex/book/handson/CrossModules.scalatex
parentd00a2e25a9ee527fa39feb04c3137715501e9fda (diff)
downloadhands-on-scala-js-a33254276bd211bf33be86eeb871ddbfe36fdb47.tar.gz
hands-on-scala-js-a33254276bd211bf33be86eeb871ddbfe36fdb47.tar.bz2
hands-on-scala-js-a33254276bd211bf33be86eeb871ddbfe36fdb47.zip
Moved `examples` into `examples/demos`, sketched out a simple example cross-module
Diffstat (limited to 'book/src/main/scalatex/book/handson/CrossModules.scalatex')
-rw-r--r--book/src/main/scalatex/book/handson/CrossModules.scalatex17
1 files changed, 16 insertions, 1 deletions
diff --git a/book/src/main/scalatex/book/handson/CrossModules.scalatex b/book/src/main/scalatex/book/handson/CrossModules.scalatex
index 30404ce..9b1f62c 100644
--- a/book/src/main/scalatex/book/handson/CrossModules.scalatex
+++ b/book/src/main/scalatex/book/handson/CrossModules.scalatex
@@ -1 +1,16 @@
-TODO \ No newline at end of file
+@p
+ We've spent several chapters exploring the experience of making web apps using Scala.js, but any large app (web or not!) likely relies on a host of libraries in order to implement large chunks of its functionality. Ideally these libraries would be re-usable, and can be shared among different projects, teams or even companies.
+@p
+ In JVM-land, the standard method for distributing these libraries is as @a("Maven Artifacts", href:="http://stackoverflow.com/questions/2487485/what-is-maven-artifact"). These are typically published in a public location such as @a("Maven Central", href:="http://search.maven.org/"), where others can find and download them for use. Typically downloads are done automatically by the build-tool: in Scala-JVM typically this is SBT.
+@p
+ In Javascript-land, there are multiple ways of acquiring dependencies: @a("CommonJS", href:="http://en.wikipedia.org/wiki/CommonJS") and @a("RequireJS/AMD", href:="http://requirejs.org/") are two competing standards with a host of implementations. Historically, a third approach has been most common: the developer would simply download the modules himself, check it into source-control and manually add a @hl.html{<script>} tag to the HTML page that will make the functionality available through some global variable.
+@p
+ In Scala.js, we side with the JVM standard of distributing libraries as maven jars. This lets us take advantage of all the existing tooling around Scala to handle these jars (SBT, Ivy, Maven Central, etc.) which is far more mature and cohesive than the story in Javascript-land. For example, the Scalatags library we used in the earlier is @a("published on maven central", href:="http://search.maven.org/#search%7Cga%7C1%7Cscalatags"), and adding one line to SBT is enough to pull it down and include it in our project.
+
+@p
+ One interesting wrinkle in Scala.js's case is that since Scala can compile to both Scala.js and Scala-JVM, it is entirely possible to publish a library that can run on both client and server! This chapter will explore the process of building, testing, and publishing such a library.
+
+@sect{A Sample Project}
+
+ @p
+ As always, we will start with an example: in this case a tiny library whose sole purpose in life is to take a series of timestamps (milliseconds UTC) and format them into a list of strings.