Skip to content

web - EmScripten Merges Its Speedy "Fastcomp" Backend

[...]
Fastcomp is the name of EmScripten's new LLVM C++ back-end. Fastcomp lives outside of the LLVM tree (along with some other EmScripten-designed LLVM patches) but aims to provide noticeable benefits over its original compiler back-end.

The new Fastcomp compiler core/back-end is more streamlined, tuned around producing ASM.js code, is much faster (around four times faster), uses less system memory, and has other improvements too. The JavaScript generated by Fastcomp is also slated to be better than its original compiler core. The downside to this work though is that this LLVM code is out-of-tree and doesn't work with a stock build of LLVM for right now.
[...]

source

duetto - write client-server web apps in a single c++ codebase

Duetto is fully compatible with almost all C and C++ 11 code. You just need to add some tags to tell duetto if you want your methods compiled for the server or for the client. Everything else (including client to server and server to client remote procedure call, serialization and deserialization, etc.) will work automagically! The duetto compiler is based on the proven and robust LLVM stack.

source

So the current version is 0.9.3., so they are near the magic first stable release.
If you take a look into the example section, you get the picture pretty fast. A wiki page is also available. What its left to need, is some spare time :-).

FrOSCon - Marring Fron With Back End

By Bastian Hofmann and Volker Dusch The talk is about application architecture from the code site. Both are from ResearchGate Speak available on speakersdeck

What You Want

  • good code review
  • rapid development (even with big teams)
  • handle large code bases
  • frameworks to the rescue

Most Framework Are Dealing With Backend Or Frontend

  • backend
    • symfony
    • zend framework
  • frontend
    • backbone.js
    • jQuery
    • ExtJS

Frameworks Out There To Join Both Worlds

How To Achieve The Goal

  • incremental refactoring (take a look to flight)
  • separate your code into components
    • clean interface
    • clean architecture
    • small teams can work on that

How Reasearchgate Have Done It

Classicla Webapplication Architecture

  • loadbalancer
  • webservers
  • database
    • pgsql
    • memcached
    • mongodb
  • services (rest services)

Webserver

  • php templates
  • lazy db queries in view
  • yui
  • duplicated code

We Could Do It Better

  • try to compose your page out of containers
    • every component has to be self contained
    • can be addressed and rendered separately (by pure html response or json/xml data that is rendered by javascript on the client)
    • javascript is part of the component (easy up refactoring)
  • initial page request is returning a simple html page as response that is triggering a lot of ajax calls
  • if ajax request returns a ok, the return contains the updated data or handles the error (hint, on the backend, a "read from master" flag is added to retrieve the most accurate data without running into master/slave replication problems)
  • share code between server and client
  • templates, validation, entities
  • create "a widget"
    • php controller (providing data)
    • ...
  • do not fetch data directly (because it is painfully slow)
  • require stuff (search for "evolution of code design at facebook" at infoq)
    • fetch requirements in a preparing step
    • batch requirements by calling resolvers
    • resolvers talks with services (multi-GET)
    • services calls connector interface (databases for example)
    • fetching data from connector
    • distribute back all the fetched data
  • entity requirement
  • service requirement
  • request cache
  • Multi-Get (get multiple data via one request for fetching a lot of data)
  • requirement vs. optional
    • optional, template will be rendered without that data
  • data dependencies within a widget by using callbacks (to create a dependencies and dataload workflow)
  • php 5.5 generators by using yield
  • data dependecies between widgets by using data requirements (fetched from the require stuff above)
  • looks like this is complicated to debug by using symfony debugging tools (for example ;-))
  • rendering (by using mustache)
    • [x]html
    • json
    • v8js for rendering templates on the server (rendering mustache templates is faster in javascript then in php) and to provide a single place to render templates (cool!)
    • use models in javascript to stop messings things up
  • enables developers to only focus on their components
    • single place for refactoring
    • moving ugly code to one point
  • easies up testing (also with faked data)
  • error handling is simplified
    • remove component from the view
    • try to rerender it later
    • display a generic component
  • a/b testing is easied up (removing "long hanging fruites" - that just made my date :-D))
    • create multiple components and simple render then via a/b testing on the frontend
    • read bandit algorithm on untyped
  • by usgin "" you can use varnish to speed up the page
  • easy reusing of components ("take that button and move it or use to somewhere else")
  • mark components to load them asynchronous
  • use "placeholder" with "placeholder data" for search engines
  • try to use BigPipe (published by facebook)
    • compute as much informations as needed (like navigation) and then flush this to the client
    • render and flush some javascript logic
    • start computing the first body (kind of heavy work) that holds javascript logic and data to replace rendered and flushed content from the top
    • repeat that until you have finished creating the initial datas
    • send the final flush with the html end tag
  • fast changes on the frontend by replaceing only the components that have to be updated and use javascript push to change the url

web - An ARM emulator written in JavaScript

Arm-js is an ARM emulator written in Javascript. It emulates ARMv7-A and some peripherals of Versatile Express. It can boot Linux 3.6.1 and run busybox processes.

Get Started

1. Download the source code 1. git clone git://github.com/ozaki-r/arm-js.git 2. cd arm-js/ 3. git submodule init 4. git submodule update 2. Execute ruby misc/simple-http-server.rb on terminal 3. Access http://localhost:8080/arm-js.html 4. Push Boot button at the top-left corner to start the emulator

Source

Well, what can i say. Because of freaky projects like that, i started to like javascript more and more :-D.