<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Bloatware: How to Avoid Bloating Your Application</title>
	<atom:link href="http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/feed" rel="self" type="application/rss+xml" />
	<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application</link>
	<description>Design, Develop, and Grow</description>
	<lastBuildDate>Wed, 17 Mar 2010 12:23:00 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: When WordPress is Getting Bloated &#124; Deuts.NET</title>
		<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/comment-page-1#comment-178999</link>
		<dc:creator>When WordPress is Getting Bloated &#124; Deuts.NET</dc:creator>
		<pubDate>Tue, 21 Apr 2009 16:18:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.devlounge.net/?p=1876#comment-178999</guid>
		<description>[...] Bloatware: How to Avoid Bloating Your Application [...]</description>
		<content:encoded><![CDATA[<p>[...] Bloatware: How to Avoid Bloating Your Application [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stian Jacobsen</title>
		<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/comment-page-1#comment-176406</link>
		<dc:creator>Stian Jacobsen</dc:creator>
		<pubDate>Sun, 05 Oct 2008 07:29:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.devlounge.net/?p=1876#comment-176406</guid>
		<description>My experience is that you can avoid this problem with &quot;section rewrites&quot;. 
Rewriting a big application takes time, so when you thinking of creating an application, make it easy to go in and rewrite sections of it when needed..

Our system is allways updated on a small scale level, our users dont acctually see/feel theese changes but it keeps the system up-to-date both on internal code and other frameworks (like jquery etc)</description>
		<content:encoded><![CDATA[<p>My experience is that you can avoid this problem with &#8220;section rewrites&#8221;.<br />
Rewriting a big application takes time, so when you thinking of creating an application, make it easy to go in and rewrite sections of it when needed..</p>
<p>Our system is allways updated on a small scale level, our users dont acctually see/feel theese changes but it keeps the system up-to-date both on internal code and other frameworks (like jquery etc)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bananaranha</title>
		<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/comment-page-1#comment-176399</link>
		<dc:creator>bananaranha</dc:creator>
		<pubDate>Fri, 03 Oct 2008 21:44:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.devlounge.net/?p=1876#comment-176399</guid>
		<description>&lt;b&gt;(...) because online you just load what you want to load, and if the WordPress core is organized in a decent manner, that means that the extra stuff won’t be called for unless needed. &lt;/b&gt;

This is even more so offline (as in desktop apps).

What most people perceive as &quot;bloat&quot; in most applications is mostly static resource files (icons, fonts, pictures, themes, language packs, etc). These can easily take 10 times or more disk space than the app itself.

As for &quot;feature bloat&quot;, sure we may only use 10% of all features —as it is often repeated—, but that consists of a common core of, say, 8% and a 2% that is fundamentally different for each user and use case).  

Just try to remove even an obscure feature from an app and see what happens (that is, a deluge of complains from people who want it back.</description>
		<content:encoded><![CDATA[<p><b>(&#8230;) because online you just load what you want to load, and if the WordPress core is organized in a decent manner, that means that the extra stuff won’t be called for unless needed. </b></p>
<p>This is even more so offline (as in desktop apps).</p>
<p>What most people perceive as &#8220;bloat&#8221; in most applications is mostly static resource files (icons, fonts, pictures, themes, language packs, etc). These can easily take 10 times or more disk space than the app itself.</p>
<p>As for &#8220;feature bloat&#8221;, sure we may only use 10% of all features —as it is often repeated—, but that consists of a common core of, say, 8% and a 2% that is fundamentally different for each user and use case).  </p>
<p>Just try to remove even an obscure feature from an app and see what happens (that is, a deluge of complains from people who want it back.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Drew Wilson</title>
		<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/comment-page-1#comment-176392</link>
		<dc:creator>Drew Wilson</dc:creator>
		<pubDate>Fri, 03 Oct 2008 15:03:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.devlounge.net/?p=1876#comment-176392</guid>
		<description>Very interesting article, and I conclude just about the same answer you have come up with.  While re-writing and revisiting code is necessary, that can also be considered the downside to a bloated application.  Just take a look at Windows Vista.  The re-wrote most of what XP has solidified, and because they were in the future terms of what they wanted, they ended up adding to the core things that actually caused the program to become a bloated application(up for debate).  I think Priorities are really where the bloated/non-bloated blame game can be had.  If your priorities are to rewrite the code so that it is modular and quick, then you may succeed, if they are to allow for more options and more choices, chances are your code will become bloated from the get-go.

Senior UI Developer, Coventry Health Care.
Geedew Owner.</description>
		<content:encoded><![CDATA[<p>Very interesting article, and I conclude just about the same answer you have come up with.  While re-writing and revisiting code is necessary, that can also be considered the downside to a bloated application.  Just take a look at Windows Vista.  The re-wrote most of what XP has solidified, and because they were in the future terms of what they wanted, they ended up adding to the core things that actually caused the program to become a bloated application(up for debate).  I think Priorities are really where the bloated/non-bloated blame game can be had.  If your priorities are to rewrite the code so that it is modular and quick, then you may succeed, if they are to allow for more options and more choices, chances are your code will become bloated from the get-go.</p>
<p>Senior UI Developer, Coventry Health Care.<br />
Geedew Owner.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Owen</title>
		<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/comment-page-1#comment-176391</link>
		<dc:creator>Owen</dc:creator>
		<pubDate>Fri, 03 Oct 2008 14:50:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.devlounge.net/?p=1876#comment-176391</guid>
		<description>There are two points to be made here.  First, it seems as though someone in the WordPress camp is noticing that they need to evolve, and they&#039;re finally doing something about it.  I can see someone with a distinct big-picture view of the codebase making some fundamental changes in how things work.  Whether they&#039;ll be able to compete well with the opposing interests that are adding all of the additional bloat and be able to make a significantly positive enough change will be revealed over time.

Second, there is an accrual in WordPress of technical debt and legacy stagnation that will be very difficult to overcome.  Since the minds in the project are so tied to conservative thinking (in terms of how the project works), it&#039;s difficult to welcome new ideas.  An example is the insistence on procedural templating in terms of exposing API to users, as compared to the power and flexibility of an object-oriented MVC approach enabled by the new features of PHP5.

While the change would have to be gradual to shift extant users gradually into a new way of working, one must wonder if the shift would need to be so slow that it will eventually be overtaken by new players willing to plunge into the new technology head-first and keep up with it, like Habari.  As they say, &quot;Change or die.&quot;</description>
		<content:encoded><![CDATA[<p>There are two points to be made here.  First, it seems as though someone in the WordPress camp is noticing that they need to evolve, and they&#8217;re finally doing something about it.  I can see someone with a distinct big-picture view of the codebase making some fundamental changes in how things work.  Whether they&#8217;ll be able to compete well with the opposing interests that are adding all of the additional bloat and be able to make a significantly positive enough change will be revealed over time.</p>
<p>Second, there is an accrual in WordPress of technical debt and legacy stagnation that will be very difficult to overcome.  Since the minds in the project are so tied to conservative thinking (in terms of how the project works), it&#8217;s difficult to welcome new ideas.  An example is the insistence on procedural templating in terms of exposing API to users, as compared to the power and flexibility of an object-oriented MVC approach enabled by the new features of PHP5.</p>
<p>While the change would have to be gradual to shift extant users gradually into a new way of working, one must wonder if the shift would need to be so slow that it will eventually be overtaken by new players willing to plunge into the new technology head-first and keep up with it, like Habari.  As they say, &#8220;Change or die.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Freelance Friday: My Writing Week 40 &#124; tdhedengren</title>
		<link>http://www.devlounge.net/column/bloatware-how-to-avoid-bloating-your-application/comment-page-1#comment-176390</link>
		<dc:creator>Freelance Friday: My Writing Week 40 &#124; tdhedengren</dc:creator>
		<pubDate>Fri, 03 Oct 2008 11:18:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.devlounge.net/?p=1876#comment-176390</guid>
		<description>[...] Bloatware: How to Avoid It In Your ApplicationA column on bloatware, on Devlounge [...]</description>
		<content:encoded><![CDATA[<p>[...] Bloatware: How to Avoid It In Your ApplicationA column on bloatware, on Devlounge [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
