ANNOUNCEMENT: Apostrophe 2, node.js, and the future of Apostrophe 1.5

[Tom Boutell]

We know folks have been waiting for an announcement about Apostrophe
2. And we don't want to keep you in the dark.

So here's the big news:

Apostrophe 2 will be built on node.js.

OK, now the FAQ:

* "What is node.js?" node.js, for those who don't already know, is a
powerful framework for developing server-side applications that run on
the open source v8 JavaScript engine developed for Chrome. node.js is
event-driven, allowing for startling levels of performance in web
applications, yet the ability to use JavaScript closures allows for
elegant and maintainable code.

* "What happens to my existing sites?" Only good things! We are still
building Apostrophe 1.5 projects, and even new plugins. We'll be
supporting Apostrophe 1.5 for a long time to come, much as the Symfony
community continues to support Symfony 1.4. And we'll be maintaining
the existing trac documentation and svn repository for Apostrophe 1.5.
Code and documentation for Apostrophe 2 will live on github.

* "Not PHP? Not Symfony 2?" That's correct. Symfony 2 is a great
framework that does a lot to make PHP better. But node.js and the
JavaScript language are a better fit for us. node.js has taken our
office by storm, and for very good reason. The performance,
maintainability, and sheer power of node.js development is a value
proposition we can't ignore. Our clients love the responsiveness of
node.js applications. And every JavaScript developer - which probably
includes just about all of you - is already a node.js developer
waiting to happen.

* "Does this mean I can use one language for the browser and the
server?" Yep! If you're familiar with jQuery at all, you'll find
yourself right at home with node's callback-driven style. Limiting the
cognitive shift required to move back and forth between browser and
server code is a big win, especially as you can use the same template
languages and utility libraries on both sides.

* "Where can I play with Apostrophe 2?"

https://github.com/punkave/a2-sandbox

Right now the sandbox project displays a simple one-page site with two
areas, which currently allow you to add text items (formerly known as
"slots"). You can drag and drop those items freely between areas,
something that wasn't possible in Apostrophe 1.5. The "save" button
saves the content on the server for the lifetime of the server
process, demonstrating the serialization and validation features of
the a2 core.

Keep in mind that we've been focusing on the area and item concepts
(akin to areas and slots in A1.5) and haven't yet turned our full
attention to the page tree concept. Also, we're hard at work on the
file item, which will serve the role of the image, slideshow and file
slots of Apostrophe 1.5.

* "What happened to your work on Apostrophe 2 for Symfony 2?" We
pursued it for a pilot project. We learned valuable lessons from that
project but ultimately decided node.js was a better platform to reach
our goals for A2.

* "Can I contribute?" Sure! But keep in mind that we're moving fast
and refactoring brutally at this point. Right now the project is a
single sandbox repository, but we've already established a plugin (aka
"bundle") architecture which will allow third party code in modules
distributed via the node.js npm repository to be included in a project
easily.

* "When will it be usable?" We plan to complete client projects based
on Apostrophe 2 in just a few months.

* "When will it be stable?" It'll take a while for A2 to settle down
to a "we promise not to break anything" level of stability.

