Node.js is an event-driven platform. A good analogy to explain this would be waiters at a restaurant. The way Node works is that a waiter greets guests at the door, seats them, and goes back to the door to seat the next group of guests, and then after a while goes back to the table of the first group and takes their order, and then in between seating new groups visits the previously seated guests to take their orders. This is an efficient approach where every spare moment is used to attend to a waiting task.

On the other hand, the way a typical LAMP stack (Linux, Apache, MySQL, PHP) works is that the waiter greets guests at the door, seats them, and then stands at the table awaiting their orders. To enable the restaurant to serve more guests it hires several waiters, all of whom take this seat-and-wait approach.

So the upshot is Node requires less resources than LAMP. And instead of waiters we’re talking about memory and processes and less waiting. Nowadays there is a massive amount of infrastructure designed around the LAMP stack to do with load balancing and caching and other performance-enhancing mechanisms, and many of these allow improved scalability, but the fact is Node provides this by default, without the need of extra bits and pieces.

Also given that JavaScript is client-side already, a homogeneous  approach using one language to rule them all for application development on both client and server is very appealing. You can hire a JavaScript pro and you’re’ good to go.

The post Node.js will kill LAMP appeared first on Web Coder.

The secondary unit of content in WordPress is a Page. It’s just like a Post except it doesn’t have categories or tags and is not listed by date. Posts are used for blogs and Pages are used for other pages(obviously), for example About, Contact, etc.

WordPress allows you to create other kinds of contents aka Custom Post Types which can be called whatever you like, e.g. Product or Movie or Profile and these can behave like either Posts or Pages depending on your preference. You can create these either through code or via point-and-click using one of many plugins available for this purpose.

You can also add fields aka custom fields or post meta fields besides the title and body content. For example with a Product custom post type you could have a price field or a colour field containing a list of check boxes for each colour. Like Custom post types, custom fields can either be specified via code or by way of plugins, most notably Advanced Custom Fields (ACF).

ACF lets you specify which custom post types (or even standard Posts and Pages) have which custom fields, and offers a variety of field types such as text inputs, date pickers, colour pickers, image and file fields, the list goes on.

ACF even has add-on plugins that enable any field to act as a repeater so that you don’t need to specify ”image 1″ and “image 2″ fields but instead can have a single “images” field with multiple entries. You can also create collections of custom fields that can be reused by different content types. You can also modify the display of edit pages and hid or change that layout of the default fields.

So armed with custom post types and custom fields you can build any website. Also WordPress has several features that work out of the box, batteries included, such as comments and user registration and password reset, both with confirmation emails.

Some other CMS are said to be better for building ”advanced” websites (whatever that means)  but typically there’s a fair amount of assembly required or too many moving parts. The simplicity of WordPress is what makes sit so flexible.

So when a developer or agency says that WordPress is just for blogs or that you need to use a “lower-level” framework or “more powerful” CMS, tell them they’re a bad developer or agency.

Because if they were any good they could customise WordPress to build your site as you’ve now discovered.

The post WordPress all the things! appeared first on Web Coder.