ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
Examine the idea of JavaScript...
... within the browser
... on the server
... in/on/as the database
... as a complete JavaScript stack
... and feel inspired! (Hopefully)
Modern Web Architecture
Fully client-side activated client
Web: Single-Page Application
Mobile: Native, hybrid, mobile web, whatever
REST calls to the server for data in JSON/XML format
Server talks to the database
Relational is fine...
... but sometimes NoSQL offers advantages
widely-believed falsehoods
incorrect assumptions
lovingly-endorsed "alternative facts"
mistakes that are all too easy to repeat
"anti-patterns"
"Essentially everyone, ... makes the following assumptions.
"All turn out to be false in the long run and all cause big trouble and painful learning experiences."
... once you know about them, you can avoid them
... "Everyone makes these assumptions"
largely because they're easy to make
and they help us avoid hard truths
and painful realizations/pain points
"Essentially everyone, when they first build an distributed system, makes the following 10 assumptions. All turn out to be false in the long run and all cause big trouble and painful learning experiences."
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous
Why JavaScript, again?
Never going to die in the Web world
Dynamic language
C-family syntax
First-class functions, growing functional features
Small core language set
Because... SCIENCE!
Modern JavaScript Web Architecture
Fully client-side activated client
Web: Single-Page Application
Mobile: Native, hybrid, mobile web, whatever
REST calls to the server for data in JSON/XML format
Server talks to the database
Relational is fine...
... but sometimes NoSQL offers advantages
Client apps need to reside entirely on one tier
In other words, no network round-trips for presentation
The only stuff traversing the network should be data
Mobile: client-side app (native or hybrid)
Web: Single Page Application, usually using JS
This implies Angular/React/Vue or some other JS framework
Opionated: very strong design decisions
Single-Page App: all the action happens in one HTML file
MVC: Model-View Controller separation of concerns
All of the application (views, etc) downloaded at once
Extensively modifies the DOM at runtime
Dependency-injected
Testable
JavaScript
Framework
In fact, Angular tries to be even more rigorous about it
Views: HTML and CSS
Controllers: Javascript
Models: JSON objects
jQuery and other frameworks see a lot of "intent bleed"
DOM manipulation in callbacks
data manipulation in DOM-related code
it's just "too easy" to break the rules
Web applications have no excuse to be not tested
HTML is easily parsed and examined
HTTP is trivial to fake/mock
libraries (Selenium) to handle the heavy lifting
Modules: grouped JavaScript functionality
Components: logically-cohesive units of UI
Templates: views
Data binding: binding between UI and models
Metadata: "glue"
Services: specialized objects used to perform specific actions
Directives: "custom HTML tags" specific to a purpose
Dependency Injection
Templates: HTML with additional markup
Expressions: computed values
Scope: hierarchical data collections
Compiler: parses the template and instantiates directives and expressions
Filter: formats the value of an expression for display to the user
Titanium
https://titaniumsdk.com/
https://github.com/tidev/titanium_mobile
Unified (across devices) JavaScript API
UI abstraction (Alloy framework) uses native UI components
UI abstraction normalizes UI across devices
Titanium
Unified UI abstraction: "ugly everywhere"
Increased developer management complexity
JavaScript API is entirely unique to Titanium
It's all about the NodeJS
Realistically, any server-side environment could work
IronJS on .NET
Nashorn on JVM
NodeJS is Google's V8 executing server-side
NodeJS is JavaScript... on the server
Yes, that's really all it is
Actually, it's Javascript outside of the browser
on the command-line
in the NoSQL database
in your web server
on the server itself (outside of the web server)
anywhere else you can embed the engine
Technically, NodeJS is the Google V8 engine
open-source implementation of JavaScript
embedded in the Chrome browser, but...
Google made it available to run at the command-line
Then they started "extending" it in various idiomatic ways
So... why does everyone care?
Because JavaScript is hot
So... why does everyone care?
Because JavaScript is hot
JavaScript-on-the-client, JavaScript-on-the-server
Scripting language vs "system language" (Java, C#, etc)
Lighter-weight stack (Node vs JavaEE, Node vs .NET)
"Portable code" across Mac/Windows/Linux
Truthfully, half the magic is in the packages (npm)
Several NoSQLs offer JavaScript-friendly storage
MongoDB
CouchDB
PouchDB (http://www.pouchdb.com)
TaffyDB (http://www.taffydb.com)
Meteor (meteor.com) is an all-Javascript stack
Think AngularJS + NodeJS + Mongo + other support
Can either host with Meteor's cloud...
... or bundle as a Node/Mongo app and host elsewhere
Includes command-line tools and ecosystem (Atmosphere)
Meteor's core concepts:
develop in one language
data on the wire (not HTML)
embrace the ecosystem (NodeJS/npm)
full-stack reactivity
Meteor buzzword bingo:
Pure JavaScript
Live page updates
Clean, powerful data synchronization
Latency compensation
Hot Code Pushes
Sensitive code runs in privileged environment
Fully self-contained application bundles
Interoperability
Smart packages
Meteor architecture:
Client-side: HTML, CSS, JS
"Blaze" (Meteor's own)
AngularJS
React
Server-side: NodeJS + middleware packages
Database: MongoDB
It's now possible to be a "JavaScript-only" developer
But is it wise?
Is there any real advantages to being so?
Are there significant drawbacks?
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Co-founder, Solidify US
http://www.solidify.dev
Principal -- Neward & Associates
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)
See http://www.newardassociates.com