* "What about the database? Are you using MySQL? MongoDB? Or..." We're
using MongoDB. MongoDB is a really good fit for this kind of work,
with extraordinary performance married to a JavaScript-based API
(there's that language again).

* "What Node framework are you using?" We'll be using Express. We're
still finalizing decisions about our preferred template language but
we don't expect you'll be forced to use it. We're taking a careful
look at Nunjucks (http://nunjucks.jlongster.com/), a port of jinja2,
which is part of Twig's family tree (har har har).

* "Where can I learn more about node.js?"

http://nodejs.org/

* "What else are you guys doing with node?" Quite a bit actually. This
is just the stuff in the punkave repo; our team is involved in many
node projects:

https://github.com/punkave/a2-sandbox
https://github.com/punkave/node-netpbm
https://github.com/punkave/dox-foundation
https://github.com/punkave/grunt-dox
https://github.com/punkave/jquery-rest-admin (this is browser side but
we plan to use it a lot in our node projects)
https://github.com/punkave/stagecoach

We hope you'll join us in the Apostrophe 2 and node.js world. And
we'll still be active in the Apostrophe 1.5 world.

Thanks for everything you do with Apostrophe!

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

[Stef]

Great news!

I tend to follow the same way. It's probably too early to contribute. Do you have a roadmap ?

++

Stef

[Robert Speer]

Bitter sweet about symfony, but it does make a lot of sense.

Are there plans a migration script or other strategy from 1.5 to the new version?

It would very useful to be able to run the db dump & css files through a magic script and be able to plug them into a2.

Also node.js/mongo question, is it a pita to host like ROR was back in the day?

[Tom Boutell]

Re: the roadmap...

The sandbox site will evolve into a more full featured single page
site, with support for files, video, etc.

Then it will evolve into a multipage site that can accommodate the
sort of conventional page tree structure you might find in, oh let's
say, an academic institution's website, as A1.5 does so well.

Around that point most of the functionality will move to an npm module
so that you don't necessarily have to start with our sandbox and can
cleanly update just Apostrophe.

At that point it'll be broad enough to accommodate many types of
projects we need to do, and we can begin going for depth as well:
version history, internationalization, workflow, etc.

Meanwhile, as you can see in the list of other Node projects in my
announcement, we're making sure we find or build good solutions to
problems that A1.5/SF1.4 solved well... or at least solved... like the
"admin generator" (jQueryRestAdmin) and the aImageConverter class
(node-netpbm).

[Tom Boutell]

On Mon, Sep 24, 2012 at 6:48 PM, Robert Speer <rhs...@gmail.com> wrote:
> Bitter sweet about symfony, but it does make a lot of sense.

Thanks for understanding where we're coming from!

> Are there plans a migration script or other strategy from 1.5 to the new
> version?
> It would very useful to be able to run the db dump & css files through a
> magic script and be able to plug them into a2.

Re: migrating content: yes, it's important that we support that,
including creating an export tool for A1.5.

Re: migrating stylesheets... well, probably not. But that's because
CSS is one of the areas where A1.5 is in most dire need of a healthy
reboot. We've learned a lot. And we're starting with
Bootstrap-friendly markup, which the entire developer community
understands and embraces.

> Also node.js/mongo question, is it a pita to host like ROR was back in the
> day?

Nah. It's easy in at least two ways:

1. Hosted cloud services like Heroku and Nodejitsu. Done! We'd be nuts
to be incompatible with these.

2. You can host node and mongodb on any VPS and easily run many sites
side by side, just as you can with Apache. You can even run
Apache-driven sites side by side with node sites. We boiled it down to
a neat and tidy package that also covers deployment:
https://github.com/punkave/stagecoach

[Marco Leong]

Just an idea, did you guys made any prototype of Apostrophe 2 with Symfony2 ? Might be it would be great to share it.

[Tom Boutell]

We built a CMS-powered client site with Symfony 2, but the code proved
difficult to wrangle, refactor and extract to a bundle, partly due to
issues with the Doctrine 2 ODM. While I'm sure those things could be
overcome, we don't want to distract from our laser-like focus on
building Apostrophe 2 on Node, or encourage folks to continue with
architectural decisions we've already improved upon (: So no, we don't
plan to do that. If you're committed to Symfony 2 development you
might want to look at the Symfony CMF project.

[Marco Leong]

I have similar difficulty on extracting different functionality on different bundle. And the Doctrine
ODM too, I'm also using Doctrine ODM bundle, and it is so annoying that you have to digging into
the bundle to check what is happening behind. Doctrine ODM still required lot of development
to be mature and usable. Doctrine team should put more focus on it.

[Lasse Munk]

Hi Tom & co.,

What a sad day for the Symfony/Apostrophe community!

While I do respect and to a certain extent understand your decision, it probably means the end for a lot of Apostrophe users. Node.js seems to be a fantastic platform, and I would love to make the switch. But with 10 years of PHP experience, 4 years of Symfony/Apostrophe and 50+ projects (still supporting half of them) built using these technologies, it doesn't seem like the right choice for me.

Can I ask you about your own projects - are you planning on migrating everything to node.js?

I think it boils down to how people use Apostrophe - as a simple (and extendable) CMS platform - or as an option for easily adding great CMS capabilities to dedicated Symfony Framework projects (Enterprise applications, .com startup projects, Administration systems etc.). -Migrating a Symfony project, being only 15-20% based on Apostrophe, would be a bad business decision.

The number one feature for me in Apostrophe is still the whole area/slot structure. When storing objects of information in a database, I can add text fields, text areas, drop downs etc. But very often, I need to store more complicated information, like descriptions with images and HTML and other custom slot type information. Some data requires strict validation and a direct relation to fields in the database, but a lot of data could simply be stored in Apostrophe slots.

So my question is this... with the PHP codebase, how about building a simpler CMS module instead of a complete tool. Skip the tree structure, permissions, templates, blogs, events, feeds etc. and just have a simple bundle for adding CMS type content to SF2 projects? If you would release the SF2 based code, maybe the community could pick up where you left off?

Thank you for a fantastic CMS and for all the hours you put into it! And good luck with the node.js project.

Best Regards,

Lasse Munk

[Stef]

Just to give you some information about my humble experience and what
I am currently doing with my clients. For projects that can benefits a
CMS like Apostrophe, I go this way and I do not need the whole sf2
project. Apostrophe is still a good choice and is still the only one
with a good user experience IMHO. I will create a new project on top
of Apostrophe this week :)

