Introducing the Famous Framework

We’re excited to announce that today we’re releasing a public alpha of our Framework open source, under the MIT license.

“Famous Framework,” you ask? “Didn’t you just release Famous in May?” Good question! In May we released our Engine, and today we’re releasing our Framework. Together, they are Famous.

We learned quite a bit from our initial release of Famous in April 2014, plus our subsequent year of developing Mixed Mode (now called the Engine). One lesson was that with a mission as ambitious as ours—to empower everyone to create beautiful experiences for any device—creating one library that tries to be ‘everything’ isn’t a tractable approach. In other words, the first version of our render engine was focused on too many goals: capabilities, performance, usability, extensibility, and approachability, to name a few.

This time around, we drew a line in the sand and chose to divide the responsibilities and conquer: the Engine layer is focused on capabilities and performance, i.e. “The Machine.” The Framework leverages the capabilities of the Engine but is focused on reusability, consistency, and integration with other technologies, collectively: “The User.”

For good measure, I’ll clarify again: our release today is an public alpha for the Famous Framework. Following is an introduction of the goals and design of the framework, but be aware that not every goal has yet been fully met, and we still expect to have some shifting ground as we learn from and respond to early user feedback. If this kind of disclaimer excites you, you are exactly who we’d like to have jamming with us today. If this kind of disclaimer makes you cautious, we invite you to keep an eye on the Famous Framework as it matures.


Let’s look at the goals of Framework in a bit more detail:

Goal: Component Reusability

Any component created by any developer should expose a consistent, discoverable interface that allows it to work predictably with any other component. We’ve driven our design around a “black box” model, where each component strictly isolates its own state—you can think of a component as an IC chip, a literal black box that has a clear “inside” and “outside,” with a standardized interface.

Integrated Circuit chips, our inspiration for “black box” components. Credit: Wikipedia, under Creative Commons

What’s more, every component is defined as a tree of other components, which are each defined as trees of other components, and each one can be reused inside yet other components—we like to joke about this reusability and composability of components as “turtles all the way down.”

Another analogue is a “Lego block”—Legos can have a whole variety of looks, feels, and functions, but they all snap together thanks to consistent interfaces. With Legos, you can put a pirate head on a princess body and snap it onto a space ship. In Framework, you can attach a data adapter to a scroll view and drop that into a header-footer layout, each as a single HTML tag. You can easily swap the pirate head for a goblin head just as you can easily swap the scroll view for a grid layout.

For example:


Note: Our full set of prebuilt layouts and components is still under development, but part of why we’re releasing Framework in public alpha is to give everyone an opportunity to create. We are consistently impressed and humbled by what our community creates with Famous, and we believe a solid foundation and ecosystem of reusable components will empower everyone to create incredible UIs incredibly fast.

Goal: Consistency

How do you build a large or complex project with Famous? Or with JavaScript in general? As teams and projects grow and change, software consistency becomes increasingly important for keeping pain low and productivity high. Code style standards can help, but JavaScript simply offers so many ways to approach any problem that it’s practically impossible to maintain consistency without some sort of enforcement at a framework level.

Breaking a large project into a number of consistent, predictable components with isolated responsibilities is a well demonstrated way to build software at scale. Enabling this consistency inside both Famous and JavaScript is a goal of Framework.

That said, there are several world-class frameworks and libraries out there in the Web ecosystem. We expect that some developers will choose to use Framework to build applications from start to finish, and many will choose to use it alongside other libraries. In both cases, it should be clean, consistent, and obvious to the developer how and where to create, edit, and configure Framework code. Importantly, the Framework shouldn’t get in the way of developers creating projects of any size, be they simple ads, reusable widgets, or full-on native/web applications.

Goal: Ease of Integration

