This post chronicles the conversion of a medium-complex web application, Magic in the Browser (MITB), from Styled Components to StyleX.

TL;DR

• StyleX promotes more maintainable component styling practices compared to Styled Components by prohibiting style cascading.
• I experienced an issue with code-splitting and tree-shaking after moving to StyleX but was able to overcome the problem.
• StyleX increased the total bundle size. The size of minified component code increased by approximately 28%, but StyleX compresses better.
• StyleX decreased the total blocking time at page load due to less bootstrapping work (perceivable even on Desktop).

History of CSS in MITB

In its infancy, circa early 2010s, Magic in the Browser was a YUI 3-powered web application. YUI 3 was prima facie still a widget library like its predecessor but under the hood lived a very robust and innovative module system. Magic in the Browser could define a module representing the current page and then declare all of that page's dependent modules. Loading the page with YUI.use('mitb-page') would generate a dynamic URL containing all dependencies that pointed to a bundling web service. A CSS file could be represented by a module and declared as a dependency of the module that it styled. In this way, each module had its own separate .css file declared as a dependency. Classes in these files were still globally scoped, so a root classname was needed to contextualize the styles.

Shortly thereafter, NodeJS would arrive on the scene and with it new bundlers like Webpack. These bundlers would obviate the need to explicitly declare module dependenies as they would now be inferred through the NodeJS import tree. A CSS file could be imported directly by a JavaScript file, cueing Webpack to add it to a monolithic CSS bundle. MITB adopted Webpack and continued managing its CSS with separate CSS files per component.

At this point, a natural progression would've been to adopt CSS Modules. CSS Modules still prescribed a CSS file per component approach but eliminated the need for an explicit root classname to scope the styles.

Instead, I jumped on the CSS-in-JSS bandwagon. The major draw for me was that by making your CSS manipulable by JS, you no longer needed some extra CSS pre/post-processer like SASS or PostCSS. Why add a separate front-end language to the mix when JavaScript was already in use and more powerful? Additionally, for times when JavaScript needed to know CSS values, the value could be defined once and shared. (this was pre-CSS variables, if memory serves) Out of the available CSS-in-JSS libraries, I chose the React specific Styled Components.

Styled Components Overview

Styled Components generates new React components by augmenting existing components with CSS styles. Styles can be applied to both built-in and custom elements.

Styling with Styled Components looks like this

const Container = styled.div`
    background-color: blue;
    color: white;
    ${props => props.primary && 'font-weight: bold;'}
`;

I chose Styled Components because it was popular and relatively performant. I loved the idea of defining styles using CSS syntax rather than JavaScript objects.

The downside is it's a runtime solution, so you're downloading the Styled Components bootstrapping code and can only start processing CSS after JS has been downloaded, parsed, compiled, and executed. JavaScript bytes are expensive.

StyleX Overview

