PageLines is NOT Dreamweaver

As PageLines readies itself to launch V3 (DMS), they’ve been posting some teasers on their blog. I think it’s a great approach, because it builds momentum for the launch. There’s nothing worse than working on a product for so long, launching, then blinks out of existence. Instead, a multi-phase launch with controlled leaks are a great way to keep the public engaged.

But apparently some people don’t like this, because the amount of trolling that’s been going on in the comments is unreal to me. But, with that part aside, I want to take the time to talk about why comparing PageLines to Dreamweaver is fucking moronic.

“yes the Pagelines Framework & DMS are tools (to me at least – no different than Dreamweaver) – ”

Dreamweaver left along with your mom 10 years ago. Developers these days, at least I hope to god, are using code editors like Sublime coupled with a preprocessor like LESS, SASS, or what have you. The number of libraries we can utilize in our projects is staggering, and combined with WordPress, there’s no reason for Dreamweaver to even be included in your workflow (unless they are completely static, non-editable, non-wordpress geo-cities websites from the 1890′s).

Alas, I’m not here to bitch about Dreamweaver. I honestly don’t have any issues with it (never personally used it), so if you’re using it, that’s your own deal. But I do want to list some reasons why, not using PageLines is actually more work.

PageLines Sections only run code on the pages they are used on. This is huge because you don’t have to muck around with conditionals making sure scripts are only loading on this one page, in this one category, by this one author. If the section isn’t on the page, it’s code isn’t running. Period.

Section API
The section API is extensive, and includes every thing you need to build custom sections. This includes both the markup, and the business logic (options).

Option API
The Option API is what makes the sections API shine. Options for select, image upload, text, text areas, and more. Everything is also documented with examples, so building an option panel for a section, or even a theme, takes, literally a few seconds. And it works, every time, without fail, and without having to write anything extra.

Not here to compare or argue about pre-processors. PageLines utilizes LESS, so that’s what we use. SASS is little more powerful, but LESS has everything you’ll ever need to use a section to provide full color automation. And this is the key here. Not only do we have the benefit of not having to right a shit ton of code, but we have the added benefits of cross-browser compatibility, and dynamic relationships between selectors and classes courtesy of LESS functions, mixins, and guards.

On-board Compiler
You don’t even have to muck around with a compiler, because PageLines has it’s own on-board, real-time LESS compiler.

Clean Theming
This, IMO, is the best around, period. PageLines has a /less directory, with a million .less files. These .less files have the styles for the framework. These styles, get compiled, and processed into CSS that the browser can read. What’s neat about this, is when you have a child theme. If you create a /less directory in your child theme, and you copy (NOT MOVE) one of the files from pagelines/less into yourchild/less, it will skip PageLines and instead compile yours. This means there is ZERO css over-writes. Clean CSS. Don’t want the reset? Copy it over to your child, and erase the contents. No worrying about battling specificity, and none of that !important devil business.

At it’s core, and older version of Bootstrap before they fucked it all up. There’s the grid, js components, buttons, tabs, etc. You name it, PageLines has it. The responsive grid alone is worth it’s weight in gold. The entire framework is responsive. So while you’re pecking along in Dreamweaver, we’re over here with a code editor and a browser resizing it every 5 seconds to make sure it’s awesome on mobile.

While I rarely use these, it’s a plus of the framework. There are some that say shortcodes should be in a plugin, and I do agree, but frameworks are the exception to the rule. A framework is everything you need to make a great site, and shortcodes should be included in that for the end user.