

Fun - a new programming language for the realtime web - marcuswestin
http://marcuswest.in/read/fun-intro/
"What if you could build realtime web apps with the same ease as you build static web pages in PHP today? Without long polling, event handling and state synchronization, the engineering complexity of realtime web applications would drop by an order of magnitude. There would be a fundamental shift in the way we build the realtime web. This is the future of Fun."
======
Twisol
Quote - "What if you could build realtime web apps with the same ease as you
build static web pages in PHP today?"

It's interesting how far we've come, no? PHP-based pages were once considered
dynamic.

~~~
Groxx
I'll play devil's advocate:

Building static PHP pages is easy (and is demonstrated in the first block of
code). So easy it's hard to beat by a significant margin, especially for small
projects like this seems geared towards.

Building dynamic - much less real-time - PHP pages is not-so-easy, and
certainly not _that_ easy. At absolute simplest you have to look into
JavaScript as well.

~~~
Twisol
I'll admit I was a bit cryptic with my remark. :D I was considering things
from a server standpoint when I wrote that comment, and from that sandpoint
it's extremely obvious that PHP is dynamic, since the page is constructed
every time.

But after a few minutes I realized that if you look at it from the client's
point of view, the rendered page really is static. It's not always the same
between requests, but once it's rendered, it's not likely to change. So you're
right in that respect!

What I got a kick out of is that my remark could be taken both with and
without its tongue-in-cheek intent. It really _is_ amazing that, once upon a
time, PHP was considered dynamic. And now we want more!

------
necubi
From a cursory reading, this isn't particularly new, even on the web.
Essentially what he's done is implement bindings/key value observing, but with
a new syntax instead of the one we already know (i.e., javascript). On the
desktop Cocoa has done this very well, and on the web Cappuccino and
SproutCore have copied the cocoa approach. There are also more lightweight
libraries that provide binding support without a heavy framework.

~~~
marcuswestin
The difference is the realtime synchronization across all clients. Fun comes
with a complete network stack, ensuring that the state you're viewing is
always up to date. Does that make sense? I actually do think that's a new
value proposition.

~~~
wangwei
Still, creating a new language just for bindings (across all clients) still
doesn't make sense to me. A good javascript library or framework should be
good enough.

~~~
marcuswestin
There's a javascript library under the hood that does just that:
<http://github.com/marcuswestin/fin>

------
seanalltogether
What they are describing is essentially data binding at the language level.
The thing to keep in mind is that "out of sight, out of mind" data binding can
result in very slow code, but it's a fantastic pattern for UI dev.

~~~
marcuswestin
The bottleneck with Fun is going to be the network latency.

Any piece of UI that needs extra care, e.g. a very long list of items, is
implemented in javascript with appropriate lazy rendering.

------
bobbywilson0
This certainly is an interesting idea. It seems to me though that all of your
application logic is jammed into a single file at the presentation layer. This
might suffice for very small apps, and that's fine if it is your goal. I can't
imagine that you just define all of your logic in one file.

How would you go about reusing code? Could you potentially separate out logic
from your template?

I would also like to see how this could be done more unobtrusively. It would
also be good to show what the output html looks like after it is compiled to
html.

~~~
marcuswestin
Absolutely!

You can declare something akin to a function, which takes arguments and emits
HTML. Imagine e.g.

    
    
        let taskTemplate = template(task) {
             <div class="task">
                  <span class="title">task.title</span>
             </div>
        }
    
        for (task in tasks) { taskTemplate(task) }
    

I'm not decided on syntax yet.

You can definitely separate out logic from template this way.

Fun outputs javascript, not HTML - the javascript then builds the DOM.

~~~
m0th87
But it still outputs something that is only consumable by web browsers. It
seems to me like the potential productivity gains you'd get out of Fun would
only be for tightly coupled systems where you're not worried about exposing an
API, and all clients use web browsers.

~~~
narcvs
Web browsers are not so "only" :) pretty good platform to start with if you're
going to pick one

~~~
m0th87
Yes but not a great platform to get locked into. What if tomorrow your client
asks for a native iPhone app?

