| 
Here are the latest updates for dzenmail@gmail.com "Ajaxian" - 4 new articles - AppJet: Develop, Preview, Deploy all on the Web
- Dan Webb Updates Low Pro
- WriteMaps.com: A tool for website planning
- window.createPopup leaks 80KB in IE 7
- More Recent Articles
- Search Ajaxian
Aaron Iba has released AppJet, an online IDE for developing simple web apps. You can
write an entire web app (client-side and server-side) in JavaScript, in 1 file of code. We run JS in a virtualized execution environment
on the server and provide free hosting. We also provide an easy JavaScript object database for persistent storage. The beta online IDE includes a syntax-highlighting text editor (for JS code, written in client-side JS). This market is becoming interesting. You have tools such as Bungee Labs, and the Google Mashup Editor, showing that you can do a lot of development directly online, and it does seem that this could be a great future. Let a developer build their application, test it, and just hit "deploy"! Done. AppJet itself was interesting to play with. Although a little rough around the edges, you can see where it is going. I asked Aaron a couple of questions, and he kindly went into detailed answers: What are you trying to accomplish? The short-term goals are to make it easier to get simple web apps
online and make it easier in general to whip up programs that "run on
the web". By making it easier we hope to appeal to both beginners and
experienced hackers. After all, experienced hackers don't like to do
unnecessary work either. We hope that this will expose the "long-tail" of web apps. There is
no limit to the number of interesting programs that can be written in
100 lines of an expressive language like JavaScript, but often
100-line-program ideas don't get published as web apps because there
is a lot of activation energy required to get a web app online. We
hope AppJet changes this. Longer term, we want to be a platform for all sorts of web apps. We
have ideas for how to make AJAX programming easier by doing the whole
app in javascript. (We disagree with the GWT approach, because we
think javascript is a better language than Java for writing apps, all
respects to the GWT team whom I know and regard very highly from my
days at Google). As a simple first step toward client-server integration, we enable
different "sections" of code to appear in the same source file. You
can specify a section of code to be run on the server, the client, or
shared between both. For instance, the shared code is useful for
running the exact same form validation code on the client and server. Why did we do this? Mostly, we were sick of all the hassle of setting up servers,
configuring apache, installing MySQL and php and mod_whatever, just to
get a simple web app online. So we largely did this for ourselves so
we could whip up little apps faster. We also think it would be great
if it were EASIER to write a web app than a desktop app. This would
change things: if you're going to write a simple computer program,
then instead of writing it on your desktop and not sharing it with
anyone, you could make it a web app and other people can benefit. What kind of applications are particularly well suited to this
kind of development? Right now, simple web apps that require server-side processing and/or
persistent storage. Like a custom sign-up form, basic input/output.
We also happen to be a really good place to prototype a facebook app.
"The Compliment Machine", for example, is a facebook app we wrote and
has been secretly hosted on AppJet for the past month. Our app server is currently very efficient about serving high QPS, but
our storage system is capped at 10MB, so if a facebook app on appjet
becomes a hit, then it will probably reach the storage limit. We plan
to offer paid accounts with increased storage. Longer term, I think we'll also become a good place for AJAX apps and
for mash-ups. Right now our mashup support consists of a server-side
wget() function that downloads a foreign URL, but you could imagine
where we could go with this. Aren't you tied to the platform? Our business model does not depend on locking people in to our
platform. The primary value we provide is easy, efficient hosting,
but we will also at least release software that lets you host an app
yourself. This is relatively low priority for us now because we're
not sure how much users care about it, especially for the kind of apps
AppJet is ideal for. If it turns out users care a lot about this, we
will quickly release host-your-own-app server software. We will
probably also even release the source. We are also going to open-source our server-side javascript
micro-framework (which is itself written in javascript). Actually,
you can already view the code to our framework by clicking the source
link at the top of any doc page . The only software we have that we feel is essential to keep
proprietary is our unique app virtualization engine. Most
virtualization efforts to date have focused on virtualizing machines
(e.g. VMWare), but we are going for the long-tail of simple apps, so
we had drastically different requirements. We designed our
virtualization software such that hosting 1 additional app provides
negligible overhead provided that the app does not receive lots of
traffic or consume lots of storage. This way, we can host over a
million apps on a single server, if each app is low-traffic. So in short, we have no problem releasing all the software necessary
to host appjet apps yourself, but we won't release the software to
host AppJet itself :). 
Dan Webb has updated his Low Pro extensions to the Prototype library making v0.5 compatible With Prototype 1.6 . In addition, several new features have been added: - Event.onReady delegates to the new dom:loaded event
- DOMBuilder now delegates to Prototype's new Element
- Low Pro's DOM methods are now gone
- Behavior.create() works just like the new Class.create()
- New core behaviors
You can learn more about Low Pro via the project's Google group and v0.5 is available for download via SVN.
Scott Jehl set out to make the website planning process more efficient and fun. Tired of dealing with expensive tools that were either way overpriced or simply didn't meet his needs, he choose to build a site that did what he wanted and with the plan of letting others developers take advantage of the new tool. Hence, WriteMaps.com was born: There are many ways to create a sitemap, most of which involve expensive software, tedious box drawing, and other annoyances that get between your ideas and your results. What if this process could be more collaborative and efficient? This is the question that led to the creation of WriteMaps. With WriteMaps, you can set up an account and work together on a centrally located version of your sitemap. Your sitemaps are available at all times from anywhere - so there's no need to worry about exporting your files and sending them around.
Scott leveraged the jQuery library throughout the site and built a very intuitive interface to layout out a sitemap. Some of the coolest features include: - Toggling of views between treeview or hierarchical metaphors
- Zooming in and out of a layout
- Dynamic addition of branches to the sitemap
- In-place editing of page names
- On-the-fly creation of XML-based sitemaps
- Print Formatting
- Contextual Undo / Redo
Sitemaps can be stored for future updates and can also be shared with other users. The WriteMaps Blog also provides more information about the progress of the project.
Frederico Caldeira Knabben, project manager of the FCK Editor, has been fighting some memory issues and found a new leak: We at FCKeditor are constantly fighting against memory leak. We have already fixed several related issues, but we were still facing an expressive memory leak with IE7. With some intuition, we were able to reduce the problem to a simple test case, and we have sadly found a new memory leak issue *introduced* with IE7. Essentially, every call to window.createPopup() leaks 80Kb of memory. A test page can be found here: http://www.fredck.com/bugs/ie/createpopupleak.html In the default FCKeditor interface, we use six IE's popups for all floating panels (toolbar combos and context menu). On pages with several editor instances, the memory increasing is substantial. As far as we could understand it, there is no way to "cleanup" that leak. We strongly hope IE8 and even IE7 will have it fixed as there is no way to workaround it (I hope I'm wrong!). Suggestions? Comments?
More Recent Articles
Click here to safely unsubscribe now from "Ajaxian" or change subscription settings 
Unsubscribe from all current and future newsletters powered by FeedBlitz
| Your requested content delivery powered by FeedBlitz, LLC, 9 Thoreau Way, Sudbury, MA 01776, USA. +1.978.776.9498 |
| 