I only use SF2 for new project that really need it, like Annotation or
some other stuff that will add a lot of productivity, or if a client
does not want any CMS or does not want to go Symfony 1 as it will not
be maintained by Sensio at the end of Nov. 2012. Another good point
for Sf2 is the strong support ESI.

And I go Node.js and all this js stuff for some all projects that
really needs new experience or focused strongly on tablets or
smartphones.

my 2 cents

Stéphane,

[Tom Boutell]

Thanks for understanding our position, Lasse.

Here's the thing: SF2 is a total bc break anyway. So while it is a
very cool framework that we like in a lot of ways, it made sense for
us to ask:

"If we have to rewrite everything, shouldn't we question everything
first before we're locked in again? We don't lose anything by taking a
look at other languages and frameworks, if we have to start over
anyway."

So we did question everything. And Node was the answer.

Apostrophe 1.5, as I mentioned, will be supported for a long time. We
are, like everyone else, still starting new Apostrophe 1.5 projects
today. Right now it's a mature solution for a lot of our needs. But
going forward, Node fits better.

The system we built for SF2 isn't what we'd build today, knowing the
lessons we learned from it and have learned since in our Node
development, and it never got as far as including many of the features
you're probably looking for. If the community is really interested in
an Apostrophe-like system for Symfony 2 it would make more sense for
folks to watch Symfony 2 node development and create a compatible
backend in PHP. Right now there's not a lot of back end code yet, but
we expect to get really moving again on A2 soon as we begin building a
major project in A2.

[Tom Boutell]

Re: the "end of support" for Symfony 1, Fabien spoke to this point
recently on the Symfony blog. Critical fixes for Symfony 1 will
continue.

[Richtermeister]

Hey Tom,

I actually think that is a good decision in a lot of ways.

First, I think us folks that need a good Symfony2 CMS will be fine.. there's already many good approaches in development, and from what I can tell Apostrophy's strongest feature, the awesome in-place editing UI, will become more universally available anyways, thanks to create.js and related efforts. Looking at A1, it really seems Javascript is your guy's strong point, so it makes sense to leverage that more.

Secondly, what excites me most is that now I have a reason to look deeper into node.js and have a great company like you guys give me some solid code to look at / play with :)

So, rock on & all the best!

Daniel

[Tom Boutell]

+1!

[Lasse Munk]

Hi Tom,

Just one comment on "SF2 is a total bc break anyway" and "We don't lose anything by taking a look at other languages and frameworks, if we have to start over anyway."

Again it's about the use case. Some of my projects include a huge amount of custom PHP based code and libraries. Even though you would provide an upgrade tool, it would "only" upgrade the standard CMS part of an application, whereas SF2 still support PHP code. For smaller projects though, it makes sense to migrate to a new platform, if it's a better platform.

Anyway, even though I'm not going to migrate all projects, I guess I am still going to take a deeper look at node.js :)

Best,

Lasse

On Monday, September 24, 2012 5:19:53 PM UTC+2, Tom Boutell wrote:

[Robert Speer]

It hit me that A2 using twitter bootstrap is a buch bigger deal than I had previously thought.

It opens the door to using off the shelf themes from places like https://wrapbootstrap.com, & http://bootswatch.com.

Which means I can put more budget towards cool features and less towards design and end up with a better product

