I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.

1. Frontend development
approaches that reduce the risks
of project failure
Viktor Turskyi

2. JavaScript fwdays’24
● 20 years in IT
● 13 years in software business
● Delivered more than 80 projects of
different scale
● Did 15 projects for 5 companies from
Fortune 500 list
● 3 years at Google
● youtube.com/@AboutProgramming

3. Is High Quality Software Worth
the Cost?
JavaScript fwdays’24

4. Do we need architecture for
frontend?
JavaScript fwdays’24

6. “If you think good architecture is
expensive, try bad architecture.”
—Brian Foote and Joseph Yoder
JavaScript fwdays’24

7. What is most popular
architecture today?
JavaScript fwdays’24

8. Big Ball of Mud
http://www.laputan.org/mud/mud.html#BigBallOfMud
JavaScript fwdays’24

9. JavaScript fwdays’24
Source: https://martinfowler.com/articles/is-quality-worth-cost.html

10. JavaScript fwdays’24
Source: https://martinfowler.com/articles/is-quality-worth-cost.html

11. What is the best architectural
decision?
JavaScript fwdays’24

12. Robert Martin
“The job of architect is not to make decision, the
job of the architect is to defer decisions as long
as possible”
“Good architecture maximizes number of
decisions not made”
https://www.youtube.com/watch?v=o_TH-Y78tt4
JavaScript fwdays’24

13. How can we make better
architectural decisions?
JavaScript fwdays’24

14. Solution is in technical domain
but problem statement in
business/product domain.
JavaScript fwdays’24

15. Understand business/product
domain. Focus on business
problems
JavaScript fwdays’24

16. Why to understand domain?
● Problems you solve comes from domain. Otherwise you will solve wrong problems.
● Requirements (including non functional) comes from domain.
● Creating good Domain Model requires understanding the domain
● Simplifies communication with stakeholders (you talk to them using their
language)
● Simplifies adding new changes
● Psychological comfort. Engineers prefer to write products that they understand.
JavaScript fwdays’24

17. Conduct business/product
trainings
JavaScript fwdays’24

18. Universal approach for better decisions
1. Always ask yourself “What problem do we want to solve?”
2. Find several potential solutions (not all possible, two can be enough)
3. Select the best solution for your problem
Let’s discuss problem microservices case again.
JavaScript fwdays’24

19. How to make “better” design?
● Understand business/product domain
● Understand technologies deeply
● Optimize for change
● Assemble first
● Think about abstractions
JavaScript fwdays’24

20. Why to understand technologies deeply?
● You cannot choose right technologies without knowing their properties
● You cannot know their properties without knowing implementation details
What will happen to DB if you will increase amount of data 10 times? Can you answer
that without knowing how indexes work?
Docker vs VMs? What are the properties? (Why docker is slow on OSX?)
Is MongoID secure as a token for password recovery?
React Native is native or not native?
JavaScript fwdays’24

21. Optimize for
change
One of Agile Manifesto principles:
Welcome changing requirements, even late in
development. Agile processes harness change
for the customer's competitive advantage.
https://agilemanifesto.org/principles.html
JavaScript fwdays’24

22. How to optimize for change?
● Do not write code which support everything. In this case, the result will be
opposite.
● Expect changes! Evaluate risks
● Simplify (simplicity and easiness is not the same, “Simple made easy”)!
● Good abstraction but without overengineering. Reduce coupling, increase
cohesion.
● Stay in touch with product managers (while you developing A they are already
thinking about B)
JavaScript fwdays’24

23. Can we predict future?
JavaScript fwdays’24

24. Talk to product managers - they
live in future
JavaScript fwdays’24

25. Assemble first principle
JavaScript fwdays’24

26. https://webbylab.com/cases/mercedes/
JavaScript fwdays’24

30. How to organize work on this?
JavaScript fwdays’24

31. What does it mean to assemble first?
● Create abstractions
● Think about data which goes through your system
● Implement behaviour just with simple boxes
● Iteratively add details to each box
JavaScript fwdays’24

