Guest Introduction: Zheng Ye, CTO of Ruff, author of Moco, winner of the Oracle Duke’s Choice Award, currently engaged in the IoT field, dedicated to simplifying the development of IoT applications. He has published articles in various media and has spoken at various technical conferences, possessing a deep understanding of agile software development, software design, domain-specific languages, etc. He is willing to share his understanding of software development and eager to absorb new knowledge, and more than willing to chat about software and hardware development.
Ruff CTO Zheng Ye
IoT (Internet of Things) is widely recognized as the future. However, it is awkward that these cool products representing the future seem to only exist in the PPTs of industry insiders. What truly enters the lives of ordinary people are mostly just some “ordinary hardware with Wi-Fi”.
Similar to the problems encountered in the popularization process of most ecosystems, IoT lacks a key system—applications. Without applications, it is naturally difficult to create a user ecosystem. However, this is not entirely the developers’ responsibility; in most cases, developers find themselves in a position where they cannot proceed because embedded development involving hardware requires a lot of foundational low-level hardware code, which deters many software programmers.
The goal of “Ruff” is to solve this problem. In short, Ruff allows developers to use the popular JavaScript language for embedded development. How do they achieve this? Let’s listen to Ruff CTO Zheng Ye explain it slowly.
▌What is Ruff?
Ruff is a hardware application development platform. In simple terms, with Ruff, developers can use JavaScript to develop hardware applications.
From the industry development trend, it is clear that IoT (Internet of Things) is widely recognized as the future. It is also known that our country’s current manufacturing level is world-class. However, what is lacking between trend and reality? What we see is: applications.
We all talk about smart hardware. In fact, so-called smart hardware is a “hardware application” that combines hardware with application scenarios. The success of applications is essentially a matter of probability. The reason we have not seen many successful hardware applications is mainly due to the overall lack of applications. Many people can see that this is a blue ocean, but the problem is that not everyone has the ability to enter this field because the threshold for hardware applications is too high.
This is similar to the era of Nokia phones, where many wanted to write mobile applications, but only a few programmers had the capability to do so. I once hoped to buy a Nokia phone for development but eventually gave up due to the complexity of development. Later, with the advent of iOS and Android, the development threshold dropped significantly, and a large number of programmers flooded in, leading to the rise of the mobile internet and the emergence of popular applications like WeChat and Didi.
Thus, Ruff aims to solve the same problem in the field of hardware application development: to lower the development threshold for hardware applications and allow more people with application development capabilities to enter this field.
There was a frontend developer who quickly wrote a small application using Ruff: lighting up a lamp on a webpage with a lighter. Because of Ruff, this developer, who had never written hardware code before, had the opportunity to start writing hardware applications. This is the role that Ruff plays in lowering the barrier to entry. In summary, Ruff aims to lower the development threshold for hardware applications, enabling developers to create more creative hardware applications.
▌How High is the Barrier for Hardware Application Development?
From the current situation, hardware and applications are completely two sets of vocabulary. For example, hardware developers care about GPIO, I2C, timing, drivers, etc., while application developers care about requirements, user experience, high availability, system architecture, etc. I once asked application developers what GPIO is, and their expression was like they had seen a ghost; I also asked hardware developers to explain the SOLID design principles, and very few could articulate them clearly.
This is the gap between software and hardware, making it a high demand for someone to possess both hardware and application skills. In fact, even within the hardware development field, aside from applications, system developers and hardware developers also have different vocabularies. Some focus on processes, while others focus on crystal oscillators; some focus on embedded systems, while others focus on PCBs.
Having someone master all these things will significantly increase the difficulty level. Even if such a person exists, their price will be very high, and the number of people available will also be limited. Furthermore, in the hardware field, the phenomenon of reinventing the wheel is quite serious. Many things, even if familiar to the developer, may need to be redone in a new environment, such as porting common network protocols or writing common drivers. My impressions come from an old master with 20 years of hardware development experience, who refers to it as a tale of blood and tears.
In the integration with applications, the hardware development process is basically a waterfall development process, or a top-down process, meaning that once the requirements are determined, a development process begins that often lasts a long time. From the perspective of software engineering practice, this is an inefficient approach because, for product development, the most important thing is rapid feedback; market demands from a year ago are different from those now.
Therefore, in the software field, methodologies like agile and lean have emerged to improve this process, with the most important being the idea of iteration, continuously improving the product. Currently, many innovative individuals come from the internet field, and they are accustomed to collaborating with software application developers, so they are also more accustomed to working with an iterative mindset. However, the same logic does not work well in the hardware field.
For example,
The product manager wants to see product progress iteratively because their ideas need repeated validation, while the hardware developer prefers to finalize the requirements before starting development because, in their logic, hardware is difficult to change once produced.
The more fundamental reason for this phenomenon is that hardware manufacturers are writing applications. However, application development is not what hardware manufacturers excel at. Once we can separate the concepts of hardware and applications, we will find that the same hardware can have different applications in different contexts.
For example,
For the same water dispenser, if you buy it home, its application is to track your family’s drinking status and remind you to drink more water;
If you rent the water dispenser, it will remind you to pay on time to ensure normal use.
Hardware is the same, but the applications are different. The best way to solve this problem is through division of labor, allowing application developers to focus solely on applications, while hardware manufacturers focus on hardware. Connecting the two is what Ruff aims to do.
▌Why JavaScript?
For programmers, language choice is always a religious war. We position Ruff as an application development platform, so when considering technology selection, we try to choose something familiar to application developers, which is why Ruff chose JavaScript.
Firstly, we excluded C/C++, which hardware developers are most familiar with, because C/C++ is seen as a system language in the eyes of most programmers. Once C/C++ is used, programmers will revert to system development thinking.
Secondly, we ruled out Java, the currently most popular language. From the audience’s perspective, Java is the most appropriate, as seen with Android, but on resource-constrained hardware, Java is too heavy.
JavaScript is an appropriate language for the following reasons:
Firstly, it is a truly cross-platform language that can run on all systems, including browsers, phones, servers, and clients.
Secondly, with the popularity of Node.js, the JavaScript community is becoming increasingly active, and many new ideas are emerging from this community.
Thirdly, JavaScript has many good runtime implementations that facilitate our work. To borrow a saying from the software development community: Atwood’s Law states that all applications that can be written in JavaScript will eventually be written in JavaScript.
However, the root cause is the audience; there is no need to educate the market from scratch. Therefore, Ruff chose JavaScript. In fact, many large companies are also entering this field, and most of their choices are also JavaScript.
▌Does JavaScript Have Advantages Over C Language?
From a personal perspective, I prefer to compare abstract levels rather than just syntax. From the development trend of technology, we have clearly seen that the level of abstraction in application development is getting higher and higher.
For instance: Initially, people used machine code, and due to memory inconvenience, assembly language emerged. Then, because assembly language varied significantly between different machines, programming languages like C were developed. Later, C++ provided object-oriented programming design, offering a good solution for organizing programs. Higher abstraction means writing the same amount of content with less code.
I once compared a C/C++ hardware application development framework from a large company, which required about 50 lines of code to light up an onboard light. With Ruff, I wrote 3 lines of code, and 2 lines were framework code.
$.ready(function() {
$(‘#led-r’).turnOn();
});
Through this code, one can feel the difference; the real core code is only 1 line, which is the value of abstraction.
▌What Depth of Development Can Be Achieved Using Only JavaScript?
The JavaScript language community has already provided many good abstractions, such as event-based models.
Ruff has also established its own abstractions. For example, it has differentiated between driver developers and application developers, where only driver developers need to care about hardware details, while application developers only need to focus on application logic.
The code I just showed is a piece of application code; you can’t see any hardware parameters, which showcases the power of layered architecture and abstraction. Furthermore, Ruff considered application testing from the design stage. Code developed with Ruff can be logically tested on development machines before being deployed to specific hardware boards. This prevents wasting time due to low-level errors that would require repeatedly burning boards.
Ruff also comes with command-line tools to simplify application development and board deployment, and additionally, there is a software repository that allows driver developers to upload their drivers and share them with the community.
As for implementing hardware programming in JavaScript, the principle is very simple: run a JavaScript engine and execute JavaScript programs on it.
Specifically,
First, we chose an embedded JavaScript engine;
Second, we run it on an operating system and build Ruff on that, which is also the version currently released.
In simple terms, this is done with the mindset of creating a minimum viable product (MVP). Ruff is also developing a version based on MCU, which will run the JavaScript engine directly on hardware. This can better address issues like power consumption and real-time performance.
▌The Future of Ruff
Now, developers can see some development boards, such as Raspberry Pi, Arduino, and Intel Edison. Ruff provides a development framework. Besides, Ruff itself also offers a set of development kits, which is intended to help people quickly get started with Ruff.
The key difference is that these development boards can only create small applications or prototypes. Of course, this is also the current state of Ruff’s development kit. In contrast, our goal with Ruff is not limited to this; we hope to connect Ruff to the production process in the future. In other words, a hardware application can be used on more realistic devices, such as MCU, without modifying the software code. We are very clear that Ruff’s endpoint is not development boards, which is fundamentally different from the objectives of other development boards.
Frankly speaking, it will be quite challenging for application developers to realize that they can write hardware applications. Many software programmers see the boundary of their thinking as hardware and do not dare to consider this aspect. Just like before Android and iOS, application developers did not feel they could write mobile applications. There is a gap in awareness; most application developers do not think hardware development has anything to do with them. Because they believe hardware application development is too difficult, they tend to shy away from it.
For Ruff, this is a market education process. In fact, hardware application development is quite simple: controlling your home TV is easy, and lighting up a lamp at home isn’t that difficult. Once the awareness gap is crossed, understanding hardware becomes much easier. After we release our official version, we will invest a lot of effort into the developer community to make them realize that they can actually do much more.
▌Latest Updates on Ruff
In January, Ruff launched a limited public beta kit, directed to some interested users, with the software SDK released alongside the public beta. A new release will occur approximately every month. Zheng Ye stated that the official version has basically completed internal stocking and will officially start sales after May Day, allowing more developers to try the new development experience.