StyleX is the CSS-in-JS library recently opened source by Facebook (teased since Facebook's redesign in 2019). It boasts the unique approach of generating a single CSS class per "style: value" pair. The argument is that, with a large codebase, CSS classes will repeat the same styling over and over as the application grows. This creates bloated CSS, contributing to a slower page load exprience.

By approaching one class per style, the growth of the app's CSS payload size approaches zero despite an ever increasing app. StyleX generates unique, short class names to represent these styles for you. This happens as part of the build step, generating a single CSS file that you include at the top of your HTML file.

The downside is it creates a single CSS file containing all styles that will block initial rendering and contain styles unimportant to the critical path.

StyleX looks like this

const styles = stylex.create({
    container: {
        backgroundColor: 'blue',
        color: 'white',
    },
    primary: {
        fontWeight: 'bold',
    },
});

const Container = () => {
    return <div {...stylex.props(styles.container, props.primary && styles.primary)}>{...}</div>;
};

The Migration

Role of Props

Styled Components create components that can accept props that vary styles. Components are defined with JavaScript template literals with embedded anonymous functions that receive props and return conditional styles.

Stylex does not produce new components but only style-related props that are spread on existing components. Props to your component can control which "namespaces" get conditionally applied to your components.

Scoped Styles

Because Styled Components lets you write arbitrary CSS, selectors targeting nested elements (built-in elements or other Styled Components) were prevalent. For example, a List element could define a CSS rule targeting a List Item component. This leads to an undesirable tighter coupling.

With StyleX, scoped styled do not exist. Styles are only set on the specific element that is being targeted via ...stylex.props() (akin to setting the style property directly).

Common Components

MITB has a common component library. With Styled Components, common components were customized with props or by "extending" the base component to a new component with custom styles. With StyleX, the same components exist, but they are customized by props or passing a style prop.

Take the common Button component. It has styles for hover, active, color scheme, disabled, etc. Additionally, the same button styles can be applied to an anchor tag- a ButtonLink.

The Styled Components version:

export const Button = styled.button`
  cursor: pointer;
  border-radius: 4px;

  /* ... */

  background-color: ${props =>
    props.primary ? colors.darkText : colors.transparentBackground};

  :hover {
    ${hoveredButton}
  }

  :active {
    ${depressedButton};
  }

  &[disabled] {
    cursor: default;
    /* ... */
  }

  ${props => props.depressed && depressedButton};
`;

export const ButtonLink = styled(Button.withComponent('a'))`
  display: inline-block;
  text-decoration: none;

  font-family: ${fonts.base};
`;

The StyleX version:

const styles = stylex.create({
  // ...
  button: {
    cursor: 'pointer',
    borderRadius: '4px',
    // ...
  },
  buttonDark: {
    backgroundColor: colors.darkText,
  },
  buttonLight: {
    backgroundColor: colors.transparentBackground,
  },
  depressedButton: {
    backgroundImage: 'linear-gradient(rgba(0, 0, 0, 0.1), rgba(0, 0, 0, 0.15))',
    boxShadow:
      '0 0 0 1px rgba(0, 0, 0, 0.25) inset, 0 2px 4px rgba(0, 0, 0, 0.3) inset',
  },
  buttonDisabled: {
    cursor: 'default',
    // ...
  },
  buttonLink: {
    display: 'inline-block',
    textDecoration: 'none',

    cursor: 'pointer',
    fontFamily: fonts.base,
    color: colors.lightText,
  },
  // ...
});

export const Button = forwardRef(function Button(
  { tag = 'button', style, primary, depressed, ...restProps } = {},
  ref,
) {
  const DynamicTag = tag;
  return (
    <DynamicTag
      {...stylex.props(
        styles.button,
        primary ? styles.buttonDark : styles.buttonLight,
        depressed && styles.depressedButton,
        restProps.disabled && styles.buttonDisabled,
        style,
      )}
      ref={ref}
      {...restProps}
    ></DynamicTag>
  );
});

export const ButtonLink = ({ style, ...restProps }) => (
  <Button tag="a" style={[styles.buttonLink, style]} {...restProps} />
);

TypeScript supercharges these types of "common components". Because all styles are typed, component authors can define allowable properties of the style prop meant to customize the component. (This is another great incentive to switch MITB to TypeScript in the future.)

CSS Variables

StyleX requires using literal values (strings, numbers) for the style properties unless you opt into the CSS Variable support. To use CSS variables, define a separate file with extension .stylex.js.

export const colors = stylex.defineVars({
  placeholder: '#cccccc',
  // ...
});

This is useful to reuse style values across your project.

Additionally, the variables can have their values adjusted in real-time in response to user interaction or media queries. As an example, here's a trick using vars for changing the text color of the ::placeholder pseudo-element of a text input:

// styles.stylex.js
export const workaroundVars = stylex.defineVars({
  inputColor: null,
});

// component.js
import { workaroundVars } from '../../core/styles.stylex';

const styles = stylex.create({
  textInput: {
    [workaroundVars.inputColor]: {
      default: null,
      ':focus': '#aaaaaa',
    },
    '::placeholder': {
      color: workaroundVars.inputColor,
    },
  },
});

Another trick using variables to allow a hovered parent to influence a child:

const styles = stylex.create({
  submenuItemLink: {
    [workaroundVars.borderBottomColor]: {
      default: 'transparent',
      ':hover': colors.lightText,
    },
  },
  submenuItemLinkText: {
    borderBottomWidth: `${submenuItemBorder}px`,
    borderBottomStyle: 'solid',
    borderBottomColor: workaroundVars.borderBottomColor,
  },
});

Workarounds

Custom classnames

Because stylex hijacks the classname and style properties of an element, if your element requires a custom classname, you can employ a trick to get that custom classname to stick:

const customClassname = {
  'custom-classname': 'custom-classname',
  $$css: true,
};

// ...

  <div {...stylex.props(
    styles.menu,
    customClassname,
  )}>

This is essentially the format StyleX compiles down to. It is not part of the standard API, so use with caution.

Dynamic Styles

For cases where the style value is more "continuous", a "namespace" can be defined not as an object but as a function that returns an object:

const styles = stylex.create({
  manaSymbolLayoutMarginTop: marginTop => ({
    marginTop: `${marginTop}px`,
  }),
});

Challenges

After all code was migrated, I went through the UI with a fine-toothed comb and smoothed out the differences. Everything seemed ready to ship until I examined the generated bundle and found, to my dismay, that the main bundle size had grown substantially. It appeared as though StyleX's processing had interfered with tree shaking and ignored my code splitting, placing everything into a giant bundle. A GitHub issue pointing to the Webpack plugin was the likely culprit. A different issue declared that the esbuild plugin worked great. Sounded like a good time to finally ditch Webpack and adopt esbuild.

Disclaimer: the Webpack problem I experienced may have been solvable in some other way while staying on Webpack. Changing bundlers is an extreme measure, but moving to esbuild was on my roadmap, anyway. If memory serves, I may have still experienced some tree-shaking and code-splitting issues after switching to esbuild. Perhaps, it was modifying Babel to generate esm that fixed my issue, but I'm not certain at this point.

Webpack to esbuild

esbuild replaced Webpack and Babel, and I threw out core-js with it. I learned later that the esbuild StyleX plugin still brings in Babel, which must still be configured with some plugins. I believe this is due to esbuild's extension points not giving full AST access like a Babel plugin would.

esbuild is FAST!

This is not a scientific comparison as there were some babel only plugins without an esbuild equivalent meaning babel was doing some extra work. Think of this as a "high level" comparison between a Webpack-based bundling and an esbuild-base bundling of the same application, just to give you an idea of the differences.

Running front end build with linux time:

	Webpack	esbuild
real	0m36.270s	0m14.682s
user	1m11.207s	0m19.242s
sys	0m7.820s	0m3.535s

Configurations

esbuild without StyleX was generating esm modules but generated cjs modules after StyleX was brought into the fold. Thankfully, the StyleX plugin accepts a Babel config. This is the StyleX esbuild plugin configuration that outputs esm modules with code splitting and tree shaking working as expected:

stylexPlugin({
  babelConfig: {
    presets: [
      ['@babel/preset-env', { targets: { esmodules: true }, modules: false }],
      ['@babel/preset-react', { runtime: 'automatic' }],
    ],
  },
  dev: false,
  generatedCSSFileName: path.resolve(__dirname, `${outputDir}/styles.css`),
  unstable_moduleResolution: {
    type: 'commonJS',
    rootDir: __dirname,
  },
}),

All files containing jsx were also changed from .js to .jsx files to work with the esbuild plugin.

Performance Comparison

Styled Componenents Version: 5.3.6

Disclaimer: 6.x was the most recent major version at the time of this comparison, but I didn't want to bother with a major upgrade before migrating to StyleX.

styled-components babel minification enabled in esbuild-based build via the esbuild-plugin-styled-components package with minify, transpileTemplateLiterals, and pure options enabled.

StyleX Version: 0.7.5

Bundle Size

Comparisons were made using the esbuild Bundle Size Analyzer.

Unexpectedly, the StyleX bundle is ~138KB larger, and this doesn't count the fact that 55KB of generated StyleX CSS is now outside of the bundle. Note that these comparisons are just on the minified code and do not take compression into account.

3rd Party Dependencies

Let's first examine the third party dependencies, primarily the CSS libraries. At minimum, we should expect that styled-components and its dependencies @emotion and stylis should be absent from the StyleX-based bundle. It is true that 20KB from styled-components was removed but only 60% (13KB) of its @emotion dependency was removed and the full stylis (6.7KB) remained. It turns out another dependency (react-select) still depends on @emotion and stylis. StyleX brought in its own runtime (@stylexjs) adding 3K to the bundle. The Styled Components branch brought in styled-normalize (2KB) while StyleX brings in the raw normalize.css (1.7KB) (pretty much a wash). Apart from some insignificant changes in other modules due to tree shaking, no other differences existed in terms of third party dependencies. Thus, StyleX saved approximately 30.3KB here (but had the potential to save 45.3KB if nobody else depended on @emotion and stylis). This comfortably makes up for the extra generated CSS file (especially after compression is taken into account).

MITB Sourcecode

We now turn to the MITB source code. StyleX shows a whopping 28% increase (171KB) in the components directory. Across the board, the component JavaScript is larger for StyleX, which is unexpected given StyleX can strip all of the CSS definitions while Styled Components should still contain that CSS.

Turns out this is less common as style definitions can only fully be stripped if (1) the styles used are all local to the file (not imported) and (2) the styles are not applied conditionally. Otherwise, the verbose style definitions stick around but with the style values replaced with their classname, which is often-times longer than the style value itself.

Even when the style definitions are completely stripped away and replaced with classes at build time, the classname attribute requires significant space. Styled Components calculates these classes at runtime, but with StyleX, you pay for it over the wire.

Because StyleX prescribes "All styles on an element should be caused by class names on that element itself.", styles no longer "cascade". With Styled Components, using complex selector rules, cascading selectors act as a sort of "compression" relative to single-style classnames.

The following table describes differences in compression of the index JavaScript bundle.

	Styled Components	StyleX
raw	755.7 KB	866.6 KB
gzip	204.5 KB (73%)	215.3 KB (75%)
br	165.3 KB (78%)	171.5 KB (80%)

StyleX compresses a little better, which would make sense given the style object key names are repeated between the definition and props usage, and the style names themselves (paddingLeft, borderLeftColor, etc.) are repeated amongst the style definitions.

StyleX Generated CSS File

Lastly, a note on the StyleX generated CSS. It weighs in at 55KB, but setting the StyleX useCSSLayers: true option reduces it to 31KB by avoiding the CSS Layers polyfill. The option hasn't been enabled yet because it will take additional work to properly handle normalize.css in a world of CSS layers. The polyfill does compress very well though. To give you an idea, the size of the brotli compressed CSS that uses the polyfill is 9.6KB (83% compression ratio) versus the brotli compressed version using CSS Layers being 9.3KB (70% compression ratio).

Web Vitals

I ran Google's hosted pagespeed service against each environment three times. For Desktop, there was little difference in performance. StyleX had 100ms less total blocking time. The Mobile view demonstrated some starker differences.

The results are displayed in the tables below:

Styled Components (with esbuild plugin)

	Run 1	Run 2	Run 3
Performance	71	68	68
FCP	2.3s	2.4s	2.4s
LCP	3.4s	3.5s	4.0s
Total Blocking Time	710ms	810ms	600ms
Speed index	2.9	3.5	2.9
CLS	0.039	0.039	0.039

StyleX

	Run 1	Run 2	Run 3
Performance	76	76	73
FCP	2.3s	2.3s	2.3s
LCP	3.7s	3.7s	3.8s
Total Blocking Time	410ms	430ms	520ms
Speed index	2.8	2.9	2.7
CLS	0.039	0.039	0.039

StyleX grinds much less. The total blocking time was consistently lower. The Styled Components runs complained about too much main thread work and js execution time.

The other categories were consistent between the two:

• Accessibiity: 94
• Best Practice: 100
• SEO: 83

Takeaways

Component styling is more maintainable with StyleX. Components' styles no longer reference other components (looser coupling). Style specificity (for the most part) no longer needs attention. Just by looking at a StyleX component, you can see where all of the styles originate and which styles will "win out".

StyleX's performance profile is also an improvement. The difference in performance between the two libraries seems inconsequential on Desktop, but StyleX shines on mobile where a snappy interface is key. Because MITB is service-worker-backed and infrequently updated, a lower total blocking time is preferred to a lower bundle size. StyleX doesn't even add that much to the bundle size, and other apps would see a less dramatic rise than MITB given @emotion and stylis are still coming in. It's also worth reiterating that, with StyleX, as the app grows, the total bytes of CSS should remain near current levels.

The migration was a ton of work. From manually migrating the style rules to changing bundlers to fixing bugs, the StyleX migration took much longer than anticipated. Though, moving to a simpler and faster bundler in esbuild also checked off a major road-map item. Ultimately, I'm happy with the decision to have adopted StyleX. While it came with an opportunity cost of more features, it begins to pave the way for MITB's mobile presence.

Thanks for reading!

From the moment I laid eyes on it, I was in love.

No JavaScript. Minimalist styling. Open Source tooling. Founded by an impassioned, idealistic thought leader and hacker.

I pored over the blog and docs in glee. Could SourceHut.org become the new home for Magic in the Browser?

History

Since its inception, MITB was built on a self-hosted instance of Jenkins on DigitalOcean. While Jenkins was the primary purpose, the box tripled as a database replication target and email server. Being a build server, though, required heftier machine specs, and given that builds were relatively rare, it was a lot of wasted resource.

In 2021, DigitalOcean went public, and the following year, prices increased by 20%. It begged the question: was DigitalOcean's simpler pricing model and superior UI still worth the squeeze compared to other cloud providers?

AWS and Azure are the cloud providers that I came to know in my professional career. I had limited exposure to Azure but enough to know I hated the UI and the inflated price. I'd also just taken steps to de-Microsoft my life and wasn't about to succumb to the wickedness and snares of Bill Gates. AWS afforded many opportunities for cost savings such as prepaying in the form of "reserved instances" and stopping instances to avoid incurring cost.

Ultimately, all servers were transferred from DigitalOcean to AWS and that became the catalyst for rethinking the build strategy. The Jenkins instance was expensive and Jenkins itself left much to be desired.

Jenkins

In my opinion, Jenkins time has passed. While it is very extensible, there's a minimum baseline that needs to arrive out-of-the-box for the purposes of building software. Configuration is a trying task- pipelines are an amalgam of plugins rather than a first-class citizens. The community seems to be waning. Plugins are outdated. Blue Ocean failed. I also really despise the Groovy build syntax. Shell commands feel more at home. I wish Jenkins the best and will continue rooting for it, but it's time for me to move on.

I believe there are better alternatives today. JetBrains TeamCity is also free and open source but has the backing of a company. Its pipeline modeling is far superior. I was not looking to run an instance, though, and the price of its cloud service is not amenable to MITB's scale.

SourceHut

SourceHut is the hacker's forge. Here are just a few of its strengths:

• Simplicity - It has the features it needs and those features are built right.
• Speed - It is the fastest git server and web UI I have ever used.
• No Walled Garden - Open Source tools that work over email and do not require registration.
• Mission - Open Source. No ads. No tracking. No outside investors.
• Builds - Shell-based build specifications submitted over UI or API as build manifests. You can log in to the build server itself to inspect build failures!

In SourceHut, named build jobs are not defined like other platforms. Instead, builds are triggered ad-hoc by submitting yaml-based build manifests. SourceHut lacks the familiar notion of a pipeline but offers enough functionality to emulate one. With my strong desire to migrate to this platform, I treated this as a puzzle to be solved rather than a hurdle. This is how I went about things.

Each repository can define a top-level .build.yml build manifest, which automatically runs on each check-in. Here is the build manifest for mitb-front, the frontend repository for MITB, which builds, tests, and if the branch is master, deploys to staging and runs functional tests.

image: ubuntu/22.04
arch: amd64
repositories:
  nodesource: https://deb.nodesource.com/node_20.x jammy main 1655A0AB68576280
  google-chrome: http://dl.google.com/linux/chrome/deb/ stable main 7721F63BD38B4796
packages:
  - nodejs
  - google-chrome-stable
secrets:
  - <redacted>
  - <redacted>
sources:
  - git@git.sr.ht:~msoukup/mitb-front
  - git@git.sr.ht:~msoukup/mitb-infra
tasks:
  - init: |
      cd mitb-front
      echo "export CURRENT=$(git rev-parse HEAD)" | tee -a ~/.buildenv > /dev/null
      echo "export MASTER=$(git rev-parse master)" | tee -a ~/.buildenv > /dev/null
  - install: |
      cd mitb-front
      npm i
  - build: |
      cd mitb-front
      npm run build
  - test: |
      cd mitb-front
      npm t
  - deploy_stage: |
      if [ "${CURRENT}" = "${MASTER}" ]; then
        mitb-infra/pipeline/deploy-mitb-front.sh stage mitb-front/build/mitb-front.tar.gz
      else
        echo "Skipping deploy stage"
      fi
  - func_test_stage: |
      if [ "${CURRENT}" = "${MASTER}" ] && [ -f ~/.mitb-functional-tests ]; then
        mitb-infra/pipeline/run-func-tests.sh
      else
        echo "Skipping functional test stage"
      fi
artifacts:
  - mitb-front/build/mitb-front.tar.gz
triggers:
  - action: email
    condition: failure
    to: <redacted>

Any other build manifest has to be submitted through the UI or GraphQL API. Shell scripts are the natural way to call the GraphQL API, but we'd like to keep the build manifests themselves in yaml files. The following script, build-runner.sh, accepts a path to a build manifest and optionally an envsubst shell-format for substituting environment variables in that manifest.

#!/bin/bash

if [ $# -ne 1 ] && [ $# -ne 2 ]; then
  echo "Usage: $0 build-manifest-path [envsubst SHELL-FORMAT]"
  exit 1
fi

BUILD_MANIFEST=$1
SHELL_FORMAT="'$2'"

if [ -n "${SHELL_FORMAT}" ]; then
  BUILD_MANIFEST_CONTENT=$(cat ${BUILD_MANIFEST} | envsubst ${SHELL_FORMAT})
else
  BUILD_MANIFEST_CONTENT=$(cat ${BUILD_MANIFEST})
fi

GRAPHQL="mutation {
  submit(manifest: """${BUILD_MANIFEST_CONTENT}""", secrets: true, visibility: PRIVATE) {
    id
    created
    status
    owner {
      canonicalName
    }
  }
}"

STRINGIFIED_JSON=$(echo "${GRAPHQL}" | jq --raw-input --slurp)

RESPONSE=$(curl -s 
--oauth2-bearer "${OAUTH_TOKEN}" 
-H 'Content-Type: application/json' 
-d "{
"query": ${STRINGIFIED_JSON}
}" https://builds.sr.ht/query || exit 1)

JOB_ID=$(echo "${RESPONSE}" | jq .data.submit.id)
USERNAME=$(echo "${RESPONSE}" | jq --raw-output .data.submit.owner.canonicalName)

echo "${RESPONSE}"
echo "https://builds.sr.ht/${USERNAME}/job/${JOB_ID}"

In addition to the build.yml present at the top-level of each repository, I've created build manifests for the following additional tasks:

• Run functional tests on any environment
• Release to production

Give SourceHut a try! You'll be glad you did.

In 2012, Ron Paul ran on a platform of real spending cuts. His plan sliced the federal budget by a trillion dollars year one. The pundits claimed he would crash the economy. When you need to level a condemned building, do you do so through a controlled demolition, or do you allow the building to collapse on its own terms (while occupied)?

Congress does not believe in real cuts. They've duped the public into believing that "averting disaster" means raising the debt-ceiling. (What good is a ceiling that is so easily raised?) All manner of temporary fixes are preferable to actual problem solving. Elections are decided by who can promise the most free stuff to the largest number of people while keeping the straightest face. Incumbent "public servants" must also justify their previous terms in office. If you repeat a lie long enough, people will start to believe it. Likewise, career politicians are really good at getting re-elected.

But it's not just our elected officials that are to blame. Some are just money and/or power junkies in search of their next hit (God bless 'em). The bigger blame lies on their suppliers- the unelected officials of the private Federal Reserve. For government, the Fed enables unfettered debt monetization. For banks, the Fed administers "quantitative easing" (spoooky language). The Fed chair, Janet Yellen, has the power to send shock-waves through the entire financial market with one poorly chosen word. (If that's not the sign of a healthy financial system, I don't know what is.) Here's a question: What would we ever do without the Federal Reserve? "Well," you say, "without the Fed, the markets would be quite volatile, leading to market crashes and potentially even depressions." Wait.

