code-standards
code-standards copied to clipboard
isobar-us
Content: Markup Section
Markup section changes here.
For specific edits, please still file a ticket, this is mostly ideas to toss around.
https://github.com/isobar-idev/code-standards/wiki/Useful-Links-and-Resources#html5
https://github.com/isobar-idev/code-standards/blob/master.next/content/en/html.md
re: https://github.com/isobar-idev/code-standards/wiki/Useful-Links-and-Resources, do we want to make mention of any of the frameworks like Angular, Ember, React, etc? I did see a link to a resource about backbone (and of course jQuery). Or perhaps there is a different/better place for this? I did not see any mention in the JS section either (https://github.com/isobar-idev/code-standards/blob/master.next/content/en/javascript.md).
My guess is the JavaScript section was last touched for content in 2011 which was when things were all jQuey all the time and the emberactular conglomerate wasn't even a glimmer of a hope.
For that, of course, I blame @rcherny
As an aside, Rob, do you ever go into the office?
I imagine code standards should be stuff that can apply to almost any code you write, any framework. But yeah some of the progressive enhancement content in the doc (like recommending that a form action always goes to a real HTML page instead of only implementing the Ajax submit) does somewhat conflict with using Angular/React, so...we'll need to make a decision on that.
recommending that a form action always goes to a real HTML page instead of only implementing the Ajax submit
This is still the path of being a better human being and web citizen. No one is interested in that though. 50MB of fragile JavaScript is where the cool kids all hang out.
shakes cane
I propose we change the title of this doc from "Front-End Code Standards" to "How to Be a Better Human Being".
@roblarsen Can always bring a smile to my face, Rob. Emberactular, nice. ;-)
Anyways, the new branch that @ben-caplan cites has been touched since then but does need some updates to at the least acknowledge frameworks and libraries etc. Currently it's pretty bare-bones. I think the content might provide advice on intelligent selection and integration, but I think we should steer wide of any preference or "standards" on a given framework.
Aside ... my current project ends in a few weeks and I was hoping to dive in head first...
I personally feel our standards should focus on the standards (W3C, ECMA, etc). Framework Soup is half trendy and half flavor of the week stuff that is very specific to particular needs.
The Wiki Links and Resources can be linked to from the last part of each section, which is somewhat implied at the moment in the draft content we have, but not actually done.
The Wiki Links is intended to be more transient content and does at least point to Todo MVC, for example in the JS section. I think we could link to some of those frameworks we "like" but ... I dunno.
Office? What's that? (in all seriousness, yes, just not that often these days)
Additionally, there are plenty of links out there to other sets of Angular, React, Ember "best practices" etc. etc.
IMHO, we should try to stay close to the metal and a bit more "timeless" lest our content grow stale ... again ... and again, and again ...
IMHO, we should try to stay close to the metal and a bit more "timeless" lest our content grow stale ... again ... and again, and again ...
(serious comment)
(wow)
I think this is the best way to go. As popular as each of these libraries are right now, the hipness factor is strong in this space. To my mind, Rob's right to suggest staying out of the weeds with this stuff and sticking closer to core JavaScript concepts.
One way to cover backreactulembular would be to discuss the smart approach to using one at all. A lot of people just start with one of these frameworks as a default and I think that's simply the wrong way to look at the web (especially an increasingly mobile-centric web.)
Then again, I don't include any javascript until I need to write some.