32. Why to assemble first?
● You will have abstractions of components that really fit each other
● You will have end-to-end working functionality early to and will get early feedback
● Feature owners can test their own pieces in fully working environment
● You can discover risks as earlier
● Early integration becomes possible
● Much easier to parallelize the work
● Not having time to deliver 100% will allow you to compromise on some visuals
than on end-to-end experience for case when you assemble at the very end
JavaScript fwdays’24

33. https://blog.udemy.com/how-to-draw-a-realistic-cat-step-by-step/
JavaScript fwdays’24

34. https://blog.udemy.com/how-to-draw-a-realistic-cat-step-by-step/
JavaScript fwdays’24

35. Does it guarantee success? No!
JavaScript fwdays’24

36. Priorities/Commitment
P0 - must
P1 - should
P2 - might
JavaScript fwdays’24

37. https://blog.udemy.com/how-to-draw-a-realistic-cat-step-by-step/
P0, P1, P2 P0, P1
P0
JavaScript fwdays’24

38. Abstractions
JavaScript fwdays’24

39. What are good abstractions
● They are usable. Think how they will be used while designing them
● You can understand them. You should be able to predict system behaviour
● You should know where to put specific code
● Tests are just statistical proofs that something is working
● They are not dependent on context
● Low coupling
● High cohesion
JavaScript fwdays’24

40. Developes are afraid of new abstractions
● Story about Test factory and assertDate method
● Story about Controllers/Mediators/Managers in UI
● Story about Extra behaviour in slides engine
● Story about Builders for UI components
● etc
JavaScript fwdays’24

41. Level editors concept
JavaScript fwdays’24

42. Universal toolkits
JavaScript fwdays’24

43. Builders
JavaScript fwdays’24

44. Type of builders
● Form Builder
● Dialog Builder
● Grid Builder
● Page Builder
JavaScript fwdays’24

45. Form builder schema
{
api: { load: (id) => {} , save: (data) => {}},
inputs: [
{field: ‘name’, type: ‘text’, label: ‘Name’}
],
}
JavaScript fwdays’24

46. Form builder
function UserEditForm({id}) {
const schema = {...}
return <FormBuilder schema={schema} />
}
JavaScript fwdays’24

47. Dialog builder
function UserEditDialog({id}) {
const schema = {
title: ‘Edit dialog’,
formSchema: {}
}
return <DialogBuilder schema={schema} />
}
JavaScript fwdays’24

48. Grid builder schema
source: { list: Promise.resolve(data)},
columns: [
{field: ‘id’, type: ‘id’, label: ‘Id’},
{field: ‘name’, type: ‘url’, label: ‘Name’, urlFormatter: (user) => `/users/${user.id}`}
],
rowActions: [
{icon: <DeleteIcon />, label: ‘Delete’, confirm: true },
{icon: <EditIcon />, label: ‘Edit’, action: (row) => {
dialogService.open(UserEditDialog, {id: row.id})
}],
JavaScript fwdays’24

49. Grid builder
function UsersGrid() {
const schema = {...}
return <GridBulder schema={schema} />
}
JavaScript fwdays’24

50. Page builder
{
title: ‘users’,
layout: {component: MainLayout, props: {selected: ‘users’} },
gridSchema: {...},
}
JavaScript fwdays’24

51. Builders pros
● You have consistent behaviour across your UI
● Increases development speed a lot
● Can be iteratively updated each time you have a new requirement
● Easier to design
● Minimum extra time for development as the features should be done in any case
JavaScript fwdays’24

52. Is technical debt a bad thing?
JavaScript fwdays’24

53. Some thoughts on technical debt
● Doing things the quick and dirty way sets us up with a “technical debt”, which is
similar to a financial debt.
● Another metaphor is “Pollution”. Pollutants gradually affect people and as time
passes by, makes it exponentially harder and costly to fix it.
● You can't cook food without dirtying the dishes. Clean the kitchen after cooking
● You introduce technical debt even if all you do is just write similar code.
JavaScript fwdays’24

54. Some thoughts on patterns and best
practices
Pattern is just a common solution (not a secret solution) which works for a common
problem.
Ask yourself why such pattern or best practice does exist and be ready to not follow it if
this “why” is not related to your case.
JavaScript fwdays’24

55. Chat example
Let’s design together
JavaScript fwdays’24

56. @turskyi
Viktor
Turskyi
Thank you