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

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.

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!

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

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.

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) }

You can definitely separate out logic from template this way.

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

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).

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...

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

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

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.

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/.

The truth of the matter is that unfortunately, our competitive advantage lies within our code and the significant R&D we've done over the years. We're also not at the stage where we could fend off a larger more well known framework from integrating our technology into their core if we did open it.

Many of our users feel that NOLOH easily pays for itself in its first day of use. We also provide unparalleled development support in addition to constant updates and new features.

I'm always surprised by those that will hem and haw over something that's not open-source. We spent the past six years of our lives and significant financial resources developing the technology.

As stated in a comment below, we open-source everything not related to the core, and are even working on legalese to ensure that if anything happens to us, the core would be opened.

My personal opinion is that if you value your time NOLOH is definitely a great tool to have in your development toolbox. I personally wouldn't do any web development without it.

That said, can you please not turn a post about Fun into a marketing platform for NOLOH? Fun may be fun, but your elevator pitch definitely isn't.

Since you just created your HN account you should know that HN is more about discussion than anything else.

I'm the first one that initially doesn't care if the tool is right. It's just something weird about web middlewares. Maybe we got spoiled by the abundance of good free solutions. I'd never reason about game engine middleware for example.

You've put in a lot of hard work and I hope it pays you off. Good luck!

http://github.com/marcuswestin/fun/commit/05870f3f54fda43090...

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....

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.

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.

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.

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.

- 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.

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.

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

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

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

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

    // PHP code

    // Fun code