“How do I use Famous within my existing application?” This is a tricky question. In the simplest case, you give a div to Famous, and it renders inside that div. This model is comparable to Flash, and it works just fine for applet-like, isolated experiences. What about when you want to go a level deeper, though? What if you want to use Famous with Angular’s data-binding? Or Meteor’s templating system? Or React’s component model? The Flash model of completely isolated applets doesn’t work when you want to bring the full experience of Famous together with the function of these other tools.

Until today, this has left developers with limited options:

  1. “Either-or” — Either you use Famous and build an app from scratch, or you use other tools like React, Meteor, etc.
  2. “Build an integration” — If you want to use Famous seamlessly with Angular, you must build an extensive integration library that hooks together every piece of each API. (example:
  3. “Isolate the experience” — i.e. go with the “Flash” model of applet-like experiences, isolating the rich experience of Famous from the rest of your application.

None of these options is ideal. Fortunately, we can do better. This is one of the goals of Framework.

How? The key is to build not only on top of technical web standards, which is what the Engine does, but also web authoring standards. Ultimately, using Famous should be as seamless and simple as using a div. You can include it, size it, move it, listen to events on it, hide it, pass content into it, query it with selectors, and even style it and bind data to it with your framework of choice—just like you do with a div. Abiding by this interface gains us foundational support from every standard library/framework out there.

For those familiar with AngularJS, here’s an example of how simple it should be to include a Famous component inside of an Angular app:

I'm inside a Famous component, and {{someAngularVariable}} ...

Or with jQuery:

$( ".inner" )
    .append( “” )
    .on(‘click’, function(){alert(‘click works on this component!’)});

In other words: good fences make good neighbors. Let Angular be Angular, let React be React, and let Famous be Famous. Rather than hooking up each API of each library wire by wire, by going one level deeper and integrating with HTML, DOM, and CSS itself, 95%+ of the effort of integrating with each of these technologies is already solved. This allows each tool to shine at what it does and allows the developer to use the best tool for the job—and it lets everyone use Famous in any application, on any device, pain-free!

Note that at our public alpha stage we haven’t yet finished all of the features of this “one integration to support them all,” but we’ve designed from the ground up with this goal in mind—e.g. by using the standard DOM event pipeline for Framework events and using HTML as the language for authoring the render tree. This means that the bulk of this functionality is already in place.


Addressing all of these goals within the constraints and standards of the Web is an ambitious charge requiring thoughtful design. So, we pooled inspiration from existing, successful technologies along with our experiences with our previous products in order to come up with the design for our Framework.


Game Engines: Given that the Famous Engine is modeled after the capabilities of modern game engines, it made sense to start by looking at first-class game engines like Unity3d and Unreal Engine. How do these tools enable building richly interactive applications and interfaces? Two recurring patterns are:

  1. Component-based application structures and
  2. Data-driven architectures that prefer dealing with streams of data rather than procedural manipulation of state.

We designed our Framework around both of these principles: components are first-class citizens. Components are also modeled after finite state machines (a pattern common in game engines,) which map streams of data into application behavior. This keeps logic clean and localized, even as applications grow in complexity.

Web Frameworks: Given that we’re building a web framework, it made sense to look at how other folks approach similar problems. React’s Flux architecture and AngularJS both inspired the design of our Framework in different ways.

Flux (React) has championed the idea of a “unidirectional data-flow,” i.e. dealing with streams of data in a consistent, limited-side-effects way, using functional programming patterns. Why does this matter? Simply enough, it keeps application complexity low and encourages component reusability. Check and check—these are both traits that we need in our Framework.

Though not a web framework, we took quite a bit of inspiration from Haskell, a functional programming language that uses monads as a way to handle state changes or side effects like user input. The way our Framework exposes State values as data streams into Behaviors is directly modeled after Haskell’s monads. We strived, though, to keep the API familiar and comfortable to web developers. In other words, although our approach is modeled after monads, most developers should never have to think directly about the word or concept.

AngularJS is the most popular MVC-ish JavaScript framework in the community today. It brought some game-changing ideas to the JavaScript landscape, and several of those ideas have been adapted into the design of our Framework. For example, anyone coming from an Angular background should see same familiarity to the ‘flavor’ of the API, notably aesthetics and naming conventions.

Another similarity to Angular is our use of dependency injection. Though not common in JavaScript, dependency injection is more common in statically typed languages and enterprise software settings. Angular uses it as a tool for scaling applications and easily unit-testing code, plus as a way to manage reusable logic/state (Angular Services.) Check: we want this same level of rich unit-testability.

Web Languages: When tasked with building a framework for use on top of web languages, we figured we should study the semantics and patterns of those languages, and then to celebrate them in the design of the framework.

Consider HTML: although JSON is a more comfortable format for many developers to use for tree data structures, one thing HTML does better than JSON hands-down is describe the hierarchy of a user interface. That’s what it was created for! Even though Famous doesn’t use

s and s to represent its UI hierarchy—it uses a virtual render tree instead—it turns out that using HTML as the language for authoring the tree is elegant, familiar, and naturally compatible with other web tools. Why reinvent the wheel?

Now consider JavaScript: it’s a language that many people love to hate. It does have its fair share of quirks and challenges—but it’s also an extremely powerful language if harnessed properly. It has declarative aspects like JSON. It has functional aspects, to the point of being arguably more Lisp-like than procedural. Nonetheless, it has obvious stateful and procedural aspects, and most people who pick up the language for the first time will use it procedurally, similarly to Java or C++. How can we celebrate each of these powerful aspects of this unique language?


What we came up with is Behavior Event State Tree. BEST is a new architectural pattern for building reusable, interchangeable components that behave predictably both in isolation and at scale. Our Framework is an implementation of BEST.

You can think of BEST as an event-driven evolution of MVC. MVC provides a Model for managing state and persistence, a View for presenting state to the user and gathering input, and a Controller for brokering communication and logic between the Model and View. Visually:

MVC has been used for decades to create software in all sorts of languages for all sorts of uses. Though MVC has been used to great success in many projects over the years, it also bears many well recognized pain points 0 1 2 3 4.

Many of those pain points center around the Controller, the oft-unkempt middleman of MVC. A common scenario in MVC is for state to be brought into the Controller from the Model, where it is locally duplicated and then sent off to the View. The user may manipulate that state (say, by filling out a form), which is then submitted back into the Controller. The Controller may store yet another copy of that state and/or possibly affect other pieces of application state as a result (e.g. log in a user; add an order to the cart). The Controller may or may not send that state back to the Model for persistence—it depends on what the application is trying to do.

Throw 20 churning developers and 100 evolving features at this application and just imagine how the code unfolds. Or better yet, don’t imagine: just look at any battle-worn MVC codebase. The Controller often bears the brunt of the inevitable complexity—synchronizing and managing each different version of state and their interdependencies across several features, plus shuttling those states off to the Model and the View gets complex quickly.

Thus the Controller is the key place where BEST diverges from MVC. In fact, you can think of BEST as an event-driven variant of MVC that breaks out the output/input responsibilities of the Controller into separate concerns: Behaviors and Events.


Let’s walk through the pieces of BEST with a simple example.

Tree: It’s simplest to start with the Tree, as it should be very familiar and straight-forward. It’s the hierarchy of your component, and it’s written in HTML. This is one of the places where we get to celebrate the semantics of web languages. HTML is great for expressing UI hierarchies, and it’s already used pretty universally across the web for exactly that purpose.

Here’s an example Tree, which blends into using vanilla HTML (a div):

tree: `  

The Tree is simply a logic-free skeleton of your UI.

Events: Events are where you assemble the nuts and bolts of your application logic. For example, ‘On click, increment x by 1,’ or ‘On data load, update array of Tweets to be the list from the server, and set isLoading to false.’ Events are where we celebrate the procedural side of JavaScript.

All manipulation of application State occurs inside Event handlers, and Event handlers can manually kick off other Events. They’re really similar to methods in an object-oriented system, except these handlers are triggered by events rather than direct method calls.

Events are attached to elements of the Tree utilizing another familiar piece of JavaScript and CSS: selectors. Selectors allow Events and the Tree to be maintained as separate concerns, just like they allow CSS and HTML to be maintained as separate concerns in traditional web development.

In the example of the Tree above, the selector ‘#square’ allows us to target the node with that id, and we can declare Events that should be attached to it like this:

events: {  
    '#square': {
        'click': function($state) {
            $state.set('numberOfClicks', 1 + $state.get('numberOfClicks'));

Component state is managed through the StateManager, which is what that $state variable is referencing in this example. Why a StateManager? In part, because it allows us to maintain yet another separation of concerns, between our Events and our State.

State: State is simply enough the state — internal data and settings — of your component. Unlike an MVC Model, which generally has oodles of getter/setter logic for things like data retrieval and persistence, a BEST State is strictly declarative and logic-free. In other words, the State of a component can always be losslessly serialized and deserialized as JSON. This is where we celebrate the stateful and declarative sides of JavaScript.

states: {  
    numberOfClicks: 0

In the Event example above, when we incremented the numberOfClicks variable, it updates the same numberOfClicks variable whose default value 0 was declared here.

Behaviors: Behaviors complete the cycle, connecting to both States and the Tree. Behaviors are functions, in the sense of ‘functional programming’—this is where our Haskell inspiration shines through. They’re not just any functions, though—they’re “functions of States,” in the sense that a function f(x) is a “function of x”. We use dependency injection to match State names to parameters of Behavior functions—the State numberOfStates gets injected into any Behavior function that lists is as a parameter, like function(numberOfStates).

Just like Events, Behaviors are attached to elements of the Tree using selectors. Behaviors are even more CSS-like than Events, though. One way to think of Behaviors is as “functional CSS,” and indeed this is where we celebrate the functional side of JavaScript. For example:

behaviors: {  
    '#square': {
        'rotation-z': function(numberOfClicks) {
            return numberOfClicks * Math.PI / 2;
    'div' : {
        'background-color': 'red’,
        'text-content': function(numberOfClicks){
            return numberOfClicks + " clicks!";

In this example, before the square has been clicked, the square’s rotation-z evaluates to 0 * Math.PI / 2, or 0. The text-content of the div is “0 clicks!” When the user clicks the element ‘#square”, the Event handler “click” is fired. That handler updates the State numberOfClicks, which automatically causes both behavior functions to be re-evaluated. #square’s rotation-z will then reactively update to 1 * Math.PI / 2, and the content of the div will reactively update to “1 clicks!” And our cycle is complete!

Learn More

Hopefully this was enough to start to get you as excited about the possibilities of the Famous Framework as we are. We’ve got plenty of work ahead, but our open source release today means that we can work toward our goals together as a community.

We have a number of resources available for you to learn more about Framework. Check out the GitHub repo and explore the code—including many examples—or join our Slack channel and chat with our team and community directly. We hope to see you around!

Original URL:

Original article

Mattermost: Open-source, on-premises, Slack alternative


We’re a YC-backed indie video game company releasing an open source alternative to Slack.

It’s called “Mattermost” and it’s the team communication service our company’s run on since last year. Like Slack, you can send messages and files across channels, get notifications on unreads and mentions, and search history–all from your PC or smartphone.

Unlike Slack, Mattermost is open source. You can download the code, run it on your own servers, and modify it as you wish.

We built Mattermost to solve our own problems. We open-sourced it because so many of our friends wanted to use our software for different reasons:

Mattermost messaging, file sharing and commenting
Mattermost messaging, file sharing and commenting

Modern messaging
Teams who can’t use SaaS rely on cryptic, decades-old technologies. As an example, the US Army uses mIRC to order missile strikes–not a place to miss notifications! Mattermost modernizes communications when SaaS isn’t an option.

Complete control
SaaS providers can’t keep up with everyone’s feature requests. Some teams need offline support, others want channel folders, others email integration. Mattermost lets you build whatever you need–and keep your data on-premises.

Teams suffer when SaaS companies lose focus. Since it’s open source, Mattermost can endure through its community. If quality declines, anyone can fork the code and take stewardship.

We’re continuing to develop Mattermost–an iOS app is already in the works–and as as our features and community increase we plan to offer commercial enterprise support (including customized guidance and deployment advisory) and later an advanced enterprise version with Fortune 500 security features and environmental certifications.

We’re so glad to share this with you, and look forward to your comments, feature requests, votes and contributions. If you find bugs, please let us know in the issue tracker. If you like this project, please tweet about us at @mattermosthq.

To learn more:

Thank you so much for reading about our new product,

Warmest regards,

The Mattermost Team (within “SpinPunch”, the YC-backed video game company)

BONUS: Sign-up for the Mattermost Announcements mailing list and we’ll send you an upcoming article on How to integrate over 500 applications to Mattermost–including Jira, Github and Twitter–using Zapier integration.

Many thanks to GitLab, RethinkDB, Automattic and AeroFS for the help and advice as we prepared to release this project.

Original URL:

Original article

Lenovo Announces a $130 Windows PC in a Stick

If you’ve ever wanted to plug a Windows machine into your TV for a little hot and heavy Excel slinging, you’re in luck. Lenovo has just announced a $130 stick, the Ideacenter Stick 300, that connects to any display via HDMI.

These single-stick computers are nothing new but this one has an Intel Baytrail Z3735F CPU, 2GB of RAM, and up to 32GB of storage. It also has a built-in speaker and SD Card reader and runs Windows 8.1.

Why would you need this? Well you could simply stick a Windows PC onto your TV and play a little Steam or you could us it as a kiosk computer for public use. You could also carry your entire computer from hotel room to hotel room, plugging it in as needed and connecting a keyboard and mouse via Bluetooth. The possibilities, as they say, are endless. There is no release date but I’d love to see this little dongle in action.

via Neowin

Original URL:

Original article

How to benchmark your GPU on Linux

Linux is not famous for its gaming abilities and possibilities, and it is only natural that there aren’t many GPU benchmarking tools available with which users can test their graphics hardware. There are however some benchmarking suites that can help you determine the various aspects of your GPU performance with precision. In this tutorial I will show you GLX-Gears, GL Mark 2 and the benchmarks from “Unigine Benchmark Products”.

Original URL:

Original article

As Slack Hits 1M Daily Users And 900K Integration Installs, It Hires April Underwood As Head Of Platform

slack-large Workplace collaboration platform Slack has been a runaway success since opening for business just over a year ago: the company co-founded and led by Flickr founder Stewart Butterfield now has 1.1 million daily active users, with 300,000 of them paying for premium tiers of the service bringing in annual recurring revenue of $25 million. Now, Slack is stepping up its game and getting more… Read More

Original URL:

Original article

Combine OneNote and Outlook for a Powerful Project Management System

Outlook’s tasks feature is pretty simple and basic. If you want to power up Outlook tasks with organization and room for details, integrate the awesome note-taking tool OneNote with Outlook.

Read more…

Original URL:

Original article

Telegram’s New Platform Lets Developers Create Smart Message Bots With Multiple Uses

The_Bots_and_the_Bees_screenshot A few years ago a slightly forgotten (a least in Western eyes) mobile messaging app called Nimbuzz launched little ‘chat bots’ on its platform. The bots could tell you about the weather or your horoscope. Although the platform was eventually sold, it became clear to me at that point how powerful the potential was for this idea. Today, a new messaging war is being waged, whether it… Read More

Original URL:

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: