99% of the time because I work with accessibility needs, JavaScript doesn't even play into it... but, IF I'm building a static website I'll still use a degree of PHP to glue the common bits of all pages together, as well as to add so-called "friendly URI" support.
Though what I first do is, well... go the semantic markup and progressive enhancement route which means I:
1) Start in a flat text editor with the content or a reasonable facsimile of future content for the main page, and organize it so it makes sense as if HTML and CSS didn't even exist.
2) Apply semantic markup (basically everything EXCEPT DIV, SPAN, ID's, and classes) to that content; semantic markup being a sick euphemism for "using HTML properly" since the tags should be chosen based on what things ARE, and NOT what you want them to look like!
3) bend that markup to my will to create the layout, adding DIV, SPAN, ID's, and classes where and only as needed as the external stylesheet hammers things into shape. For this step I start with the desktop layout and then use media queries to make it responsive. I go large to small because we cannot target legacy desktops with media queries, so that HAS to be the starting point! All the "mobile first" nonsense seems to be parroted by people who cannot grasp that simple truth.
Fact is you are more likely to get visitors on legacy browsers for desktop who don't even support media queries, than you
I then repeat this process by plugging in content for various sub-page types.
IF I get JavaScript involved, it is to enhance existing functionality or apply things like advertising, bugfixes, and so forth. I rarely code in a manner that the page isn't at minimum usable to get at the content scripting off -- since if it doesn't work scripting off all you've built is a WCAG violation.
The CLOSEST I get to a "starter kit" would be the basic HTML I apply around the content at the start of step 2.
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
<meta
name="viewport"
content="width=device-width,height=device-height,initial-scale=1.0"
>
<meta
name="keywords"
content="seven,or,eight,single,words,from,body"
>
<meta
name="description"
content="natural language text describing the page"
>
<link
rel="stylesheet"
href="screen.css"
media="screen,projection,tv"
>
<link
rel="shortcut icon"
href="/favicon.ico"
>
<title>
PAGE_TITLE - SITE_TITLE
</title>
</head><body>
<div id="top">
<h1>
<a href="/">
SITE_TITLE
</a>
</h1>
<ul id="mainMenu">
<li><a href="home">Home</a></li>
</ul>
<div id="contentWrapper"><div id="content">
<hr><!-- remove if content starts with <h2> -->
Page Content Here
<!-- #content, #contentWrapper --></div></div>
<div id="extras">
<hr><!-- remove if sidebar starts with <h2> -->
"SideBar" content Here
<!-- #extras --></div>
<div id="footer">
<hr><!-- remove if footer starts with <h2> -->
Footer Content Here
<!-- #footer --></div>
<!-- #top --></div>
</body></html>
The double-wrapper for content is for negative margin float. Holy grail is cute, but too fragile and too hackish for "but... but... you waste an extra DIV!?!" -- the laugh being the people who cry that in favor of Holy Grail seem to have no problem pissing all over the rest of their code with DIV for nothing and endless pointless classes for even LESS.
Some people would argue the height=device-height in the viewport meta is pointless and unsupported -- tell that to my old Icoo tablet and my current Cubot phone which BOTH screw it up using the "lie" height as width when in landscape view.
Oh, and HTML 5 validation bitches about "projection" and "tv" -- **** that noise. Given what media targets are FOR the specification has ZERO damned business telling us which ones are 'valid' or not as that stifles hardware and browser innovation. But what can you expect from a specification clearly made by people who never grasped the intent much less the logic of HTML 4 Strict.
Then I use a CSS reset. There are smaller resets, like the so called "universal" * { margin:0; padding:0; border:0; } but that can wreak havoc with form elements between Firefox and IE since they apply their own rules separate from what CSS can control... and there are larger resets like "Reset Reloaded" which are so big they usually border upon being a framework unto themselves... they waste time changing values that are NOT inconsistent across browsers.
/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,dl,dt,dd,
table,tr,td,th,p,img {
margin:0;
padding:0;
}
img, fieldset {
border:none;
}
At a quarter K it's not so massive as to be a bandwidth issue, and it only hits what NEEDS to be hit.
Then I often also have a few bugfixes, as well as personal preferences.
hr {
display:none;
/*
HR in my code are for semantic breaks in topic/section, NOT
style/presenation, so hide them from screen.css users
*/
}
@media (max-width:480px) {
/*
Some older small screen devices will try to force a text-size
adjustment regardless of our viewport meta, this overrides that
so it obeys what we tell it. This is in a max-width query so that
we don't send this to desktop safari, as it breaks zooming there...
Even though it does NOT break zooming in mobile Safari?
Way to herpa that derp there Apple!
*/
* {
-webkit-text-size-adjust:none;
-ms-text-size-adjust:none;
}
}
The comments pretty much explain that. Remember, HR is basically a second depth heading without text -- it MEANS "a change in topic or section" and does NOT mean "draw a line across the screen" ANY MORE than H1..H6 "means" text in different weights and sizes.
As the saying goes:
If you choose your HTML tags based on their default appearance, you are choosing all the wrong tags for all the wrong reasons!
Hence why with H1 being the heading that everything on every page of the site is a subsection of (and should be your first content-bearing tag), H2 meaning the start of a major subsection of the page, H3 meaning the start of a subsection of the H2 preceding it, H4 meaning the start of a subsection of the H3 preceding it and so forth... well... why the **** did the WhatWG think we needed SECTION, ARTICLE, NAV, HEADER, FOOTER, ASIDE, or MAIN for again?!? Of course if you bother leveraging semantics and content of value what purpose does Aria serve again? Oh, that's right, two things -- and Jack left town!
We really need a 5 Strict or something to kick the pointless redundancies aside the way 4 Strict told HTML 3.2 to suck it.
But in any case from there I slice it up into PHP functions like template.header which outputs everything before the primary content area, template.footer which outputs everything after the content area such as sidebars and (duh) the footer... and then have PHP glue together the requested pages as needed.
No fancy "templating system" BS needed since PHP is a perfectly good templating system all unto itself, PARTICULARLY if you bother using separation of presentation from content meaning the REAL template is in your external CSS file, not the damned markup!!!
Hence why <style> is epic /FAIL/ at web development, and why style="" should only be used in a handful of corner cases -- and why BOTH are blocked by default if you need to use the Content Security Policy.