------
sshumaker_2
Actually, there's a lot more to it than simple 'key/value' binding, depending
on how it's implemented. It allows you to build very live pages that are
driven directly off your data model. Normally, websites build dynamic content
using a templating system on the backend, but live updates need to be done in
a horribly awkward manner using a Javascript builder syntax or manually gluing
together things in JS. This avoids this problem and unifies it into one nice
syntax.

I built a similar language like this powered a site of mine that was actually
in production (well, Alpha) - and it was a huge productivity boost, resulting
in far more interactive pages. (The site never got out of alpha, and never had
designer love, so it's stale, but you can see it at
<http://www.magnifeast.com> \- try entering a los angeles address).

The downsides to this approach are compatibility (most libraries won't work
out of the box), SEO, and performance problems for generating large pages
(particularly in IE).

(BTW: this is a secondary account, I'm normally sshumaker - noprocast rule and
all).

~~~
marcuswestin
Why not open source what you have?

------
asnyder
A similar sort of thing is already possible using the NOLOH PHP Framework
(<http://www.noloh.com>) using its Listener Control. Using a quick example
similar to the post you can simply do something like:
<http://noloh.diffpaste.com/#/691/>. Furthermore, you can specify the various
options, whether it's stream, short-poll, or long-polling.

A video demonstrating it from this past March's Confoo web conference can be
found here:
[http://www.youtube.com/phpframework#p/c/C102458C2FFD8ACF/7/8...](http://www.youtube.com/phpframework#p/c/C102458C2FFD8ACF/7/8r0FR0Dx4zE)

We're also planning to add a more direct syntax in the future so that you can
easily set properties of objects directly to a changing data source without
having to handle the assignment in a controlled callback, which we initially
mandate due to taking the cautious route, thus allowing you to handle for data
and security issues.

Disclaimer: I'm a co-founder of NOLOH

~~~
Keyframe
Looks rather interesting. I'm not sure I follow licensing options. So it's a
framework one cannot use for free in commercial projects? Also, are there any
performance reviews of it and is that "Loading..." configurable or hardwired?
Thanks.

edit: I may be out of the loop a bit, but how does google and other spiders
crawl pages like that?

~~~
asnyder
Loading is configurable, it's just an object like anything else. See
LoadIndicator <http://dev.noloh.com/#/api/WebPage/LoadIndicator/>.

We're sorry about the confusion regarding licensing. Essentially free for
anything non-commercial (open-source, educational, non-profit), and
development. We offer free hosted sandboxes, in addition to free downloads for
developing.

Essentially, you only pay when you go live with a commercial product, and even
then we offer affordable options. There will be a comprehensive performance
review in an upcoming issue of php|architect magazine. Since the framework is
built from the ground-up to be lightweight and on-demand the result is
considerable. You can read more about that here:
[http://www.noloh.com/#/home/&expanded=performance](http://www.noloh.com/#/home/&expanded=performance).

In regards to the spidering question, see:
<http://dev.noloh.com/#/articles/Search-Engine-Friendly/>.

You can also read a comprehensive article in this past May's cover story in
php|architect, <http://www.phparch.com/magazine/2010/may/>.

~~~
marcuswestin
Fun is MIT licensed :)

[http://github.com/marcuswestin/fun/commit/05870f3f54fda43090...](http://github.com/marcuswestin/fun/commit/05870f3f54fda430909dddc9ee47311987e5410b)

~~~
asnyder
We feel that NOLOH is significantly advanced to warrant a small fee for
commercial purposes. As you can see from my previous post we offer several
free license options, including free licenses for open-source projects.

Fortunately/Unfortunately (depending on your viewpoint), we live in a
capitalistic society and need to recoup some of the costs associated with our
team's development over the past six years.

Furthermore, we open-source every new module and component on our github
either through an MIT or BSD license. We've even taken the unprecedented step
of integrating github into our site as can be read here:
[http://dev.noloh.com/#/blog/2010/06/30/demos-demos-
everywher...](http://dev.noloh.com/#/blog/2010/06/30/demos-demos-everywhere/).

Like Google, we open source anything non-related to the NOLOH core. Similarly
, they don't release the details or the code to their search engine. Also,
we're working on legalize that would open source the core if anything were to
happen to us.

~~~
jacquesm
Your comparison with Google is flawed, google does not ship the core software
to third parties for integration in to their product, it's purely a service.
So google not shipping their core as open source has a different impact on
their users than NOLOH releasing the source of their core would have on
theirs.

~~~
asnyder
So if we were to create a WebApp then it's perfectly okay for it to be closed,
but as soon as we decide to write tools, then it has to be open?

As was mentioned in the previous post, we try our best to open source anything
non-central to the core. We also try our best to document everything within
the core and provide you the ability to extend and override anything, thus
reducing any real need for the source to be open. We're even working on
legalese to ensure that the source would be opened in any catastrophic event
to the company. What else can we do?

Whether or not NOLOH is open has the same amount of impact on our users. If
they have an issue they report it and we fix it, furthermore, they could
override any functionality in the meantime if they so desired.

Essentially, it seems that you're arguing that nobody is allowed to charge for
development tools anymore. We should just open it up, and donate all that
time, money and R&D. If we want to eat we should be creating WebApps, rather
than creating the tools to help you make yours.

~~~
jacquesm
> So if we were to create a WebApp then it's perfectly okay for it to be
> closed, but as soon as we decide to write tools, then it has to be open?

Ideally, yes.

> As was mentioned in the previous post, we try our best to open source
> anything non-central to the core.

Those parts are not relevant to the continuity of businesses and those parts
will not benefit from being open from my point of view (many eyes, user
contributions) as the core would.

> We also try our best to document everything within the core and provide you
> the ability to extend and override anything, thus reducing any real need for
> the source to be open.

For those parts where you decide that is the case.

> We're even working on legalese to ensure that the source would be opened in
> any catastrophic event to the company. What else can we do?

Open it up. Live dangerously. Look at where it took MySQL.

> Whether or not NOLOH is open has the same amount of impact on our users. If
> they have an issue they report it and we fix it, furthermore, they could
> override any functionality in the meantime if they so desired.

That's good.

> Essentially, it seems that you're arguing that nobody is allowed to charge
> for development tools anymore.

No, I never said that. _You_ can keep it closed and charge as much as you
want, but _I_ would _like_ it to be open source. Think of it as potential user
feedback.

> We should just open it up, and donate all that time, money and R&D.

...

> If we want to eat we should be creating WebApps, rather than creating the
> tools to help you make yours.

Look, I understand exactly where you're coming from. I used to write licensed
software for a living (the first version of the webcam software was a nice
example, it did several hundred K in turnover annually at some point) but I've
seen the writing on the wall and closed source is not going to be around
forever for code such as this. Right now you have first mover advantage, you
have a very solid codebase that you have put your time and effort in and if
you can roll out fast enough and wide enough you can cement your position for
the next 10 years or more.

By open sourcing it you cut off the route where some other group of smart guys
with spare time on their hands looks at what NOLOH does and re-implements it.
You don't create lock-in with tools the way Microsoft could do it with office,
we're not talking about end-users, we're talking about developers here.

They already understand the way their job is done and to a very large extent
that means that they've learned the downside of relying on closed source. And
as a result plenty of them now have a very simple policy: Toolchain to create
my product has to be open. Especially on the BSD and linux platforms, less so
on Mac and Windows.

The stuff you've built is aimed squarely at that BSD and Linux fraction of the
market, the portion where the resistance against closed source is going to be
the strongest, you're building on top of PHP which itself is an open source
product.

So the whole chain from OS, language, probably the db and the primary language
is open, then you insert a DSL or middleware (however you want that to be
classed) and you undo all that.

So you'll find some resistance to your policy. But I find the concepts
embodied in NOLOH interesting enough that I've signed up for a trial license,
so who knows, I might even overcome my dislike for your licensing policies.

Note that MySQL made some very good money by dual licensing their product and
eventually a huge exit. It's not impossible.

~~~
asnyder
Thank you for signing up for a trial license, and thank you for the mention in
your recent blog post.

It's interesting you chose MySQL as an example, since they in fact didn't
open-source everything, the Enterprise stuff as I recall was/is still closed.

Don't get me wrong, we would open source the core if we could, the problem we
have with that is that we're not large enough to fend off a competing
framework from implementing or cherry picking our technology, whether it's a
direct copy, or a derivation. Once that's done, what's the incentive for
anyone to try NOLOH? The more established tool may not feel the same, but on a
comparison grid they would still be able to check off whatever feature we
provide.

They may not have the vision, and the experience won't be the same, but for
many users that won't matter.

~~~
jacquesm
I can see several possible routes out of that swamp:

\- the ransom model

\- find an investor that is able to fend off a competing framework in the
marketplace (drupal has raised a fair amount of money on top of an open
framework)

\- take the plunge and drop licensing as your income stream in favor of
another model

The reason why I picked MySQL is because I think they're the poster child for
the situation you're in.

At this point you're trying to sell bibles to the satanists, you are aiming a
closed source product squarely at the most die hard fanatic open source
portion of the market.

The money is in the services, the (enterprise) support and the fame & glory
related income (speaking engagements, that sort of thing), and if you want an
enterprise version that technically should be classed as a freemium model.

The road you're on right now I can see enough frustration building on both
sides of the divide (wannabe NOLOH users that insist on open source and
yourselves) that at some point someone might just get up and build it. Then
you've got even bigger problems. Open source is an ecosystem, if you want to
play around in that ecosystem (and that's where you are) you can try to adapt
to the ecosystem or you can - by virtue of the quality of your product and
your unique value proposition - try to adapt the ecosystem to you.

Entities that resist the general trends and conventions in an ecosystem are
usually called food ;)

I'm not aware of any company that has successfully managed to do that outside
of the CAD/CAM world (varicad, specifically) and even that is not strictly
speaking a developer tool.

If NOLOH is as great as it seems to be then the open source route would
probably be the more profitable one in the longer term, even if in the shorter
term it would mean a complete loss of license income. The 'ransom' model might
get you over that hump.

------
mgrouchy
Is it just me or does this seem like a "Fun" way to code up an unmaintainable
mess?

Some of the ideas such as the state synchronization stuff is neat, but would
probably be better suited as part of another framework/template language.

~~~
marcuswestin
Totally - remains to be seen!

Someone should take the underlying realtime datastore
(<http://github.com/marcuswestin/fin>) and bundle it with mustache or
<angular/>!

~~~
gregwebs
<http://github.com/ahe/choco> bundles a different js datastore (js-model) with
sammy and has mustache support

~~~
marcuswestin
Nice - the relevant fin API used under the hood by Fun is dead simple:

    
    
        fin.set(id, property, value)
        fin.observe(id, property, function callback(mutation){})
    

Would be rockin to see if we could hook up fin to js-model!

------
Jach
Reminds me of how Flex does data binding, but with the added feature of
blurring server and client. I don't think I like this idea, and I'm not sure
it would save me code or headache in the long run... Still neat though.

------
jackowayed
I notice that you haven't technically OSSed it yet (not released under any
license). Is this just an oversight?

~~~
marcuswestin
Sorry about that - fixed in
[http://github.com/marcuswestin/fun/commit/05870f3f54fda43090...](http://github.com/marcuswestin/fun/commit/05870f3f54fda430909dddc9ee47311987e5410b)

------
thomasfl
The "Fun" language looks a lot like Ruby and the Camping web framework with
inline Markaby templates created by Why (the lucky stiff):
<http://camping.rubyforge.org/>

It's 4k of pure ruby art. Check it out.

------
zokier
"To bind an element that reflects a piece of state to a piece of data, all you
do is set data attribute in the element."

Reminds me bit of register globals. And generally blurring the line between
clientside and serverside processing feels bit scary.

------
enduser
For those of us who gravitate toward the code examples instead of the English
it would be more clear to leave out the PHP example at the very beginning.
Took me a moment to figure out what was going on.

~~~
marcuswestin
Good feedback! I had the time to add a simple

    
    
        // PHP code
    

and

    
    
        // Fun code
    

comments at the top of the code examples. Not great but hopefully helpful :)
This was meant to be a high-level intro. I'll be diving into explaining the
nitty gritty of the language next month.

------
wazoox
Jemplate, anyone? This was already done.

~~~
marcuswestin
Jemplate does not do the realtime stat synchronization across browsers I don't
think

------
parisba
This is really awesome!

------
AlphaPlus
Sounds fun

