3 ms·
Are you suggesting that using HTML5 Boilerplate is a bad idea? Because no, no it isn't. That is an insane assertion. The number of weird idiosyncrasies or brows
by tomasien 13y ago
Are you suggesting that using HTML5 Boilerplate is a bad idea? Because no, no it isn't. That is an insane assertion. The number of weird idiosyncrasies or browser specific problems that WILL come up with any web app that I've fixed by just saying "hmm, wonder if I put in HTML5 Boilerplate" are insane. It creates 0 technical debt, you will always be happy you started with it, and it is fantastic.
I do no understand the big about reset.css either but I guess I"m willing to listen? Reset.css has also been a lifesaver.
For a blog making a really important point (don't just use Angular because you've heard of it, use what gets shit done), suggesting that boilerplate creates dependancies that you will regret having seems out of place.
- Gigablah 13y agoCSS frameworks, boilerplates and reset.css could probably be condensed into a single point. (HTML5 boilerplate already contains some form of reset.css anyway) I guess some people just like to write their frontend code from scratch...? It's funny because the author wrote Zepto, of all people he should know about abstracting away cross-browser concerns.
- tomasien 13y agoRight? Man I feel like I'm missing something huge here if somehow reset.css and HTML5 Boilerplate are creating technical debt for me. I think I've launched at least 10 projects using it and I've never once had to say "oh that's a weird thing that HTML5 boilerplate does, here's how you compensate for it" like you have to do with Bootstrap or Foundation or things that DO create debt.
- awinder 13y agoI think the point was that they weren't completely necessary, and it would create a dependency on their continued use? I'm not sure, but that's what I got, and I don't agree. NOT using CSS frameworks creates a pretty radical dependency on NOT using them in your design going forward. Sometimes the costs of not doing or using something create a lasting debt. There's an alarming stench of NIH in some of the authors points, co-mingled with some more salient points about not over-engineering up front.
- Chris_Newton 13y agoIt creates 0 technical debt That’s a bit of a stretch. The current version of HTML5 Boilerplate includes several things in the header that probably aren’t exactly what you want, particularly if you’re supporting mobile devices. It loads 4 distinct JS files. One of those is Modernizr, which is loaded at the top of the page and will therefore block, and there’s a custom class on the HTML element to go with it. It loads 2 distinct CSS files. It inherently has potential security and privacy issues that come from using any third party servers, in this case Google Analytics and attempting to load jQuery from their CDN. Likewise, it has dependencies on some third party scripts, both Modernizr and the ones for Google. And it contains an unprofessional nag message for users of IE8. This is not a criticism of HTML5 Boilerplate. All of the defaults mentioned above might be a good fit for some projects, even many projects. However, none of them will be suitable for all projects, so the moment you start from HTML5 Boilerplate you almost certainly have some technical debt to pay off, just like any other template or framework or scaffolding system.
- Gigablah 13y agoYour points sound suspiciously like premature optimization... and I'd argue that is exactly what you DON'T need.
- Chris_Newton 13y agoHow did only adding parts that are relevant to the current project become some sort of “optimization”? There is more work to do if you start from someone else’s boilerplate that has lots of parts you don’t want, because you have to actively delete things that you need to replace or just don’t need at all. In any case, some of the defaults in HTML5 Boilerplate can have real negative consequences if you just use it without fixing them. If your market will be using mobile devices a lot, or tends to have limited connection speed for any other reason, then making half a dozen extra requests before you even start doing anything interesting can have a significant impact on performance. Playing around with viewport settings can have significant adverse effects for usability if you don’t know what you’re doing. That little message about IE8 that isn’t going to show up on the recent browsers your developers usually use is going to get you in trouble with a client one day if you develop a lot of intranet sites and forget to remove it.