Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content: Markup Section #44

Open
rcherny opened this issue May 22, 2013 · 12 comments
Open

Content: Markup Section #44

rcherny opened this issue May 22, 2013 · 12 comments

Comments

@rcherny
Copy link
Contributor

rcherny commented May 22, 2013

Markup section changes here.

For specific edits, please still file a ticket, this is mostly ideas to toss around.

@rcherny
Copy link
Contributor Author

rcherny commented May 22, 2013

@rcherny
Copy link
Contributor Author

rcherny commented Nov 8, 2014

@ben-caplan
Copy link
Contributor

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).

@roblarsen
Copy link
Contributor

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.

@roblarsen
Copy link
Contributor

For that, of course, I blame @rcherny

As an aside, Rob, do you ever go into the office?

@ericdouglaspratt
Copy link
Contributor

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.

@roblarsen
Copy link
Contributor

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

@ericdouglaspratt
Copy link
Contributor

I propose we change the title of this doc from "Front-End Code Standards" to "How to Be a Better Human Being".

@rcherny
Copy link
Contributor Author

rcherny commented Jul 23, 2015

@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)

@rcherny
Copy link
Contributor Author

rcherny commented Jul 23, 2015

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 ...

@roblarsen
Copy link
Contributor

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.

@rcherny
Copy link
Contributor Author

rcherny commented Jul 26, 2015

Excellent. Yeah. What he said :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants