Frameworks are one of the hugest anti-patterns in software development. They're hard to learn. They limit your creativity. They increase your project's complexity and dependencies. They go out of business and get abandoned. You have to maintain and upgrade your code to match the latest framework versions for no good reason. You have to search for help and ask others for advice when you're stuck. And you probably only need a small percentage of features that the framework offers anyway. They just don't make much sense.

You should prefer core-language solutions to small abstractions to small helper libraries to general libraries to frameworks. Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years. Frameworks are at the far end of software complexity spectrum and you want to avoid them as much as possible. You should be fighting complexity and not embracing it. I don't use frameworks and I encourage you not to use them as well.

In fact, one of the rules for writing software at Browserling is to avoid frameworks at all costs. There must be a tremendous reason to use a framework. So far we've used 0 frameworks and just a few libraries to get things done. I've yet to see someone come up with a good reason to use a framework. Simplicity is the law at Browserling. I've taught my employees well to never choose a framework solution and to try to find the simplest solution starting from the core language and core tools and going up.

Let's go over the reasons why you shouldn't be using frameworks in more details.

Frameworks are hard to learn and this knowledge is generally useless

Frameworks take a lot of time to learn. Instead of learning fundamental tools, core computer science concepts, and programming techniques, you spend time learning something specific and generally useless. Just because someone invented a framework and many people use it doesn't mean you need to learn or use it. People give in peer pressure too easily. "Everyone's using FrameworkA/FrameworkB, I must be using it as well."

No, you shouldn't.

You should be thinking, how do I avoid using this framework? How many actual features or core concepts do I need from this framework? Can I implement these features in a hundred lines of code and be done with it and never depend on this framework? Who are the authors of this framework? Do these guys have a track record of maintaining their code or did they just put it together in a weekend and released it?

Don't learn useless frameworks that have no value.

Frameworks limit your scope of creativity

Frameworks limit the scope of your creativity. Frameworks put you in a box you can't escape. Frameworks make you dumb. Whenever you're faced with a problem you can't just invent a solution; you're limited by what the framework lets you do. You have to seek experts, waste your time and energy to find a solution to a problem you shouldn't have had in the first place if you hadn't used a framework.

You can't let framework authors control what you can or can't do. You should be in total control over your product.

Frameworks increase your project's complexity and dependencies

Complexity and dependencies are bad. You should keep both your project's complexity and dependencies at minimum. If no one controls complexity and dependencies, and no one enforces how software is written, then one dependency leads to another, and soon your project ends up using 25 different frameworks and 5 different programming languages. There should be strict rules what you can and can't use in your project, and someone has to make that call.

Without rules you might save time at the beginning and sound cool using all the latest frameworks, but now your software is so complex that no one understands how or why it works. It's also become unmaintainable. You may not notice it in the first few months as things are moving along quickly, but as your project progresses, your team's productivity will drop because of all the complexity and dependencies. You'll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you're dead.

You should be fighting complexity and not embracing it. Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.

Frameworks go out of business and get abandoned

Frameworks go out of business and new frameworks appear. You have to learn the new frameworks again. It takes a lot of effort, energy and resources. You just spent all that time earlier learning the old framework and now it's out of business. All the skills you accumulated are now useless.

Everyone's hyped about the new frameworks and you don't want to be left out, but in fact you shouldn't even care what they are. Core fundamental tools already let you do everything that these frameworks do and you'll just waste your time learning something that doesn't solve anything new. The more marketing and buzz a framework has, the less you should trust it.

Even worse, framework authors sometimes just abandon their projects or they quit the projects and delete their entire projects. Your entire build now fails because of one author.

Use fundamental core concepts, solid tools and programming techniques that are here for the next 20 years, rather than frameworks and useless libraries. You don't need them.

Frameworks evolve and you have to spend time upgrading your framework versions and other dependencies.

If you wait too long between updates, frameworks have changed dramatically, and you have to spend days adjusting your code and learning the new interfaces. You don't need all the extra functionality the framework developers added. Most likely you don't need anything at all from the new version.