Regarding the Great Depression. You're right, we did it.-Ben S. Bernanke

The Fed has begun easing the easing, and now, we wait with bated breath for what could be a tsunami of financial ruin. Assuming that the current "recovery" is only the short-term result of massive stimulus spending (an "interest-rate recovery" as Gerald Celente puts it), the Fed will soon be forced to pause the tapering before reversing course, increasing stimulus even more dramatically. That reversal will leave the markets quaking. Continuing to taper will dissipate the mirage of a recovery.

But, it's not like other countries are free from their own economic problems. Central banks the world over have employed usury to subjugate their populations, and governments are printing money left and right. When debt that is mathematically impossible to repay goes exponential, countries can choose to default on their obligations or inflate their currency. Since inflation can keep the ponzi scheme going, is harder to detect, and can be explained away by the experts, it is undoubtedly where we're headed. As debt climbs steeply, so too inflation to pay it off. That dollar just won't buy what it used to, and people might need to retire later than planned. Not to mention, high taxes and huge income gaps is the stuff of revolutions. Do you believe "target practice" is the reason Homeland Security bought a billion bullets?

When currencies are being debased in a race to the bottom, who is going to come out on top? The weaker currencies will go from a backing of confidence to a backing of paper. Assuming a massive blow to the confidence in fiat currencies, currencies backed partially by gold may even return to prominence. Regardless, when currencies and trade are at war, holding gold is an excellent hedge. Last year, Germany tried to repatriate a small fraction of its gold holdings from US soil. The US wants seven years to ship it. Why? The vaults are empty. People understand this, and now the value of gold incorporates speed of delivery.

