Prototype code. Lecture on FrontTalks
Happy holidays, friends! In preparation for the start of the new working year, we are completing a series of materials from the FrontTalks 2018 conference. This is a lecture by Andrei Salomatin filipovskii_off , a developer from Polychops. Andrei proposes a balanced approach to prototyping: to turn from artisans who fulfill orders into researchers into learning to work with uncertainty and, perhaps, to keep their sanity even without a clear plan.
- Hello! I would like to talk about prototyping: why do prototypes, what we get from this and how to do them, by examples.
')
I'll start with a little story. In 2012, I joined this startup, a wonderful deer. We had something like an advertising platform, I came as a Java developer. It is clear that large volumes of traffic, interesting tasks, the team is just freaky - everything is great. We work for about eight months, with our heads on the keyboard, we make very cool features, we quickly turn everything around. But in 2013, the deer goes up with its hooves.
What happened? I thought about it for a very long time, afterwards I went to work as a front-end and back-end developer at different companies, then I was a team leader, then a product manager. He worked in startups, and in outsourcing companies, in large enterprises. Mainly focused on startups.
I also did some of these projects. I was lucky to work on MoscowJS, Frontend Union Conf and RadioJS. Maybe we overlap with you somewhere. Now I am doing Code Podcast, a podcast in English about general programming concepts, and Polychops, a project for musicians that works in a browser and helps you practice with the instrument, get more time and practice.
What happened to HeyMoose? The company had very smart people who are now working as senior developers at Microsoft or have become a service station. We did what we did best: we solved complex technical problems quickly and interestingly. But something went wrong.
And something goes wrong with a lot of companies, especially startups. Startups basically burn out for two reasons: either they don’t understand the product, they miss something with the product, or they run out of money. They often run out of money because they are looking for a product and cannot find it for a long time.
But why is custom development in outsourcing companies not closing? Or why aren't large enterprises closed? It seems they are slower. As a rule, teams there are at least less motivated. What is the difference? The mechanisms of work are the same: in custom development, we write TK or ask TZ to customers, they paint it for us, give it away, we make layouts, code, fizz it - the same process. What is in a startup, that in large companies there can be ejail practices. Everything is the same. So why do startups fade?
Let's first imagine a hypothetical situation: the product manager comes to us and asks if we can forget the metronome, which will work in the browser, make a sound with a periodic interval and synchronous visualization, so that different lights sparkle at one with the metronome. And that all this was accurate, regardless of what is happening on the computer, other processes, etc.
Who is 100% sure that we can do this by using the browser and the browser API? Not a single person. Who is 80% sure that we can probably do this? 3-4 hands. Who is sure 50 to 50? Most. Who is sure that we cannot do it at all? Decently.
The following example. Suppose we are working in another company on a mobile bank. We think more about the product and think that we need to grow the number of users who use our mobile bank. We came up with a feature: now the user can share a purchase or account replenishment in social networks. A money came to him, he is so on Facebook - look, the money came to me. Do you think this will help attract more users? Who is 100% sure of this? No one. Who is 100% sure that this will not help us in any way? Two or three hands. The rest is somewhere in between.
And the last example. We do cloud service, we open our company. The cloud service will collect logs from projects, from the frontend and backend in small and medium business, aggregate them, machine learning, AI and all that. We will sell it. Who is sure that this is a 100% success or a 100% loss? A couple of people.
There is only one correct answer to all these three questions: "probably." In the answers to some of the questions we are 50-80% sure. A lot depends on the context, on execution. The same metronome with visualization - I worked on it, it cannot be made so that it works in all contexts: for example, with Bluetooth headphones. But you can do for two or three generalized cases. In my understanding, this is “probably” - and there is a reason for which startups are closing, for which HeyMoose went up with its hooves. Maybe we will do something good, or maybe we just waste time. And we have no way of understanding how confident we are of what we are doing.
A bit of theory. What is the difference between customized development and startup? The difference is in context. We are in this context of uncertainty, we have the probability of success and the likelihood of failure. It is as if we try to use the same methods and practices when we run on the earth and when we run in space without gravity. It would seem that we are running, but nothing happens. What are we doing wrong?
This uncertainty comes from three main directions. It comes from the market - because we do not know clearly what other companies are engaged in the aggregation of logs. Maybe this market is already captured by someone? What is the demographics on the market, what are the prices? Uncertainty can come from a product. We do not know what the problem is with our client and how to solve it. This is from the example of a mobile bank. We seem to have an understanding, but we are not sure whether users have this problem and how to solve it.
And there are implementation issues. An example with a metronome. We do not know 100%, it is theoretically possible or not.
Or another example. We have no problems with the market or product, if we invent a cure for cancer, which is just a pill - taken and healthy. But there is a huge amount of uncertainty about how to implement this pill. We are in a fog of war, but at the same time we behave as if fog does not exist, because we have the same principles that work in custom development. We simply move them into our context of uncertainty.
We pretend that this fog does not exist, there is no uncertainty. And we are trying to predict the future. When I started working as a product manager, I was amazed after the development process how much product product manager should be doing fortune-telling. When you report to the director or to someone else, you must look confident, I must say that we will do it or that, take the market by September, everything will be hurt. All such - well done, all thought out. Although in fact, I understand that there is nothing of this, I am just wondering on the cards and trying to look confident at the same time. We do not have a work culture with uncertainty, with probability. Plus, to look like experts, we need to constantly strive for reputation, to be confident, to talk about what we should do, instead of what we should check, or what we are not sure about.
We, especially developers, still have a tendency to think about what we know, understand and can control. As developers, we love to plan architectures, think about the future, don't repeat yourself, pattern programming and all that.
Designers are also sick of it. They like to think about the future, make perfect layouts, etc. We are experts, although in fact we may need to become someone else.
How do we deal with uncertainty? What methods of struggle do we have? The first method is the most important - to put all the cards on the table, to recognize that we are not sure of any question. We may be 50% sure, but to test the hypothesis, we need two days. Then why don't we just go and test the hypothesis? We may be 90% sure that the product will soar, but we need eight months to import this product and test the hypothesis. Will we just go and check? Or, perhaps, think about how to reduce uncertainty to 90 or 100%?
This is the first way. You need to hang a badge of this uncertainty, say how big or small it is, how much work is needed to resolve it, etc.
The second way that humankind has been working for the last 500 years is a scientific method. It is not perfect, there are some bugs there, but this is the best mechanism we have at the moment. The scientific method says: to resolve uncertainty, we first guess, invent a hypothesis based on our conclusions, then we think up an experiment that confirms or disproves this hypothesis, then we start the experiment, look at the numbers and understand whether our hypothesis is true.
In development, especially in the frontend, we have a unique opportunity to run these experiments at very high speeds. This method is called prototyping. Prototype - a way to deal with uncertainty. This is not an invention of the product, not the creation of something perfect that users will use. This is an opportunity to learn more about the world around us. We will know this by creating illusions. The prototype is an illusion, not a product. We kind of build the scenery on the theater stage or on the stage for making movies. This is just an illusion. The goal is to reduce uncertainty.
Prototyping works in two contexts: in the context of implementation, when we do not know theoretically in terms of the API, whether it is possible or not, and in the context of the product, when we do not know what problem the user has and how to solve it. Prototyping doesn’t work much in market research - Excel exists for this
The point is that when we are working on a prototype, we need to abandon the way to think like experts. We need to forget these programming patterns, we need to forget how we make perfect products - because we don’t make them. We are trying to do research, become scientists.
So instead of thinking through architectures, we need to find a way to iterate very quickly. Instead of approximating and thinking about the future, you need to think about how to crank it now, in a short time.
Instead of thinking about my reputation, what will happen if I say that I am sure or not sure ... Instead, I must renounce my reputation and become newcomers. Dunce. How do we do it? What specific things can we apply to become newbies?
The first and most important point - feedback. Even before we plan our prototype, draw a layout or something else, we think about who we will show these mockups or prototype to, how we will test the product, what we are trying to get from this experiment. The shorter this feedback loop, the better for us.
An example from personal life. Productive Mobile - a company I have recently been working in as a startup; they have come up with a platform that allows you to make a mobile application from a website in such a drag and drop way. We sold it to large corporations, because they have products like SharePoint or SAP that cannot be used on a mobile phone, pinch zoom, that's all. We offered them an option: you can make a mobile application based on a real site, say, in a week. The problem is that we had a very strong development team and a very long sales cycle. When you sell a product of a Daimler or BMW size company, the sales cycle is at least 8 months. During this period, a team of talented developers can cut a lot.
What have we done and what has helped us? We created a mini-team of users within our company who used the product. And the quantity of features which we began to do and to release, was reduced. But at the same time, the quality of features has increased n times. And when we came to our user and said that we have such and such a platform, let's try it, for some reason emergency situations ceased to arise when we are like this: we didn’t think about it, this is something new. We began to make features that actually began to bring results. This is due to the fact that we simply reduced the feedback loop.
An example with a metronome, the Polychops project I'm working on now. First of all, we created in a short time a video that was posted somewhere on the Internet. In it we asked how this concept is to you, what do you think about it. According to reviews, we not only appreciated how interesting it is. We also received leads that we could communicate with, who could be invited to make phone calls, interviews, give them a prototype, etc.
We try to get feedback very early. And not just any feedback, but qualitative, not quantitative.
What is the difference? Quantitative feedback is AB testing, binary results, when either Option A or Option B is winning. That's all that we can get from quantitative cycles. It is as if we are in a dark room and nothing is visible, but we have a laser pointer. From time to time we shine it in the corners, we highlight some points and we understand what is in them.
What would we like instead? A user who describes this dark room, who knows it much better than we do. We need high-quality interviews, calls, something else to get information from users in expanded form.
An example of a company that relies heavily on quantity feedback is Booking.com. In my opinion, there is something to work on their website.
One of the prototypes of the project I'm working on is a feature with which a person can record himself and at the same time reproduce himself the way he played under the metronome - good or bad. We came up with this feature because we asked for high-quality feedback from people who tested the prototype. One of the people wrote that everything is great, I like the part with the metronome, but it would be cool to export this track with the metronome as a sound track. We are - it is illogical, why? He says: “I insert it into my program for working with music, then I record myself over it, and then I can hear whether I get into a rhythm or not.” We are - this is brilliant.
But instead of just exporting, we decided to test the hypothesis. We talked with people, asked if they listened to themselves at all when they were playing with the metronome. Many people said that yes, we often have one program - a metronome, another program - a voice recorder on the phone or somewhere else, we just record and listen to ourselves. We are - we are programmers, we can connect it in one application. As a result, we got this feature. We would never have guessed it if we simply performed the AV testing.
The most important part of the prototype is the interface. In a global sense. If we have some kind of service with some kind of API, then our interface is an API, then what the user interacts with. If we are working on the metronome, our interface is the visual part and sound. If we work simply on a mobile application, our interface is a visual interface. In the prototype, the interface is the only important part. Everything else we can forge, replaced by plush.
Another example from Productive Mobile. At some point we decided to rewrite the internal API in this mobile application’s drag and drop editor. The API allows JS to revive some difficult parts of your mobile application. As a product manager, I could just write a specification and give it to the developers. I am sure that in a maximum of a month everything would be ready, tested and wonderful. But we decided to try a different way. We just documented the API that we had in our head, on paper, and gave this paper to the people who were involved in the creation of mobile applications. They asked: if you had such an API, how would you, in theory, build your applications?
They took another paper, they checked everything on it. Without implementation. The API did not work at this stage. So we cranked 5-10 iterations before we realized what form API should be. We saved a lot of time on implementation. Already after we understood the form, we documented the specification, and we have inserted it. Everything was great.
Another example from the metronome. The very first idea for Polychops is a metronome for working with polyrhythms. We made the first prototype in about 20 minutes and wrote in Flash. That's how he looked. There was even a sound. We just went and showed it to fellow musicians, asked - how do you even? This is the only important thing.
Then we did a real metronome in the browser, it all worked, animation, blah blah, everything is beautiful.
-, — 20 .
.
, -. Polychops.
, , . - , , , , - . , , , . -, material-, . , .
. . . - , , . , , , - .
Polychops. , Logic. , , , Logic, , , Polychops.
. , . .
: , . , , .
, , . , , . , , , , , . .
— . , , . , .
, , — . . , React . React, React. , , , Redux Apollo, . . .
— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .
, , . . , . — , , .
, . , . . , . . . — , . , .
? « ?» — , . ?
. , . . 10% , , 10%, , — .
. , 90% , . , , 10%. — , . .
, . Productive Mobile , . , , - , .
. React, — React Native. , , — React, React Native. - : «, React Native, , ». .
? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .
, , … ?
Polychops - , . , , , , , . - , , . . .
, . , , , . , , , , , , , , , .
, , , - . Thank.
Quantitative feedback is AB testing, binary results, when either Option A or Option B is winning. That's all that we can get from quantitative cycles. It is as if we are in a dark room and nothing is visible, but we have a laser pointer. From time to time we shine it in the corners, we highlight some points and we understand what is in them.
What would we like instead? A user who describes this dark room, who knows it much better than we do.
- Hello! I would like to talk about prototyping: why do prototypes, what we get from this and how to do them, by examples.
')
I'll start with a little story. In 2012, I joined this startup, a wonderful deer. We had something like an advertising platform, I came as a Java developer. It is clear that large volumes of traffic, interesting tasks, the team is just freaky - everything is great. We work for about eight months, with our heads on the keyboard, we make very cool features, we quickly turn everything around. But in 2013, the deer goes up with its hooves.
What happened? I thought about it for a very long time, afterwards I went to work as a front-end and back-end developer at different companies, then I was a team leader, then a product manager. He worked in startups, and in outsourcing companies, in large enterprises. Mainly focused on startups.
I also did some of these projects. I was lucky to work on MoscowJS, Frontend Union Conf and RadioJS. Maybe we overlap with you somewhere. Now I am doing Code Podcast, a podcast in English about general programming concepts, and Polychops, a project for musicians that works in a browser and helps you practice with the instrument, get more time and practice.
What happened to HeyMoose? The company had very smart people who are now working as senior developers at Microsoft or have become a service station. We did what we did best: we solved complex technical problems quickly and interestingly. But something went wrong.
And something goes wrong with a lot of companies, especially startups. Startups basically burn out for two reasons: either they don’t understand the product, they miss something with the product, or they run out of money. They often run out of money because they are looking for a product and cannot find it for a long time.
But why is custom development in outsourcing companies not closing? Or why aren't large enterprises closed? It seems they are slower. As a rule, teams there are at least less motivated. What is the difference? The mechanisms of work are the same: in custom development, we write TK or ask TZ to customers, they paint it for us, give it away, we make layouts, code, fizz it - the same process. What is in a startup, that in large companies there can be ejail practices. Everything is the same. So why do startups fade?
Let's first imagine a hypothetical situation: the product manager comes to us and asks if we can forget the metronome, which will work in the browser, make a sound with a periodic interval and synchronous visualization, so that different lights sparkle at one with the metronome. And that all this was accurate, regardless of what is happening on the computer, other processes, etc.
Who is 100% sure that we can do this by using the browser and the browser API? Not a single person. Who is 80% sure that we can probably do this? 3-4 hands. Who is sure 50 to 50? Most. Who is sure that we cannot do it at all? Decently.
The following example. Suppose we are working in another company on a mobile bank. We think more about the product and think that we need to grow the number of users who use our mobile bank. We came up with a feature: now the user can share a purchase or account replenishment in social networks. A money came to him, he is so on Facebook - look, the money came to me. Do you think this will help attract more users? Who is 100% sure of this? No one. Who is 100% sure that this will not help us in any way? Two or three hands. The rest is somewhere in between.
And the last example. We do cloud service, we open our company. The cloud service will collect logs from projects, from the frontend and backend in small and medium business, aggregate them, machine learning, AI and all that. We will sell it. Who is sure that this is a 100% success or a 100% loss? A couple of people.
There is only one correct answer to all these three questions: "probably." In the answers to some of the questions we are 50-80% sure. A lot depends on the context, on execution. The same metronome with visualization - I worked on it, it cannot be made so that it works in all contexts: for example, with Bluetooth headphones. But you can do for two or three generalized cases. In my understanding, this is “probably” - and there is a reason for which startups are closing, for which HeyMoose went up with its hooves. Maybe we will do something good, or maybe we just waste time. And we have no way of understanding how confident we are of what we are doing.
A bit of theory. What is the difference between customized development and startup? The difference is in context. We are in this context of uncertainty, we have the probability of success and the likelihood of failure. It is as if we try to use the same methods and practices when we run on the earth and when we run in space without gravity. It would seem that we are running, but nothing happens. What are we doing wrong?
This uncertainty comes from three main directions. It comes from the market - because we do not know clearly what other companies are engaged in the aggregation of logs. Maybe this market is already captured by someone? What is the demographics on the market, what are the prices? Uncertainty can come from a product. We do not know what the problem is with our client and how to solve it. This is from the example of a mobile bank. We seem to have an understanding, but we are not sure whether users have this problem and how to solve it.
And there are implementation issues. An example with a metronome. We do not know 100%, it is theoretically possible or not.
Or another example. We have no problems with the market or product, if we invent a cure for cancer, which is just a pill - taken and healthy. But there is a huge amount of uncertainty about how to implement this pill. We are in a fog of war, but at the same time we behave as if fog does not exist, because we have the same principles that work in custom development. We simply move them into our context of uncertainty.
We pretend that this fog does not exist, there is no uncertainty. And we are trying to predict the future. When I started working as a product manager, I was amazed after the development process how much product product manager should be doing fortune-telling. When you report to the director or to someone else, you must look confident, I must say that we will do it or that, take the market by September, everything will be hurt. All such - well done, all thought out. Although in fact, I understand that there is nothing of this, I am just wondering on the cards and trying to look confident at the same time. We do not have a work culture with uncertainty, with probability. Plus, to look like experts, we need to constantly strive for reputation, to be confident, to talk about what we should do, instead of what we should check, or what we are not sure about.
We, especially developers, still have a tendency to think about what we know, understand and can control. As developers, we love to plan architectures, think about the future, don't repeat yourself, pattern programming and all that.
Designers are also sick of it. They like to think about the future, make perfect layouts, etc. We are experts, although in fact we may need to become someone else.
How do we deal with uncertainty? What methods of struggle do we have? The first method is the most important - to put all the cards on the table, to recognize that we are not sure of any question. We may be 50% sure, but to test the hypothesis, we need two days. Then why don't we just go and test the hypothesis? We may be 90% sure that the product will soar, but we need eight months to import this product and test the hypothesis. Will we just go and check? Or, perhaps, think about how to reduce uncertainty to 90 or 100%?
This is the first way. You need to hang a badge of this uncertainty, say how big or small it is, how much work is needed to resolve it, etc.
The second way that humankind has been working for the last 500 years is a scientific method. It is not perfect, there are some bugs there, but this is the best mechanism we have at the moment. The scientific method says: to resolve uncertainty, we first guess, invent a hypothesis based on our conclusions, then we think up an experiment that confirms or disproves this hypothesis, then we start the experiment, look at the numbers and understand whether our hypothesis is true.
In development, especially in the frontend, we have a unique opportunity to run these experiments at very high speeds. This method is called prototyping. Prototype - a way to deal with uncertainty. This is not an invention of the product, not the creation of something perfect that users will use. This is an opportunity to learn more about the world around us. We will know this by creating illusions. The prototype is an illusion, not a product. We kind of build the scenery on the theater stage or on the stage for making movies. This is just an illusion. The goal is to reduce uncertainty.
Prototyping works in two contexts: in the context of implementation, when we do not know theoretically in terms of the API, whether it is possible or not, and in the context of the product, when we do not know what problem the user has and how to solve it. Prototyping doesn’t work much in market research - Excel exists for this
The point is that when we are working on a prototype, we need to abandon the way to think like experts. We need to forget these programming patterns, we need to forget how we make perfect products - because we don’t make them. We are trying to do research, become scientists.
So instead of thinking through architectures, we need to find a way to iterate very quickly. Instead of approximating and thinking about the future, you need to think about how to crank it now, in a short time.
Instead of thinking about my reputation, what will happen if I say that I am sure or not sure ... Instead, I must renounce my reputation and become newcomers. Dunce. How do we do it? What specific things can we apply to become newbies?
The first and most important point - feedback. Even before we plan our prototype, draw a layout or something else, we think about who we will show these mockups or prototype to, how we will test the product, what we are trying to get from this experiment. The shorter this feedback loop, the better for us.
An example from personal life. Productive Mobile - a company I have recently been working in as a startup; they have come up with a platform that allows you to make a mobile application from a website in such a drag and drop way. We sold it to large corporations, because they have products like SharePoint or SAP that cannot be used on a mobile phone, pinch zoom, that's all. We offered them an option: you can make a mobile application based on a real site, say, in a week. The problem is that we had a very strong development team and a very long sales cycle. When you sell a product of a Daimler or BMW size company, the sales cycle is at least 8 months. During this period, a team of talented developers can cut a lot.
What have we done and what has helped us? We created a mini-team of users within our company who used the product. And the quantity of features which we began to do and to release, was reduced. But at the same time, the quality of features has increased n times. And when we came to our user and said that we have such and such a platform, let's try it, for some reason emergency situations ceased to arise when we are like this: we didn’t think about it, this is something new. We began to make features that actually began to bring results. This is due to the fact that we simply reduced the feedback loop.
An example with a metronome, the Polychops project I'm working on now. First of all, we created in a short time a video that was posted somewhere on the Internet. In it we asked how this concept is to you, what do you think about it. According to reviews, we not only appreciated how interesting it is. We also received leads that we could communicate with, who could be invited to make phone calls, interviews, give them a prototype, etc.
We try to get feedback very early. And not just any feedback, but qualitative, not quantitative.
What is the difference? Quantitative feedback is AB testing, binary results, when either Option A or Option B is winning. That's all that we can get from quantitative cycles. It is as if we are in a dark room and nothing is visible, but we have a laser pointer. From time to time we shine it in the corners, we highlight some points and we understand what is in them.
What would we like instead? A user who describes this dark room, who knows it much better than we do. We need high-quality interviews, calls, something else to get information from users in expanded form.
An example of a company that relies heavily on quantity feedback is Booking.com. In my opinion, there is something to work on their website.
One of the prototypes of the project I'm working on is a feature with which a person can record himself and at the same time reproduce himself the way he played under the metronome - good or bad. We came up with this feature because we asked for high-quality feedback from people who tested the prototype. One of the people wrote that everything is great, I like the part with the metronome, but it would be cool to export this track with the metronome as a sound track. We are - it is illogical, why? He says: “I insert it into my program for working with music, then I record myself over it, and then I can hear whether I get into a rhythm or not.” We are - this is brilliant.
But instead of just exporting, we decided to test the hypothesis. We talked with people, asked if they listened to themselves at all when they were playing with the metronome. Many people said that yes, we often have one program - a metronome, another program - a voice recorder on the phone or somewhere else, we just record and listen to ourselves. We are - we are programmers, we can connect it in one application. As a result, we got this feature. We would never have guessed it if we simply performed the AV testing.
The most important part of the prototype is the interface. In a global sense. If we have some kind of service with some kind of API, then our interface is an API, then what the user interacts with. If we are working on the metronome, our interface is the visual part and sound. If we work simply on a mobile application, our interface is a visual interface. In the prototype, the interface is the only important part. Everything else we can forge, replaced by plush.
Another example from Productive Mobile. At some point we decided to rewrite the internal API in this mobile application’s drag and drop editor. The API allows JS to revive some difficult parts of your mobile application. As a product manager, I could just write a specification and give it to the developers. I am sure that in a maximum of a month everything would be ready, tested and wonderful. But we decided to try a different way. We just documented the API that we had in our head, on paper, and gave this paper to the people who were involved in the creation of mobile applications. They asked: if you had such an API, how would you, in theory, build your applications?
They took another paper, they checked everything on it. Without implementation. The API did not work at this stage. So we cranked 5-10 iterations before we realized what form API should be. We saved a lot of time on implementation. Already after we understood the form, we documented the specification, and we have inserted it. Everything was great.
Another example from the metronome. The very first idea for Polychops is a metronome for working with polyrhythms. We made the first prototype in about 20 minutes and wrote in Flash. That's how he looked. There was even a sound. We just went and showed it to fellow musicians, asked - how do you even? This is the only important thing.
Then we did a real metronome in the browser, it all worked, animation, blah blah, everything is beautiful.
Polychops Metronome Video
-, — 20 .
.
, -. Polychops.
, , . - , , , , - . , , , . -, material-, . , .
. . . - , , . , , , - .
Polychops. , Logic. , , , Logic, , , Polychops.
. , . .
: , . , , .
, , . , , . , , , , , . .
— . , , . , .
, , — . . , React . React, React. , , , Redux Apollo, . . .
— . , , — . , - , . , , , , , . -, . . -, , — , . , , , , , .
, , . . , . — , , .
, . , . . , . . . — , . , .
? « ?» — , . ?
. , . . 10% , , 10%, , — .
. , 90% , . , , 10%. — , . .
, . Productive Mobile , . , , - , .
. React, — React Native. , , — React, React Native. - : «, React Native, , ». .
? . , , 10 React Native , React Native-. , - , , . , , , «write once — use anywhere». Android iOS . . , , , . — , - , - . — .
, , … ?
Polychops - , . , , , , , . - , , . . .
, . , , , . , , , , , , , , , .
, , , - . Thank.
Source: https://habr.com/ru/post/435302/
All Articles