Welcome! Happy to see you in the fourth part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.
You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the first day's talks. You can also find the previous parts of Vue Amsterdam in my blog.
(Recurring) Introduction
After two and a half years, JSWorld and Vue Amsterdam Conference were back in Theater Amsterdam between 1 and 3 June, and I had the chance to attend this conference for the first time. I learned many things, met many wonderful people, spoke with great developers, and had a great time. On the first day the JSWorld Conference was held, and on the second and third days, the Vue Amsterdam.
The conference was full of information with great speakers, each of whom taught me something valuable. They all wanted to share their knowledge and information with other developers. So I thought it would be great if I could continue to share it and help others use it.
At first, I tried to share a few notes or slides, but I felt it was not good enough, at least not as good as what the speaker shared with me. so I decided to re-watch each speech, dive deeper into them, search, take notes and combine them with their slides and even their exact words in their speech and then share it with you so that what I share with you is at least at the same level as what I learned from them.
A very important point
Everything you read during these few articles is the result of the effort and time of the speaker itself, and I have only tried to learn them so that I can turn them into these articles. Even many of the sentences written in these articles are exactly what they said or what they wrote in Slides. This means if you learn something new, it is because of their efforts. (So if you see some misinformation blame them, not me, right? xD)
Last but not least, I may not dig into every technical detail or live codings in some of the speeches. But if you are interested and need more information, let me know and I’ll try to write a more detailed article separately. Also, don’t forget to check out their Twitter/Linkedin.
Here you can find the program of the conference:
The Unwanted Stack
Maya Shavin - Senior Software Engineer at Microsoft
Develop with Vue, build using Vite and deploy using Netlify or Vercel sounds to be the perfect stack, for every Web developer. But life is not always that perfect. And to be a good developer, we need to learn and to adapt ourselves in any situation. How do we make the most out of Vue in a less perfect, or even an unwanted tech stack? Let's join her talk and find out.
She uses an example of the evolution of building a window as a window manufacturer to make it easier to understand.
The beginning
When you start building a simple window, you can build it in any shape that you want and you have a lot of choices. You have the freedom of choice and you can choose any frame(work), any shape, any supporting tool, and any building technique.
After a while
Assuming you finish with your windows, either you become the company who makes windows because you’ve released your window out there and it became successful, or it’s just a project that you do in your free time, so now that you know how to build a window you join a company to make windows.
At this point, you start to realize that you can not choose everything on your own like before.
- Delivery/Deploying: How you’re going to Deliver the window to production or the store.
- Team: How you’re going to build a team around it; Each person in the team will be in charge of building a section of the window.
- Scalability: How you’re going to add another lock or another frame or even another layer of protection over your window to protect it from sun or rain.
- Maintenance: You always have to maintain your window because if it’s not maintainable anymore and people use it and then one day it’s broken and someone gets hurt from it, you have to take responsibility.
- Integration: Not all of the windows will fit what your customer needs. For example, it may need to be a little curvier to fit into the area where it supposes to be. So you have to do the integration and provide customization.
And suddenly, you don’t have a choice anymore and you have four factors that you need to consider to work on the window: Frameworks, Tools, Platforms, and Rules.
The Platform is the base on which you build your windows on, now the question is:
Can you build your Window on anything you want? → Can you build your application on any platform or server you want?
Every Company has its favorite platform & stack. For example, Google has its own Google Cloud, Amazon has AWS, and Microsoft has Power app and Azure. So when you work with one of these companies you don’t decide on the platform, you work with the platform. But it’s not always your favorite one!
The New Guy Phenomenon
“The one who thinks he’s cooler and knows better, and always asks: Why would you do that instead of this?!”
When you join a new company, this is how you feel and how other people see you because you come fresh, so when you go into the system you think you know it better and ask questions like why do you use Webpack instead of Vite?!
This is common and you start wanting to change things, which is good. But it leads to another debate:
“My Approach, my framework, and my stack are better!”
Or after some time you fail in convincing or feel that:
“What am I doing here?! I don’t know and don’t like this stack!”
So are you going to leave because that’s not the stack that you want?
It’s not about you
The tech stack is been there for a long time. It can be changed, but
It’s not about you, and It’s not about Evan You either! No one changes the stack just because of you or Evan You!
It’s about the Window Project
Deployment - CI/CD, Architecture, Compliance, Platforms
These represent the whole process of building a project. When you come into a new team or start a new project in a company, you need to consider these four cubes and not just go ahead and talk about a cool framework that comes with some nice tool that makes it a perfect stack. You need to consider the whole thing and find out why this is good for the project.
For example in a project which Maya works on in Microsoft, There is not much control on the Platform and Deployment part.
The Platform is already there and has all the connections to the database and all the authentication. So you can build everything up, but it also takes away some control. You don’t have control over the build process because the deployment is taken care of by the Power Apps. You don’t have control of building the server because the server is already there and you only need to config it to work with your application.
So what we have right now is the control over the architecture and compliance.
Architecture
Project nature (size, type, etc)
When you work on a project, you have to consider the nature of the project. Not every project is the same, and not every project needs the same stack.
Code Maintenance
How you are going to maintain and structure your code so that when the next new guy comes into your code base, he will not feel lost in the wood?
Scalability
How much scalability you’re going to provide in your code? If you are going to write a normal website or a landing page, you probably don’t need scalability, but if you are going to write an application where every piece is a component going to be reused by some other team or be deployed to the customer as the component itself and they would take it and use it in their applications, you probably need to understand how to do scalability.
Team performance (Skills, expertise)
This is not about the performance of the application, it is about how fast a team can walk together and can help each other to achieve what you want to do.
Compliance
This is what you want to do to comply with a bunch of protocols that your projects are given.
Startups or small companies may have fewer protocols, but in big companies like Microsoft and Google, there are many protocols to fulfill before you can release something.
Accessibility Support
Accessibility has to be a huge part because It is usability for everyone so you can not ignore it.
Testing (E2E, Unit test)
Are you going to manually run your test, check on your browser or have a whole team dedicated to doing manual testing? That’s not going to work. Nowadays finding people is hard and finding manual QAs is harder.
UI Consistency
Every Company has its own product and brand in UI design. For example, the Flat UI in Microsoft. At Microsoft in every single product, no matter what tech stack developers use, they have to use the same standards and protocols for the UI components, and in everything they do, the UI has to match the company’s branding and look and feel.
For example, if a user uses an Excel file and there is a Save button, your new application has to have the same color and look and feel for its save button.
Integration/Customization
To what extent are we going to provide integration or customization? What is the level of workaround we want our customers to have?
If you are going to build a store, that’s not much customization here except for the UI. But if you are going to build a dashboard that will be integrated into the customer database and pull data from the customer and it still needs to maintain the look and feel like Microsoft app, that would be the part where you trying to shape your application so that it will work with different customer needs.
Select(newCoolTool)
Let’s say you are the new guy on the team and you want to propose to change a testing tool. How do you want to do that?
For doing that, you have to understand what are the priorities, what are the alternatives and compare them, compatibility with the system, and only then, you propose the change to your managers or your team with Data. Here is an example:
Select(e2etesting)
What is the goal?
- Speed?
- Visual support?
- Cross-browser support?
- Flexibility in changing test runner?
- Parallel testing?
- Accessibility testing support?
How compatible is it?
- Platform integration?
- CI/CD integration?
- Maintenance effort?
- Learning effort?
Why would it be THE solution?
- What are the tradeoffs?
- Developer experience?
- Community support
- Comparisons
- Scalability
Show me some data
You will do a demo, and not just a simple demo on a small or simple case, but make the test on the hardest and most complex case of your application. That takes time but if you do that, you can see the difference in performance between the two frameworks. Because the most complex situation is what you will face in the feature. If you choose one testing framework and it’s failed to do that complex case, then you have to revert and choose a different one and that means all the effort of trying to learn and write tests and adapt to the new testing framework got wasted.
And be ready for questions.
Change the stack, or make the best out of it
There are several things that you can do to make the best out of the stack:
- Keep the coding standard
- Use TypeScript
- Be open-minded
- Create solutions, not refactor first
- Understand your window nature first
- Plan your window
- Instead of thy, try “What can be better?”
End of the fourth Talk
I hope you enjoyed this part and it can be as valuable to you as it was to me.
You can find the next Talk here
Top comments (0)