Would it be worth while to make A1.5 bootstrap compatible?

Along with all the benefits of bootstrap, it would also ease the transition to A2 for both sites and dev's.

[stephenrs]

Sounds like a great idea, I just hope A2 take a less CMS-centric approach than its predecesor...I've been building SAAS apps for the past 10 years or so, in environments where the vast majority of our value comes from the tools that we're building, not from the content - but every SAAS app needs at least a few pages of content to dress it up for the public.

Every CMS that has crossed my path during this time has taken a "the CMS is the thing" approach, which has seemed to embody the belief that you should start with your CMS, then try to use it as the foundation for whatever else you might want to build. This heavy-handed techno-narcissistic approach has almost always made tossing up a Wordpress site and doing some mod_rewrite magic more appealing. When my small team and I discovered Apostrophe during its alpha stages, put forward as a Symfony plugin, we thought finally someone understands that sometimes a CMS should just, uh, manage content well and nothing else. We figured that since it was known that we were already using Symfony, then we're probably already building something more complex than serving up content, and that a Symfony "plugin" would stay out of the way while preventing us from having to maintain a separate platform for the content bits. Not so.

From things like the routing monstrosity, to the aggressive and presumptuous CSS umbrella, and the forced suspension of Symfony's output escaping, struggling to keep Apostrophe out of the way has been more than we bargained for...and trying to integrate bits and pieces of it into our app in strategic places has been effectively impossible, so we've rolled our own in those cases.

This is not meant as a slam or rant against Apostrophe - we're still using it, we've tamed it (although pinned to a 2 year old svn tag), and it's serving well at this point. I just wonder if there are others out there who long for lightweight, pluggable content management, and have seen enough CMS beasts who all think they are better beasts than the ones who came before them - they all smell the same to me at this point. Node + mongo sounds promising. 

 
Hoping for the best for all.

SS

[Tom Boutell]

Thanks for the honest feedback, Stephen.

A lot of your concerns did get addressed in that two-year period since you stopped updating Apostrophe. I'll speak to a few things that didn't.

A2's CSS is cleanly namespaced, there is always an apos- prefix. (Any exceptions are bugs we look forward to stomping out.) We are not forcing bootstrap or any other CSS framework on you; there will be a grid that we like in the sandbox project, but you'll be able to get our dialogs and area editors to work without it (again, if you can't, that's a bug we're up for fixing). 

If you want to re-style our stuff you can, or you can leave it alone and concentrate on styling your own public-facing stuff.

Routing is certainly much cleaner in A2 because we're not fighting to force-fit nested routing into a Symfony routing engine that was never meant to support it.

The storage layer is drastically simpler. Every page is a mongo document, plain and simple. Many things we fought MySQL to accomplish in A1 are intuitive with Mongo.

In general: it's a cleaner architecture. We've learned from experience.

For what it's worth, we've always built projects with a mix of Symfony modules and Apostrophe-specific stuff, and we've never really had a problem. 

We look forward to your code contributions and feedback on A2.

--
You received this message because you are subscribed to the Google Groups "apostrophenow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apostropheno...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[stephenrs]

Hi Tom,

Thanks for the additional info...and I checked, and it looks like we're pinned to the 1.5.2 tag, which is in truth just over a year old - so we did get the some of the benefits of the issues that you guys addressed (keeping up with the dev changes just turned out to require more bandwidth than we could dedicate to CMS stuff, so pinning to a stable tag seemed prudent at the time).

Also, nice to hear that A2 will get the benefit of your experiences - I know the feeling - with the JS frameworks that have popped up over the last few years, there are just much cooler/better ways to structure and build certain kinds of apps these days...A2 on SF2 wouldn't really have made much sense to me either. Also, Mongo seems like a great fit for a CMS. FWIW, we've been running part of our app on Couchdb for a while with great success, and I've recently become enamored with EmberJS and have ported part of the app to it.

Good luck getting A2 built and out there...if my long time dream of a CMS that doesn't expect me to pray to it can ever become a reality, I'm betting you guys might just be the crew to do it. And although I should probably be more afraid of the bleeding edge than I am, when I hear you say "it's alpha, but we're using it in production" it might just be enough to pull me in...I'll never learn...

Best,

SS 

[Geoff DiMasi]

Hey Stephen,

I would be interested in checking out the lightweight version that you guys rolled. Is that available on github?

g.

--

[stephenrs]

Geoff,

Calling it a 'lightweight version' is a bit generous...our Apostrophe installation consists of the core CMS with a few hacks that at this point have stood the test of time. We've added things like the ability to specify internal links in content and navigation with a simple syntax (like "{{@about/team}}"), and the ability to manage pages and other pieces of content from an "internal pages" menu that I added to the global (admin accessible) navigation. The built-in nav/menu mechanism didn't really fit for us.

In places in our app that live outside of the Apostrophe world, but where non-programmer content management autonomy was desired, we've implemented a combination of a hack that switches apostrophe templates based on routes (although I can't remember exactly how this works, or where we hooked it in), and a simple UI that allows folks to edit a small collection of "content blocks" that are retrieved using Symfony components. For a while we also had a context-sensitive help system that interacted with Apostrophe areas/slots programmatically (and had its own menu in the global admin nav), but that's been retired.

