Lotus vs. Excel

A recent blog made a comparison between Lotus 123 and Microsoft Excel.  I found it interesting because our CSA Brian Chan often uses this example when describing Liferay's company strategy.  And while I already posted on how I felt our product has become somewhat bloated, the article reminds me all the more, that it definitely is better to have too many features rather than too few.

But another thing i found interesting was the point he made about javascript sizes.  If you've been following our discussion forums, you would have noticed that one of the most talked about topic is javascript sizes.  If what this guy writes is true, maybe our javascript size isn't an issue at all (which i admit is quite large at the moment).  If yesterday I felt we were building Liferay backwards, today I feel like Liferay is being built for the future .

Haha.

 

 

Blogs
it is possible to strip down the js in liferay to just the minimal set that you require.
Hi Dave,
Actually, when you take into consideration gzipping, the file size of the Javascript is around 80k. Not small, but definitely not bad for a portal that is incredibly AJAX and JS heavy.

I disagree with Joel on the whole feature thing, at least as regards feature QUANTITY goes.
I agree with your other post about streamlining Liferay down, which is something I've been pushing for since I started.

I think we need to make Liferay follow the plugin paradigm, and even start removing features where we can.

I'm all for needed features that are truly needed, but I think Liferay has a history of feature creep.

The problem is, it's always way easier to actually add a feature than it is to remove it. And most features, while "cool", are many times not worth the effort that results from the added code download size, code complexity, bugs, etc.

Luckily, we are making strides, and I think we're improving a lot all around.

I have to disagree with Joel about his observation in quite a few areas. First, I don't think Lotus' problem was that they didn't add enough features. The problem was they spread themselves too thin, not focusing on the core product, and wasting too much time on performance, without realizing just how quickly the PC market was changing.

The reason why the AJAX phenom is different is because 1. bandwidth doesn't follow Moore's law. Some 50% of the U.S. is still on dial-up, and those speeds are dropping fast, but not quite the same as doubling speed every 18 months (the bandwidth at the Diamond Bar office is a huge testament to that).

Also, he grossly overestimates the browsers changing. How long has IE 6 been the dominant browser, even with IE 7 available?
Microsoft won't dramatically improve their rendering engine, because they're afraid of backlash from the millions of sites that are hooked on their broken model.

He kind of glosses over the numerous problems (like the copy/paste thing), and doesn't realize quite the problem that is there. For instance the copy/paste thing. That's doable in IE, but not allowed in Firefox because of security settings.
Stuff like that isn't a small thing to overcome.

Personally, I do think there is that "New SDK", but it's been around for ages. It's called Flash.

The problem with Flash is legion, from SEO and accessibility issues, to a terrible IDE, and a completely convoluted development model.
However, Adobe could quite possibily introduce new features that base it's rendering engine upon the HTML and CSS currently on the page.

Flash is more embedded and consistent than any standard, across more platforms, and behaves as expected much more often.

If they could build the rendering engine to read from the page, we'd be in business. We'd have our new SDK.

But the kind of massives jumps Joel is talking about is not likely to happen.

Just a thought, thanks for posting these, it's interesting hearing your thoughts on the matter emoticon