Framework developers can't stop evolving their projects for no good reason. Often software is just done. It does what it's supposed to do and doesn't need any changes ever again. You don't need the latest version of every software. Some of the best software was written 10 or 20 years ago. Use it!

Upgrading versions for no reason is another huge anti-pattern. If software works at version X, then it should stay at version X and should never be touched unless absolutely necessary.

Ask how happy your developers and system administrators are when you have to upgrade from Framework v1.4.3 to Framework v2.0.0. It's the worst time of their lives.

You have to ask others for help

When something goes wrong with the framework or you get stuck, you can't just come up with a solution because you're limited by what the framework lets you do. You have to ask for expert help, wait until someone helps you or pay an expert framework consultant.

If you keep your dependencies to bare minimum, then you're the expert and you can quickly get things done and come up with the solutions without ever asking for anyone's help or advice.

You probably only need just a few of framework's features

I've seen this again and again - someone starts their project with a bunch of full blown frameworks when they only need a few features from each. At this point they have already destroyed their project. "Which frameworks shall we use?" is the wrong question to start you new project with. Start your project with an empty file and use programming and a few helper libraries and core tools to get it going.

Use frameworks only when absolutely necessary

I'm not saying that there isn't a use-case where framework would be good but it should be an absolute exception. The only areas that come to mind where frameworks make sense are mathematically complex areas of computing such as sound processing, image processing, and machine learning, where it would take many months to write the code that does the job. And even then you should try to avoid them.

Friends don't let friends use frameworks

Until next time!

My mission at Browserling is to make developers' lives easier so I decided to create world's largest collection of web developer and programmer tools. I found that I was often googling for things like "json minifier" or "url escape online" and I'd often end up on random garbage websites with ads and tools that don't work and that have tons of options that no one needs.

So I created my own tools and launched Browserling's Web Developer Tools. No ads, no garbage, no bloated dialogs, no useless check boxes, just plain text tools all in one place with the same interface. Press button, get result.

See Announcing programmer tools and I've added another 13 web developer tools blog posts for a more detailed introduction.

Here are the latest tools I've added. Now there are 49 tools total.

Pro tip: You can use ?input=text query argument to pass text to tools.

Next few tools I'm adding are JSON to CSV, XML to CSV and Number base converter. I'll also soon redo UI/UX of the tools to make them much nicer.

Until next time!

What do I do when I'm tired of programming? I do some more programming! I just added 6 different subscription feed formats to Browserling's webcomic. They're Atom, RSS, JSON, Simple Plain XML, YAML and TXT. (RSS) (Atom) (JSON) (Raw XML) (YAML) (TXT)

And extra bonus. JSONP API:

Update: Now also CSV, because why not. (CSV)

Another Update: Now also TSV. (TSV)

Does this have any value? No. Was it a fun side project? Hell yes it was! Fun side projects is what makes you great at what you do. Now back again to main product work. Until next time!

Browserling 0 Comments January 27, 2016

SEO Expert

I just illustrated a popular joke that you've probably heard.

An SEO expert walks into a bar, bars, pub, inn, tavern, public house, Irish pub, drink, drinks, beer, alcohol...
SEO Expert

If you like this cartoon, visit Browserling's webcomic at for more.

Browserling's webcomic is about web developer jokes, web developers, web programmer jokes, web programmers, coder jokes, web coders, web designer jokes, web designers, browser jokes, browsers, internet explorer jokes, ie jokes, programmer jokes, programmers, javascript jokes, js jokes, web development jokes.

Browserling is an online cross-browser testing site, javascript testing, internet explorer testing, browser, browsers, cross-browser compatibility testing, cross-browser css, browser testing tools, browser testing software.

I'm that guy in the picture. Haha. Until next time!

I heard about this new technology called JSX today so I went to JSX's Introduction Page to read more about it. The first sentence said:

JSX is a JavaScript syntax extension that looks similar to XML. 

And this is where I stopped reading. We all hate XML. You can't possibly ever go on reading about this technology further if it's introduced like that. Developers hate XML and don't want to ever hear this offensive word. Every word matters when presenting to developers.

I'll be just fine not knowing what JSX is. Until next time!