We also did away with the "cms" requirement in urls early on (although I think you guys did that at some point as well).

So, there isn't really a "thing" here, just a bunch of bits and pieces that we added to suit our purposes...and we're also an old skool svn shop...git is (shamefully?) still just a curiosity for me...we'll join all the cool kids if/when the time is right ;)

The underserved use case for me has long been the ability to marry a non-content-based web application with content management capabilities for the text/media that dresses it up - so developers are never responsible for fixing typos or changing images in web-based software, for example. Having to manage hundreds of pages of hierarchical content fast will probably never be something that I'll be drawn to worry about (although a quite worthy pursuit). Being able to sprinkle bits of a CMS where it's needed in an app, while being free to continue to think "app first" rather than "cms first" would be the ideal. The current wave of "new-thinking" frameworks seems to bring something like this much more into reach...and if there's already something out there that I've missed, I'm all ears.

SS

[Tom Boutell]

Mmm. We've always supported virtual pages as a way to add an editable area or singleton slot to anything. We frequently use this to accessorize an otherwise non-Apostrophe-related object (like, say, a product or person) with a content area about them.

Have you read the section on virtual pages in the Apostrophe Developer's Guide? It's a very useful technique, and so simple that people sometimes cruise right past without noticing it.

[stephenrs]

Virtual pages does ring a bell, and reviewing the docs again in this context the technique is intriguing (and you're right, I never went further than skimming the paragraph or so about them in the manual(s) until now). I wonder though, would application pages that used the technique need to be served via the a/show (or some other Apostrophe-controlled) route? If so, running our app "on top of" Apostrophe would be a non-starter, but let me know if I'm confused about something, or if there's a less tightly coupled way to get this kind of integration than comes first to mind.

SS

[Tom Boutell]

Nope, you do not use the a/show route for virtual pages. Like the docs say, you use a slug that doesn't start with a /, and call the a_area and a_slot helpers as needed, and everything else just works. You're responsible for passing in 'edit' => false or 'edit' => true, since it's your context and you know who's allowed to edit what and we don't. Apostrophe's admin routes are involved in saving and editing things of course.

That's pretty much it.

It's not the first time someone has missed this feature and spent time reinventing it, unfortunately - that's happened in our own offices. In A2 the feature is more front and center, but we'll be gunning to make this harder to miss in the docs.

[Tom Boutell]

(You can think of virtual pages as a NoSQL db whose only job is to associate areas and slots with a slug and be pretty good at loading them efficiently together if they share a slug.)

[Richtermeister]

The virtual pages were genious, once I figured out how to use them right.
Overall Apostrophe was/is genious from a user-interface and user-experience standpoint, and I loved how you could mix regular symfony models/actions/generators, etc with it.
What I found clunky is the way you had to dance around Doctrine1 limitations, which made a lot of code hard to follow/extend, and the excessive passing through of variables through templates.
Would have been cool to see what you could have done with SF2 under the hood, but I'm looking forward to seeing A2 in action, too.

Daniel

[stephenrs]

Does sound like something that could fit our case - so the next time we need to add/change/fix something related to the handful of content bits we're currently using our DIY setup to manage, I'll definitely look more closely at virtual pages (unless we're already playing with A2 by then). I guess it might have been nice to know about them sooner, but the rough and ready setup we have now was built literally overnight, and has been serving our limited internal needs pretty well.

Thanks for the tip.