search

micahgodbolt / front-end-architecture

Raise a Banner. Take up the Torch. It's time to make Front-end Architecture matter! #frontendarch
956 stars 109 forks source link

Pillars of Front-end Architecture #6

Open micahgodbolt opened 9 years ago

micahgodbolt commented 9 years ago

Current pillars of Front-end Architecture are:

Coding Standards (how do we write our code) Documentation (how do we communicate what we've written) Testing (How do we assure that we won't break previously written code) Automation (How do we do all of the above efficiently and consistently)

Are these 4 complete? Do we need to add a 5th? Or change one of them?

Are there tools/processes/categories of things that we DO that don't fall into these 4?

lencioni commented 9 years ago

Performance?

Evangelism maybe? Could include blog posts and talks.

tevko commented 9 years ago

I think performance is a big one

lencioni commented 9 years ago

Yeah, although performance isn't really a component of architecture, more like a quality. Perhaps tooling is a component, some of which should be performance tooling. Although, simply having tooling doesn't really speak toward building a culture of performance...

tevko commented 9 years ago

I would think that a goal of good front end architecture would be a site that performs well. We all see sites with bad code bases and poor planning that also take several seconds to load. Performance may not be a component of architecture, but for me at least, it is certainly one of the things I hope to get out of it

micahgodbolt commented 9 years ago

Yeah, this is where the gray lines occur. I think performance is a consideration in that we want to be creating small file sizes, performant selectors, and speedy javascript. But the Front-end Ops discipline is pretty clearly defined now as focusing on delivering front-end assets in the best way possible.

So while I see performance an important part of your HTML/CSS plans, I don't really see it as a pillar of front-end architecture. Though i'm sure many FEA's wear a FEO hat as well!

Thoughts?

jvandenrym commented 9 years ago

Front-end web performance I think should be part of testing.

kevinwhoffman commented 9 years ago

@micahgodbolt Thanks for starting this conversation. Your list seems to cover the majority of process/tools used within FEA, but ultimately those things are put in place to achieve larger goals (clarity, sustainability, efficiency). I would argue that our ability to accomplish these goals is what gives us value, so it might be worth leading the conversation with a focus on goals instead of the underlying processes/tools used to achieve them.

I looked at each of your components and asked why?

Q: Why do we establish coding standards and documentation? A: To improve clarity.

Q: Why do we test? A: To be more sustainable.

Q: Why do we automate? A: To improve efficiency.

Here are those answers as a list of components.

What do you think?

micahgodbolt commented 9 years ago

@jvandenrym or maybe better yet in automation. the architect's job is to set up performance budgets, tests, and tools required to track the performance of a site. The actual implementation, improving front-end performance, is squarely in the hands of the front-end ops.

Obviously sometimes the Architect also wears the Ops hat, but I certainly see them as different roles.

micahgodbolt commented 9 years ago

@kevinwhoffman that was my idea with the FEA definition. Code quality, efficiency and sustainability. So I agree, the elements of FEA need to support the goals of FEA.

jvandenrym commented 9 years ago

@micahgodbolt Tackling FE performance in a FEA context would be also adhering to best Coding Practises. Loading JS from the body, reduce file size of assets, using the appropriate JS framework, custom build modernizr, mobile, CSS 3 animations (Chrome profiler) , fonts loading, etc... And FEA woud be than monitoring the performance after improvements. Indeed in the end, it would also involve as you mention Front-end Ops (if you have the luxury to have one in your team) and Sys admins that do extensive back-end server performance tests (Load balancing etc.). The FEA does contribute in that process (preliminary steps) but does not take the full responsability.

jvandenrym commented 9 years ago

@kevinwhoffman I would also include scalability as a goal. if we talk than merely about CSS http://labs.apnerve.com/metarefresh/slides/#/step-5 for example.

kevinwhoffman commented 9 years ago

Before further debate, I think we need to get on the same page as to what the definition of 'component' is within this context. Is this a list of goals/pillars that explains why FEA's exist? Or is it a list of tools/processes that explains what FEA's do?

Also, within front-end frameworks such as inuit.css, 'components' has a very specific definition relevant to OOCSS. Might be confusing to some.

jvandenrym commented 9 years ago

@kevinwhoffman @micahgodbolt Components in the context of FEA? I think of concepts like modular, reusability, maintainability, dependency management, SRP and extensibility. @kevinwhoffman You are right that components can be confusing. Are we talking CSS components, web components or components-based programming JS? All components which fit in the FE.

micahgodbolt commented 9 years ago

@kevinwhoffman exactly. Components might be the wrong word.

Just like RWD is a combination of media queries, fluid grids, and responsive images, Front-end Architecture is comprised of:

Coding Standards (how do we write our code) Documentation (how do we communicate what we've written) Testing (How do we assure that we won't break previously written code) Automation (How do we do all of the above efficiently and consistently)

These are the components/pillars/core of FEA (or at least what i've come up with).

Things like reusability, maintainability, performance, clarity are all part of the definition/objectives/goals of FEA, which is issue #5

kevinwhoffman commented 9 years ago

@micahgodbolt Got it. The RWD analogy helps a lot. I also think 'pillars' is the better term.

jvandenrym commented 9 years ago

@micahgodbolt What about Best Practises? It is complementary to Coding Standards.

micahgodbolt commented 9 years ago

@jvandenrym yeah, i'm not sure if I like the word "Coding Standards", but I think it fits best for now. It's to answer the question of "how do we write our code". Obviously this one pillar can be broken down quite a bit! But best practices, oo approach, html, css, js, file organization, naming conventions. Everything that goes into determining the standards for how our code is produced.

micahgodbolt commented 9 years ago

After a bit of thought and debate, I'm simplified the pillars a bit, making them broader and more encompassing.

Code (HTML/Sass/JS) Documentation (Components, System, Onboarding, APIs) Testing (Visual, Functional, End-to-end) Process (Git/Automation/Deployment)

JuanMaRuiz commented 8 years ago

@micahgodbolt I'm not pretty sure if the pillars should be limited to a specific technology, I think it should be more generic. I mean: