Skip to content

bartblast/hologram

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Hologram

Hologram is a full-stack isomorphic Elixir web framework that can be used on top of Phoenix.

Inspired by

Hologram was inspired by Elm, Phoenix LiveView, Surface, Svelte, Vue.js and Ruby on Rails.

How it works

Hologram simplifies web app development by breaking it down into basic building blocks: Layouts, Pages, and Components.

Hologram analyzes the content of your Pages, which need to follow certain conventions. Based on this analysis, it decides which code should run on the client (in the web browser) and which should run on the server. Then, it converts the client-side code into JavaScript.

Keeping the state (data) on the client side makes the programming model simpler. With stateless or stateful components, the app becomes more scalable.

In Hologram, code meant for the client is organized into "actions," while code meant for the server is organized into "commands." Actions can trigger commands, and vice versa. Both actions and commands can be directly triggered by user interactions with the web page.

For communication between the client and server, Hologram uses WebSockets. No additional boilerplate code is necessary - Hologram handles the setup automatically.

I want to see some code!

To understand the structure of a Hologram app and view some actual code, take a look at the feature tests app: hologram/test/features

Basic example

defmodule MyPage do
  use Hologram.Page

  route "/my-page-path"
    
  def init(_params, component, _server) do
    put_state(component, :count, 0)
  end

  def template do
    ~H"""
    <div>Count is {@count}</div>
    <button $click={:increment, by: 3}>Increment by</button>
    <Link to={MyOtherPage}>Go to other page</Link>
    """
  end

  def action(:increment, params, component) do
    put_state(component, :count, component.state.count + params.by)
  end

  def command(:save_record, params, server) do
    # Do something on the server, e.g. save a record to the database
  end
end

Selling Points

  • State stays on the client - solving various problems as outlined below:

  • No latency issues arise since most of the code runs immediately on the client. This enables the creation of rich UIs or even games. Currently, with solutions that keep the state on the server (like LiveView), creating rich UIs usually requires multiple servers (in different locations) close to the users. However, latency persists, and response time cannot be guaranteed due to inherent variability. Additionally, some JavaScript or Alpine JS is still necessary to implement more advanced UI functionality. Until someone devises a solution like quantum internet (utilizing entanglement), there are no workarounds for this issue. I'm not sure if this is even technically feasible, though πŸ˜‰

  • Enhanced offline support, addressing scenarios such as internet disconnection or poor signal. With the bulk of code executed on the client, Hologram functions offline for extended periods. This facilitates the development of Progressive Web Apps (PWAs) or mobile apps via WebView, particularly when incorporating mechanisms like LocalStorage.

  • Reduced server RAM usage as the state resides in the browser.

  • Lower CPU utilization since the browser handles most code execution, alleviating server workload.

  • Decreased bandwidth consumption, as only commands necessitate communication with the server, eliminating the need to transmit component diffs for re-rendering.

  • Elimination of state synchronization issues, with the state centralized in the browser and WebSocket communication remaining stateless.

  • Minimal reliance on JS except for interfacing with select third-party scripts or widgets. This can be mitigated through standardized libraries tailored to popular packages, streamlining interoperability.

  • Particularly welcoming to new Elixir converts or novice developers, prioritizing DX and intuitive usability to streamline feature development without excessive technical troubleshooting or writing boilerplate code.

Features

Please note that the "Readme" file is currently undergoing an overhaul, and the "Features" section may not be up to date.

Elixir Syntax

Data Types

Type Status
Atom βœ…
Bitstring βœ…
Float βœ…
Function βœ…
Integer βœ…
List βœ…
Map βœ…
PID βœ…
Tuple βœ…

Control Flow

Expression Status
Case βœ…
Cond βœ…
If βœ…
Unless βœ…
With ❌

Function Calls

Function Type Status
Anonymous Function βœ…
Function Capture βœ…
Local Function βœ…
Remote Function βœ…

Operators

Overridable General Operators
Operator Status
unary + βœ…
unary - βœ…
+ βœ…
- βœ…
* βœ…
/ βœ…
++ βœ…
-- βœ…
and βœ…
&& βœ…
or βœ…
|| βœ…
not βœ…
! βœ…
in βœ…
not in βœ…
@ βœ…
.. βœ…
..// βœ…
<> βœ…
|> βœ…
=~ ❌
** ❌
Special Form Operators
Operator Status
^ βœ…
. βœ…
= βœ…
& βœ…
:: βœ…
Comparison Operators
Operator Status
== βœ…
=== βœ…
!= βœ…
!== βœ…
< βœ…
> βœ…
<= βœ…
>= βœ…
Bitwise Module Operators
Operator Status
&&& ❌
<<< ❌
>>> ❌
||| ❌
Custom and Overriden Operators
Operator Status
custom βœ…
overriden βœ…

Error Handling

Keyword Status
After ❌
Catch ❌
Else ❌
Raise ❌
Rescue ❌
Throw ❌
Try ❌

Guards

Construct Status
Anonymous Function βœ…
Case Expression βœ…
Comprehension Generator ❌
Private Local Function ❌
Public Local Function ❌

Other Syntax

Construct Status
Comprehensions ❌

Misc Features

Feature Status
Regular expressions ❌

Framework Runtime

Core

Feature Status
Actions βœ…
Commands βœ…
Cookies ❌
Session ❌

About

Full stack isomorphic Elixir web framework

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •