Domain: morfik.com
Stories and comments across the archive that link to morfik.com.
Comments · 12
-
AJAX directions
I see few recurring themes in the questions asked, so I'll try to cover them briefly:
Q1: How do you deploy an AJAX application offline?
A1: You can use integrated HTML/CSS/JS/Flash/PDF runtime, like Adobe AIR.
Q2: How do I deliver bulky complex AJAX applications over the net, if it's a lot of code?
A2: You don't. It's not a suitable deployment model, at least until we have a simple delivery vehicle for bundling multiple app elements into a single file, such as a browser downloading and directly reading a ZIP file with collection of resources/JS files (as with Java's JAR). Until then, and for complex UI-s in general, look into established compiled solutions like Flash.
Q3: Do we need JS2.0?
A3: No, we don't (right now), since JS2 delivers benefits for larger projects only (refer to Q2 why large online JS projects are not viable). If this is resolved, then JS2 will be highly desirable.
Q4: Hand-made AJAX or AJAX framework?
Q4: Framework. Cuts development time, provides consistent code, avoid wheel reinvention (Exception: very large projects may need custom code. Are you Google? Yahoo? If not, use a framework).
Q5: Is AJAX wide-spread / easy / hard / common?
Q5: It's easy, wide-spread, and accepted. Fallback is usually present, unless the AJAX is a component of a complex online app that can't have no-JS fallback (example: rich text editor).
Q6: Do I pick AJAX or Web 1.0 / iPhone SDK ?
A6: Apply common sense. In general, when a new technology comes around, people abuse it and try to shoehorn it into replacing everything before it. Then comes the backlash ("AJAX sucks"). Only then, people settle to use said tech in moderation, co-existing versus replacing, evolution versus revolution, and solving unique problems not solved before. -
...Unless you use a tool that already fixes these
Morfik http://www.morfik.com/ has already worked on these issues and deal with them so you don't have to lift a finger when you build your application. Atlas is (reportedly) going to (eventually) make all of these issues go away as well. Since Atlas isn't handling these issues yet I can't comment on how elegant it is, but Morfik is unbelievable. States are just handled. Bookmarks, back, forward, and reload buttons are no longer an issue. What's even cooler about Atlas and Morfik is that they are RAD IDE's with built-in everything that you need. Obviously Atlas is an all Microsoft tool, but Morfik integrates the more
/.-friendly Apache and Firebird servers, which also means that in theory you shouldn't be burdened with a higher deployment cost. How they're going to handle patches to those products as new versions come out hasn't been determined, AFAIK.
Both make the transition to AJAX development even easier since the code-portion of your application is built in a high-level language you are already familiar with, whether or not you do web-development for a living already.
It's so cool to live in interesting times! -
Tools To Build With
Now that http://www.morfik.com/ is in public beta, and Atlas is about to do the same, we are finally starting to get some IDE/RAD tools to build WebOS apps. It's pretty exciting to see where AJAX has gone in 14 months. I can't wait for things to get a bit further so I can start seriously selling clients on going this route.
Next stop: IBM reintroduces the javastation (only now it will be a javascript station).
We'll see how long it takes to make this kind of interface really WORK on cell phones and other ultraportable devices. -
Well, Here We Go
Well, the AJAX wars have started, and M$ maybe just got off the first shot. We'll see. With http://www.morfik.com/'s public beta just around the corner the RAD IDE AJAX tools are finally coming on scene. We'll see what people can do with these tools, and whether AJAX is REALLY as overrated as some are claiming. Personally I'll bet that once people can get their hands on tools that let them build web apps as easily as they can desktop apps (and unplug them, i.e. run them locally or over the 'net, as you can with Morfik) you'll see a huge increase in web applications.
The number of AJAX tools that are on their way is staggering. http://www.tersus.com/ is one designed for the absolute noob, and http://www.backbase.com/ is also a potential option. -
Re:You don't know (A)JAX sh*t.
don't take it personally, most of these guys are still thinking they're gonna MetaRefresh their tables and use JS for mouseOver on links
ajax plus caching is the bomb, now if only we all had time to program up those objects in Javascript. Well I don't, so I'm waiting for this : http://www.morfik.com/ -
Google querying of Morfix.comMy Bullshitt-Meter just pegged... Check out what a Google search for "site:www.morfik.com inurl:media" pulls up:
http://www.morfik.com/media/The_Making_of_Northwi
n d_Unplugged.pdfThey made a presentation of another demo, then made one of GMAIL. Both use almost exactly the same language, it just looks like some marketer did a find-replace on Northwind. Both were made in 2 weeks for a protoype, and 2 months for a full version.
Fishy.
StickyWidget
-
Re:Great!
lol
check the page source code. You can read a "Generated by Morfik XS http//www.morfik.com" on top... and then realize that the generated code is not compliant with xhtml or html strict.... So using ccs2 with this "mega tool" will be another pain in the ass.
Good job pionners! -
at least..
it makes code easier to read http://www.morfik.com/js_sshot.html
-
Re:Any one has sample code?
-
Re:Any one has sample code?
-
Re:Why GMail?
Because they used their IDE to create a replica of GMail:
http://www.morfik.com/prerelease_schedule.html#Gma il_Demo -
Where are the web standards
Assuming that they actually eat their own dog food, and use their own tool to create their Own site, I wouldn't trust this tool. Their site is an inaccessible piece of table-based rubble with missing alternative texts all over the place. Not even Slashdot in it's old incarnation was this ugly, standards-wise.
Adding to that, their site is severly SEO-deoptimized, which might -- now that I think of it -- be a good thing to end-users, as this will undoubtedly reduce the spread of said markup rubble