Why can't we see the gold in Fort Knox? Because it's invisible!

Dr. Paul Craig Roberts, former assistant to the Secretary of the Treasurey under Reagan, exposed the Fed's rigging of the gold market. Paper claims to gold (that vastly outnumber the amount of available physical gold) are used to drive down the price of physical gold by selling the paper claims short on a massive scale- a form of naked short-selling. A strong gold price reflects a weakening dollar and threatens the dollar's status as the world's reserve currency. Asia's demand for physical gold will eventually implode this manipulation.

The Fed is testing the limits of this economy. Creating so much wealth without creating value is a recipe for financial Armageddon. If 2008 is any indication, they could again be caught off guard. The petrodollar and the dollar's status as reserve currency have really been the Fed's saving grace. Once countries start dumping their dollar holdings (China), start accepting other currencies for oil (Russia), or start trading in other currencies (BRICS) or directly in gold (Iran), the dollar will be under even more pressure. The Fed's tapering or gold manipulation will also force a correction in the not too distant future. Now is the calm before the storm.

Following its humiliating defeat by Russian, English, and American hands, Washington was forced to rescind its demonization campaign of the Syrian regime. Syria agreed to disarmament, and Iran quickly followed suit, proclaiming a willingness to ease its own nuclear endeavors. Without skipping a beat, Obama changed his tune from bellicose rhetoric to peaceful diplomacy and was hailed. The planned destabilization of the region was put on hold, but not before triggering the totalitarian alarm clock- an alarm clock that awoke millions of Americans from apathy. Battle-hardened America awaited its next challenge- defending against an attack on its healthcare.

