I am currently designing a website for a business. This website will have dynamic areas - such as an "admin" area in the future. But for now, there are going to be 14-16 static pages. Testimonials, products and services, typical corporate pages.
I really like the idea of loading html dynamically with backbone and doT.js. But for this purpose, am I better-served with a multiple-page approach? I've read that single-page designs can harm SEO but wasn't sure if that was still accurate. That is of major consideration for a basically fully static site where content is king.
Is SO a single-page site?
I am using apache2 with PHP/symfony2 for my current multi-page implementation for all of the static pages (and caching them).
It sounds like your site would be better off as static as possible. There's a lot of upside:
It should load quickly, because there's no processing to do, fewer files to load, and once it's sent to the browser you don't have to wait for the JavaScript to run before the page shows.
It will be more widely supported. Everything supports HTML; if your page loads require JavaScript, you might be cutting people off and never realise it.
Search engines will have a much easier time indexing static sites.
It's easier to develop and maintain a simple static site.
It's a lot harder to break. If your page loads require JavaScript and you accidentally deploy a broken script, you run the risk of completely blank pages. In a static site, chances are the text will still show.
Things like Backbone and JS templating are great when you're dealing with dynamic data. Backbone comes in to its own when you have objects that you're showing on a page, and want to build a complex interface to interact with them. But that doesn't sound like your page here. Similarly, JS templating is great if you're sending data to the page, maybe from an AJAX request, and want to render it client-side. But it doesn't sound like that's the case for this project.
In general, try to do the simplest thing that will work. Building the site as a static page will be a good starting point, and if you want to add JavaScript to it later you can build on that foundation.
Related
I'm working on a website I eventually plan on purchasing a domain for and having, hopefully, many users. Of course, a lot of people plan on that and it never comes true! Regardless, I'm progressing forward with the intent of having a good looking interface that's efficient in it's data usage.
One thing I would very much like to do is to have my banner / header and side-bars persist when they navigate to separate pages inside my site. My header contains the site-wide context menu as well as login and profile information, and the side-bars are currently undecided, but potentially just static images.
I don't know exactly how I would do it well. I could just use my PHP session object, but I'd like to be as efficient as possible.
I'm using a traditional LAMP stack, HTML, JS and CSS (using the Bootstrap library) on Ubuntu on an Amazon's EC2 service.
You could create a file with header and sidebar and then use this php code:
include("nameofthefile.php");
on every file of your site
I have been developing a application for 8 months now that has been utilizing Smarty for PHP templates.
I have had no problems at all with Smarty, and I have started to add more JavaScript interactions for the users on the site.
I was thinking of using backbone.js to template the JavaScript as well.
But another thought came to me, would it be bad idea to return a smarty template and load it in the div rather then return a json and use backbone.js to format the results?
Would this slow the application in anyway? What are the benefits (if any) and disadvantages to doing this?
Any thoughts would be great,
Thanks
With a normal multi-page "web site", users navigate from page to page consuming the site's features. Backbone however works best with a single-page "web application" model. With this approach, the only html page loaded is the first one; after that, every "page transition" is actually handled by Backbone's Router, which fakes page transitions dynamically via DOM manipulation. Each new page's elements are in turn built out of Backbone Views; PHP-generated html is never involved.
And that's why Backbone may not be the best fit for you. Unless you want to change your PHP code to be purely a server-side API-style structure (which wouldn't really need Smarty), much of Backbone's value is going to be lost.
I have a small project about a dynamic database driven website which is users can post, comment, like,... on it.
and I was thinking about creating html pages instead of php pages.
for example after someone posts sth a php code will create a html page for that post and people can comment on it. while submitting a comment, an ajax call to a php page will save comment data to database and write that comment to the html file.
I thought it could be a good way to reduce server load. and have advantages for SEO.
Does this technique have a name? and Does it have any more advantages or disadvantages?
Thanks in advance
There's a flat-file blogging engine called Kure. It's an open-source project so feel free to check it out. "Flat file system" would be the closest thing to a name for this technique.
I have to agree with my SO colleagues here. Servers and even personal computers are, for the most part, more than capable to handling what you're describing using a real database. Blogging engines such as Wordpress, are incredibly powerful and flexible and will save you a lot of hassle down the line.
That said, if you insist in creating your own flat-file system... more power to you. Good luck.
Yes, it is a known technique for optimizing serving of relatively static pages. By 'relatively static' I mean "dynamic, but update rarely".
For example, Yandex (a search engine) uses this to serve its main page. It's pretty rich page, and it would require significant resources to generate it on each request.
Also, there is (at least, there was) a plugin for Wordpress that does this.
You can't use this technique if your pages update often (it will not worth it).
You can't use this technique if your pages are personalized (that is, if you can't serve the very same page to all your visitors).
I don't know any name for this technique. I know it's already been used for some big sites in the past but I'm not sure it's still used because it's not always easy to handle and if a file is corrupted because of a script, other scripts working with the page can make it even worse.
I'm a student programmer for a company, and the lead developer is making a huge push to use Dreamweaver templates for our new site with vague reasoning pointing to performance benefits.
I'm not convinced…why would one use Dreamweaver templates over a PHP or a Javascript template engine? Especially since we're still using a LAMP stack for pulling in dynamic content.
So: What are the benefits of using Dreamweaver templates for our site pages, and why would one use them over PHP or Javascript?
You'd use DW templates if you were building a purely static website with no interaction beyond following links. The template will allow you to make changes to the page layout, and all your pages will be updated to reflect the changes you made. You will have to reupload every page that uses the template in question, however.
As soon as you need more interactivity than simple navigation, or need to present data that changes over time, you've gone beyond the scope of what a DW template can reasonably do. When you get to that stage, you'll need some kind of server-side scripting language (PHP, Perl, Python, something beginning with P :) )
It sounds awfully like someone in management has heard that DW has templates and has latched onto that idea without really understanding what templates really are. Whilst it can be argued that they can improve performance in certain circumstances (a non-scripted web page will consume fewer server resources to run than a PHP script, for example), they aren't really suited to maintaining big sites, especially not if said sites require more interactivity/data presentation than DW templates can offer.
Dreamweaver templates are just unusable for the dynamic site. You can't, for example, create a template to print out 10 recent news titles. You need some server-side engine for this.
JS is not the way to go too.
I've been trawling SO for a couple of hours tonight looking for some answers, but I've not found anything that really answers what I'm after. My apologies if it has, in fact, been answered already.
I'm designing a new website and I'm trying to decide on the architecture to use to serve the content. In the past, my websites have used PHP feeding data into Smarty templates.
However, recently at my work, I've been working on a Java web application where jQuery was used to retrieve the data from a RESTful API (which returned JSON), where HTML template pages were used as the base and javascript was used (utilising jQuery) to fill in the content.
My question:
The website I'm designing will be in PHP, but would it be better to construct (or use an existing) RESTful API or to continue on as I've done before feeding the data into Smarty templates?
Are there real benefits to one or the other, or does it just come down to developer preference/experience?
If it helps, the website will be for a church, where the content types will be CMS-like; news/announcements, wiki-like pages, and a limited type of social networking (for the minister to communicate with parishioners).
Short answer: It sounds like filling the content with JavaScript would not be useful in your case. Loading the data with JavaScript is adding a layer of complexity with minimal or no benefit (in your case). Take a look at CMSs and websites that have similar functionality to what you're doing. WordPress, Drupal, etc.
For an example of when it might be useful to load data with JavaScript, check out the tags section on this site. When you search for a tag it queries the server without reloading the page. However, the initial tag list is loaded during the initial page load without any JS.
Here are some cases where you might benefit from loading information with JS:
There is some data that will take longer to load. For example, you're getting data from a web service. Using the traditional method, you would need all the data you need for the page to be available before it can be displayed. If you loaded that data with JavaScript, the page could load and the slow data would appear when it returns. Realistically, you would probably just cache the data but this is just an example.
You will be getting more data as the user stays on the page. You might want to update the page without refreshing.
You want the user to be able to query more data without refreshing the page.
Your users have limited bandwidth (mobile).
This site has more guidelines: http://www.oracle.com/technetwork/articles/javase/index-137171.html