Question to web developers out there. How do you maintain DRY HTML? DRY, as in, "Don't Repeat Yourself".
For example, if you have a navigation bar to be shared across every page, what do you do to avoid having to copy-paste this code 10-20 times?
Among the solutions, I found JQuery/JS, PHP, Server-sided includes, iframes, object element, and Python.
Is client-sided, so it relies on the client having JS enabled.
PHP has a handy include function which lets us compartmentalize web components.
This is apparently the HTML equivalent to PHP's include. It requires setting certain flags in Apache, and marking HTML files for parsing in HTML. I think this might be slower than PHP, because I read somewhere that it involves the server re-parsing and updating HTML files every single time they're being delivered.
This is useful for sandboxing HTML, but not so useful when you want JS and CSS to work cleanly across the entire page.
I couldn't find as much information about using object to embed HTML. This might have the same issue as iframe?
Really one could use any scripting language. Basically place special tags in your HTML file, like $$$header$$$, and then perform a find-replace in Python with the appropriate HTML whenever you wish to deploy or run the HTML file.
I had a dream about HTML last night, so this is really bothering me. What do you all think?
For includes, generally I load up a "base" page, then load dynamic content via js. This works well for 99% of cases as most modern browsers support javascript and its not hard to fallback to conventional HTML such as iframes. Though with older or not-as-advanced cellphone browsers this can be an issue.
As far as the 'object', this is in reference to an applet such as flash, java, etc. The browser would load it, then it would manipulate the page. It falls victum to the same security limitations as iframes (with that said, javascript AJAX has the same limitations)
My biggest worry as far as client-side JS goes was accessibility -- would a user be able to see my website if JS was disabled?
A better question was whether or not it's worth keeping no-JS support. This apparently is a whole other debate.
For my purposes, using Go or Node.js just for templating is just over-engineering. Right now I'm leaning towards Python templating.
Edit: I found another principle of sorts called progressive enhancement.
@BlueThen I think it's safe to say you can stop worrying about supporting non-JavaScript users. Just about every modern website requires JavaScript. When it comes to choosing a platform, it's always good to pick one that's relevant, thus Go and Node.js. This isn't a matter of overkill. You just need to demonstrate your point using some sort of platform, so why not choose newer platforms that will draw more attention.
Progressive enhancement or in other words "Responsive Design" has become the norm. This is a matter of scaling your app to any screen resolution. With frameworks like Bootstrap, this is a breeze.
@Bluethen With modern browsers, as many people posted in that reddit thread, very few(less than .1%) of users had JS disabled. With that said, I can understand why a dynamically loaded page, done client side can raise issues. I don't turn an entire site into a blank HTML file then use JS to fill in the rest. I feel html is there for a reason and design my webpage with it, but for nonstatic data JS adds a very clean feel.
@Hawkee Go and Node.js are as you said platforms. BlueThen is asking about the methodology which doesn't change [much] from platform to platform. Progressive enhancement also includes designing your website in such a way that it plays well for users that are disabled and need such things as screen readers, magnifiers, etc.
A friend of mine just developed a simple app using Firebaseapp with no server-side code. The app uses AngularJS, Bootstrap and Firebase for data storage. I find it amazing that we can now develop entire applications without any server-side code. I'm contemplating doing a little writeup on how to make an app like this using their free account. If you're curious the app is here, https://prayerjournal.firebaseapp.com
The context I saw for progressive enhancement talked about layering your website in order of need:
Basically you want your website to still work with everything stripped away but the bare essentials, this is good for Screen Readers, SEO, and No Scripters.
It also makes sense from a "clean maintainable code" point of view. It's hard to say at this point which platforms will be obsolete 2 or 3 years from now, so it's risky when you start relying on some of these newer platforms for the "Bare essentials."
@BlueThen I think that was a lot more relevant a few years ago, but as @SReject pointed out, only .1% of users have JS disabled. When I see companies like Google and Facebook fully embracing JavaScript, I have no problem relying on it myself.
The newer technologies like Node.js and AngularJS make application development faster and easier to achieve. If it takes you two weeks to build something that somebody else can build in two days, you'll have a hard time completing in this sphere.
I was going to make this a page with relevant code, but I accidentally back-spaced out and lost all of it.
Will probably make a page after getting some input from anyone here.