Officially titled "The Patient Protection and Affordable Care Act," the bill (unsurprisingly) neither protects patients nor negotiates affordable healthcare. Again, we are presented with another gross abuse of language revealing just how lawmakers perceive the public (malleable idiots). Our Conmander-in-Chief went on tour across the country, painting half-truths and misdirection on a canvas of trust and naïveté.

Stephanopoulos: But you reject that it’s a tax increase? Obama: I absolutely reject that notion.

Obama said the penalty is not a tax, but then it is. It is an unapportioned direct tax, yet it's legal. The supreme court argues that it's not a direct tax because not everyone is required to pay it- "it is triggered by specific circumstances." Note the colorless, indirect language. What they meant to say is, "it is triggered by a refusal to purchase private health insurance." I'm pretty sure that's called fascism.

If you like your plan, you can keep your plan. Period.

Patients were quickly informed by their insurance companies that they could keep their plan... if they didn't mind paying double the price. The individual mandate and universal coverage creates artificial demand for health services, and increasing demand without proportionately increasing supply means increasing price. Add in a couple rolls of red-tape, and you've got a de facto 100% increase in price.

Here's a paradigm shift: why not actually spend that money to improve health. Buy quality food, vitamins, health books, and club memberships. What did people do before health insurance? Moreso than today, they were their own doctors. The problem isn't insurance companies. Insurance companies are, ironically, a symptom of a flawed medical system. There's no real incentive in finding a cure when you're dealing in a trillion-dollar-a-year industry. Modern medicine is set up to nurse symptoms until the patient runs dry. Did you really think the apex of modern medicine was epidemic levels of debilitating disease? Now that the insurance companies have us mandated, they're going to try their hardest to convince us it's worthwhile. How would finding cures and promoting true health make insurance worthwhile? It doesn't fit the for-profit model. There's a reason we still drive cars that run on gasoline.

