Weaving a better Web with Haxe

Why Though?

Web Front End is a Minefield

Exhibit A: the different types of mines you can expect to blow your foot off:

  • HTML is weird (DOM even weirder) and what nice ideas there are, are barely used
  • CSS is super cool, surprisingly well designed and very powerful, if you know - which nobody does
  • JS is designed in 10 days and has been "iterated" by committee for two decades now
  • lots of politics, most stuff is broken most of the time, hype driven development, low entrance barrier, easy rollout
  • But in the end we get GitHub, VSCode, Slack, ...

It's downhill from there

Web development

is a thing

The Web needs Fixing

  1. Enough people want to see it fixed to the point where ANYTHING goes
    • For reference, Haxe: 2005, 3.1 ⭐
    • Elm (Haskell light for FE only): 2012, 5.5⭐ (Jason, Prezi)
    • PureScript (Haskell-like): 2013, 6.1⭐ (Franco, Stephane)
    • imba ("Ruby" with JSX): 2015, 3.7 ⭐
    • ... etc. (kit)
  2. Haxe can fix it better
  3. Haxe could use new niches
  4. Everybody benefits \o/

How to infiltrate any eco-system with Haxe

  1. Get rolling with what's already there, but don't get too involved
  2. Evolve your own stuff when ready
  3. Congratulations, you now have super powers!

Unfortunately, that's becoming increasingly harder.

Case study: Events

Step 1: Implement EventDispatcher

   ...

Step 10: Design signals abstraction

   ...

Step 50: Redesign the damn thing for the nth time

   ...

Step 100: Reimplement tink.core.Signal for the nth time

Adding 50000 listeners, then removing them:

  • nodejs EventEmitter: ~2s (due to O(N)) removal cost
  • tink.core.Signal: .01s (cancellation tokens cost O(1))

 

 

 

 

 

Other niceties:

  • call stack cap
  • cancellation tokens are 1st class values and null safe
  • signals are 1st class values
  • private dispatch yields better encapsulation

Case study: tink_web

  • ... Step 47321: build a web framework
  • on top of cross platform HTTP abstraction:
    • Server: IncomingRequest -> Future<OutgoingResponse>
    • Client: OutgoingRequest -> Promise<IncomingResponse>
  • "web is a delivery mechanism" - Architecture, the Lost Years
    • focus on modelling a clean interface
      • for server: implement
    • if you annotate for "the HTTP bit" NOW, you get remoting and routing FOR FREE, along with content negotiation, validation and much more!

Case study: coconut

Case study: coconut

Steal from everywhere:

  • Model-View separation (MVC)
  • observable data layer (Rx, knockout, MobX)
  • reactive views (React)

Result:

  • faster and smaller than React, but can be used together with it
  • less mad science than Rx (or Redux for that matter)
  • safer than MobX
  • highly portable (coconut.vdom, coconut.react, coconut.haxeui, coconut.h2d)

Case study: cix

CSS in Haxe ... yay!

  • quite similar to CSS preprocessors
  • can use constants from Haxe code
  • classes and keyframes are scoped
  • possibility for static export
  • full DCE support
  • suitable for libraries
  • faster to install
  • zero config

Haxe is
the
Right Thing

Worse
is
Better

Haxe for Web Developers

AKA: fighting a guerrilla war on three fronts \o/

Business People

  • hard to hire
  • never heard of it
  • high risk
  • benefits unclear

Business
is not our
strength

Compiler Team

  • nobody with skin in the game
  • occasional disdain for the web
  • trivial additions are blocked because "you shouldn't be doing that" or "you can use macros"

Let's talk about inline markup 🙃

People preferring XML to describe UI

  • Microsoft (XAML, JSX)

  • Apple (XIB)

  • Facebook

  • Oracle

  • ...

  • Nicolas (domkit)

  • ...

  • Ian (HaxeUI)

  • ...

  • Juraj (post 2017)

People preferring other DSL to describe UI

  • Apple (SwiftUI)

  • Kotlin

  • people who don't write much UI code

  • Juraj (pre 2013)

People who think support for embedding LaTeX is as important as first class support for UI description markup

  • Nicolas

Other web devs

  • But: where is the hype?
  • Does it support webpack? Modules? does it have generators? async/await? JSX? Arrow functions? Destructuring? ...
  • JS is already natively full stack, why introduce overhead?

Problem:

people suck at making decisions

DX

Made with Slides.com