If they're seriously counting on the young adults of this country to offset the increased costs, they're living in a fantasy land. Young people are already debt-enslaved from the allure of a college investment that, in many cases, won't be paying dividends in this faltering economy. They're concerned with paying off that debt, not spending an extra $2500 a year for what is essentially zero value. Social Security and Medicare payments are already fleeting before their eyes. Most young people will undoubtedly pay the tax for the first two years. Of course, human behavior is not hard to predict, and they would have seen this coming from a mile away. This begs the question: was it designed to self-destruct from the beginning?

Financial collapse is the ultimate goal but not before the public has accrued an unsustainable amount of debt. The dark agenda of Obamacare is to further tighten the shackles of voluntary debt-slavery. When the economy collapses, the public will be so broke that it will have no choice but to accept the lawmakers' most finely crafted, tyrannical legislation. What will trigger such a collapse? It may be a bail-out of the struggling health insurance companies. The world would bear witness to the government's repeated failure and the dollar's fragility. The question is whether the American people would submit to yet another bail-out.

The sheer amount of red-tape creates a belief that the government is interfering with the insurance companies to their detriment. Obama essentially rewrites the law through decree and now the insurance companies have to adjust. But let's be clear- it's definitely in their favor. Just check out the health insurance index on the NYSE. This belief will fuel sympathy (misdirected) towards the health insurance companies and potentially beget a public opinion that is more accepting of an insurance company bail-out. Problem-reaction-solution at its finest.

They're betting on Americans remaining silent. Surely this is the straw that breaks the camel's back. Will America stand for it?