Improving Developer Productivity on Internet of Things using JavaScript

Fernando L. Oliveira

1 a

, Rafael R. Parizi

1 b

and J

ulio C. B. Mattos

2 c

Lardev Research Group, Federal Institute Farroupilha, 305 Otaviano Mendes st, S

ao Borja, Brazil

Technological Development Center – CDTec, 373 Gonc¸alves Chaves St., Pelotas, Brazil

Keywords:

Internet of Things, Embedded Software, JavaScript.

Abstract:

C is a compiled language traditionally used to develop Internet of Things (IoT) systems. It requires higher tar-

get domain knowledge and attention to manual issues like memory management, particularly on constrained

devices. In addition, the growing complexity of applications has fostered the use of interpreted languages

for programming embedded software. However, little is known about how interpreted languages improve the

development of IoT software. This paper reports an experiment comparing JavaScript and C languages over

performance and coding. We implemented solutions for the same problem at hand through each language,

keeping the same hardware platform. As a result, we identiﬁed that the JavaScript language could be consid-

ered an alternative for the Design Space Exploration phase. Since the perceived beneﬁts from the programmer

perspective overcome the higher performance achieved in the C-based solution, collaborating to better under-

stand the trade-off between development, maintainability, and optimization on constrained devices.

1 INTRODUCTION

Over the years, the Internet of Things (IoT) has be-

come pervasive in our daily routine. It has supported

innovation in the industry, agriculture, transport, com-

merce, health, home automation, to name but a few.

According to Transforma Insights (Transforma In-

sights, 2021), the forecast until the year 2030 will be a

total of 24.1 billion active IoT devices, with a growth

rate of 11% per year.

Commonly IoT devices are constrained in terms

of processing, memory, storage, and power consump-

tion. These characteristics imply a software develop-

ment process that must consider resource limitations.

Hence, developers are forced, except for a few cases,

to build speciﬁc hardware platform-based solutions

(Liggesmeyer and Trapp, 2009).

Traditionally, embedded software development

uses compiled programming languages such as C lan-

guage. C dominates constrained devices (Ebert and

Jones, 2009), (Severin et al., 2020), (Eclipse Foun-

dation, 2020); it is also a natural choice for embed-

ded coding because most microcontrollers support it.

Also, it is the only option for some devices due to

https://orcid.org/0000-0002-9158-8879

https://orcid.org/0000-0001-8550-1135

https://orcid.org/0000-0002-0619-9271

their constrained properties. Moreover, the C com-

piler introduces optimizations (interprocedural opti-

mizations) to achieve performance, reduce the binary

footprint, and best manage resources (Oshana and

Kraeling, 2019).

However, the increasing complexity of embedded

software imposes requirements on the software de-

sign. It needs to attend non exclusively resource man-

agement but also consider the aspects of software de-

velopment, such as maintainability, reuse, and testa-

bility (Papadopoulos et al., 2018), (Oliveira et al.,

2008). Therefore, the C language can be unsuitable

considering the language structure and the lack of

utility functions. For instance, pointers management

might have difﬁculty understanding the logic imple-

mentation, and memory management need extra at-

tention to avoid memory leaks.

At the same time, the hardware evolution allows

the introduction of new approaches, techniques, and

technologies. Thus, the Design Space Exploration

(DSE) can explore different design alternatives for

modeling and planning applications and standards

(Thole and Ramu, 2020). Therefore, DSE for em-

bedded systems explores the design space to make

choices about which technologies should be used and

consider optimization objectives and software engi-

neering metrics (Pimentel, 2016).

In this paper, we introduce JavaScript (JS) lan-

Oliveira, F., Parizi, R. and Mattos, J.

Improving Developer Productivity on Inter net of Things using JavaScript.

DOI: 10.5220/0011082200003194

In Proceedings of the 7th International Conference on Internet of Things, Big Data and Security (IoTBDS 2022), pages 223-230

ISBN: 978-989-758-564-7; ISSN: 2184-4976

223

guage as an alternative to a programming language

that can be considered at the DSE phase. We devel-

oped two versions of the same application using C and

JavaScript language. Both solutions were deployed in

the same hardware platform (ESP8266 NodeMCU-

12E (ESP8266 NoDEMCU-12E, 2021)). We ex-

tracted data about execution and resource consump-

tion. Also, we performed analyses from the source

code using software quality metrics. Our ﬁndings

show that although the C language has better per-

formance than JavaScript, the developer perspective’s

beneﬁts can overcome the poor performance. Further-

more, we identiﬁed that the JS language could be a

key to creating a cross-platform development environ-

ment.

The outline of this paper is as follows: Section

2 presents the essential concepts about source code

analysis in a nutshell; Section 3 describes the method-

ological process of the research; Section 4 shows the

results and discussions, and ﬁnally, Section 5 con-

cludes this paper and gives an outlook on future work.

2 BACKGROUND

The search for application development improve-

ments has been investigated in detail by the re-

searchers. There are many techniques, approaches,

and methodologies to contribute, somehow, toward

better software development.

Choosing of programming language is one of the

most complex decision-making that the software en-

gineer must take (Bhattacharya and Neamtiu, 2011).

Several items could impact the decision process, such

as implementation cost, quality of result, learning

curve, maintainability, language ecosystem, among

others. Therefore, each language has different traits

that should be considered in selecting a ﬁtting lan-

guage (Farshidi et al., 2021).

Thereby the software engineering concerns of

software product quality to achieve software require-

ments. Thus, the programming language features

have a strong impact on the programming attributes

like usability, cost, product, supplies, and maintain-

ability. Then knowledge about programming lan-

guages assumes an essential role in the developer pro-

cess, in particular, in the embedded system domain

(Farshidi et al., 2021).

Given the context, source code analysis aims to

seek code quality. Nevertheless, the analysis can be

performed considering distinct goals; for instance,

optimization, maintenance, and reuse are interested in

software engineering perspective, even though com-

plexity, code size, and available resource are needs

from the environment or device (Mushtaq et al.,

2017).

Therefore, the source code analysis may take stat-

ically, dynamically, or combined using tools. More-

over, the static analysis evaluates the raw source code

to extract information about the program (Binkley,

2007). These analyses help the developers detect log-

ical defects, better understand the program ﬂow, min-

imize security issues, and measure code complexity,

among others.

The Halstead Metrics (Halstead, 1977) is one of

the classic and widely used tools for software qual-

ity metrics. It was proposed by Maurice Halstead and

comprehends software complexity measures based on

the numbers of operators and operands from source

code. In this way, it is possible to assess different lan-

guages and use them as a quality parameter to com-

pare them.

Static code analysis allows us to perform statis-

tical analysis to evaluate and compare programming

languages against each other. Likewise, the empirical

study of programming language could evidence fac-

tors that led the designers to adopt or not determined

language, helping in the decision making about which

the best ﬁtting programming language for one speciﬁc

scenario (Meyerovich and Rabkin, 2013).

2.1 Related Work

The overwhelming majority of research from litera-

ture addresses code analysis over the desktop, server,

or web perspective. We have been selected works that,

in some way, address code analysis from the embed-

ded systems outlook.

Prashant and Gurumurthy (Joshi and Gurumurthy,

2014) investigate optimizations at the source code

level to ARM processors in the embedded system

context. Their research addresses loop transformation

techniques; Their results point to a gain of 40% con-

cerning the code density and by 30% in the speed of

operation.

Kienle et al. (Kienle et al., 2012) explore static

code analysis up a speciﬁc system. They presented

a case study of an industrial embedded system devel-

oped with C language. As a result, the authors re-

ported insights that can be used as a complement to

more generic code analysis tools.

Otherwise, Oliveira et al. (Oliveira et al., 2008) in-

vestigate the relationship between quality metrics for

software products and physical metrics for embedded

systems. They used Java language and concluded a

strong correlation between quality metrics for tradi-

tional software products and performance metrics for

embedded systems.

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

224

Commonly, code analysis approaches for em-

bedded systems concern the devices’ performance

and sometimes overlook the software quality met-

rics. Therefore, it is essential to evaluate the impact

over source code apart from performance considering

other panoramas such as the developer or software en-

gineering perspective.

We explore JavaScript as an alternative to pro-

gramming language in the Internet of Things context.

Furthermore, to the best of our knowledge, this is

the ﬁrst evaluation of the JavaScript language over-

development viewpoint applied in the embedded soft-

ware domain. In particular, we investigate the advan-

tages and disadvantages (focusing on constrained de-

vices) of JS against C language regarding resource

consumption and software quality metrics such as

complexity, maintenance, and reuse.

3 METHODOLOGY

We developed two versions of the same applica-

tion using C and JavaScript language. The appli-

cation consists of home automation integrated with

the Google Smart Home platform (Google Actions,

2021). It allows users to control their devices through

the Google Home app, Google Assistant (via voice

command), and custom applications. In particular,

this automation proposal controls an automatic garage

door opener through 433MHz frequency.

Each command from the server to the IoT device

is represented as a JSON object (JavaScript Object

Notation) that describes the request, device, and ac-

tion to perform. This object is called Google Home-

Graph. Furthermore, we included an extra parame-

ter (RFCode) inside the model, which contains the bi-

nary code to interact with the garage opener. Finally,

we collected the RF code to open and close the door

through the RF receiver sensor.

Regard the hardware, we elected the ESP8266

NodeMCU-12E (NodeMCU) (ESP8266 NoDEMCU-

12E, 2021) as the microcontroller. It is a popular de-

velopment board integrated with a Wi-Fi communi-

cation chip, 80MHz CPU frequency, 64kB of mem-

ory, and 4MB for storage. According to the RFC

7228 (RFC 7228: Terminology for constrained-node

network, 2021) parameters, it is considered a con-

strained IoT device. In addition, we use the FS1000A

433MHz RF transmitter (Components Info, 2021) for

wireless communication between the IoT device and

embedded garage door circuit. Figure 1 presents the

application ﬂow for the proposed application.

Figure 1 shows that the user can start the interac-

tion by saying a command. It is processed at Google

Execute

Intent

Node MCU

Context Awareness

UM2C

Power Meter Power Supply

433MHz

Application

Back-end

(JavaScript)

IoT Device

CJS

Hey google

Google Cloud

Command Status

Figure 1: Application ﬂow.

cloud, which ﬁnds an intent and sent to the application

server, and ﬁnally, it notiﬁes the edge device. This

process could be started without voice command us-

ing the Google Home app or any in-house applica-

tion. If the user has Google devices in the same net-

work, the command cannot need to be processed on

the cloud server because these devices can load and

run custom applications (written in JS) inside upon.

From that, the communication is over Wi-Fi, reduc-

ing the latency and increasing reliability.

To enable JavaScript on IoT devices, we need

an interpreter to execute JS code. For this experi-

ment, we selected Espruino (Espruino, 2021). Espru-

ino is an Open Source JavaScript engine for Micro-

controllers that has a full coverage of ES5

and par-

tially ES6 features. Furthermore, Espruino provides

ﬁrmware with support ESP8266 board and web IDE

to development.

We collect execution time and memory usage

from JavaScript performance API and ESP8266 SDK

on JS and C algorithms. C program was compiled

over Arduino IDE by default optimization settings.

Regarding power consumption, we connected a mul-

timeter in series with a battery and supplied ESP8266

from that. As a power meter, we selected the UM2C

USB (UM24c USB Tester, 2021).

We performed a static code analysis from C and

JavaScript source code to extract software quality

metrics. For that, we selected the Halstead-Metrics-

Tool (Software Engineering Research Group at Po-

litecnico di Torino, 2021) to collect Halstead Metrics

and Lizard tool (Terry Yin, 2021) to collect Cyclo-

matic Complexity. In addition, to insurance the evalu-

ation approach, we apply the code analysis tools over

the Ostrich Benchmark Suite (Khan, Faiz and Foley-

Bourgon, Vincent and Kathrotia, Sujay and Lavoie,

Erick, 2014), aiming to evaluate the results of these

tools on external (neutral) codes and compare them

with the results obtained from our source code to ﬁnd

behavior patterns.

ES is an acronym for ECMAScript; This is the ofﬁcial

name of JavaScript language used in its speciﬁcation.

Improving Developer Productivity on Internet of Things using JavaScript

225

4 RESULTS AND DISCUSSION

Programmers can propose different solutions to the

same problem. We developed the algorithms to keep

the source code as simple as possible, deﬁning only

the necessary structure and importing some libraries

in order to facilitate the development. This section

shows the analysis from performance and developer

overview.

The algorithms comprise a web server that re-

ceives and processes post requests. We created RF

and STATUS endpoints to send radio-frequency com-

mands (RF) and get the device status, respectively.

All the requests contain a JSON object for data in-

terchange between the layers following the Google

HomeGraph format.

4.1 Performance Analysis

The data extraction was performed from a set of ex-

ecutions of each algorithm. Every single request was

repeated 50 times to obtain data consistency and more

reliable analytical information. The results represent

the average of the executions or the sum of them.

Although both algorithms were deployed over the

same hardware, the experiment points out signiﬁcant

performance variations regarding memory consump-

tion. Table 1 shows the memory usage details.

Table 1: Memory consumption (bytes).

Lang. Used (%) Free memory Total

C 5924 (11,09) 47512 53436

JS 19880 (62,12) 12120 32000

JavaScript solution attained in huge memory con-

sumption compared to the C algorithm. This high-

memory consumption occurs because the JavaScript

engine reserves memory space for the entire

JavaScript heap. Also, external libraries, which typi-

cally use buffers, demand a large amount of memory

(Hong and Shin, 2020).

Moreover, the available memory for each imple-

mentation is distinct as well. The C solution had

≈ 53kB, and at the same time, the JavaScript ap-

proach had 32kB only. That happens because part

of the memory space is reserved for ESP8266 SDK

to support Wi-Fi and TCP/IP protocol. In particular,

the Espruino engine uses 20kB for itself plus 8kB for

TCP/IP buffers.

Regarding execution time, we measured how long

it took to process each request, and we clustered the

results by algorithms. Figure 2 resumes performance

data by language. In addition, each graph shows

JavaScript results twice because Espruino sets the

ESP8266 clock to 160MHz by default, but the C al-

gorithm works over 80MHz. In this way, we decided

to expose all of the data.

Section “a” in Figure 2 reports the experiment in

which the 433MHz RF transmitter is used to open or

close the garage door. C algorithm has taken a longer

time than JS. In a deep analysis, we found that most

time is spent sending RF commands through the RC-

switch library. In contrast, section “b” exposes that C

is, at least, four times more efﬁcient than JavaScript.

Finally, Figure 2 still reveals the data about energy

consumption.

The results represent the sum of power consump-

tion from 50 runs recorded over the whole executions.

In general, JS ﬁgures out to consume more energy

to develop the algorithms. It happens because the

JavaScript engine performs optimizations in order to

gain performance. Such analysis implies direct CPU

usage, so it has an extra energy cost. The only excep-

tion is when RF commands are used, and C had the

worst consumption.

Overall, C’s performance is better than JavaScript,

as it was supposed. However, the JavaScript applica-

tion got a satisfactory outcome, and the decision to

use it is not merely about performance issues. We

consider other aspects around the developer process

or associate to post-development, such as mainte-

nance and reuse. Thus, We processed the solutions

from the programmer’s perspective.

4.2 Developer Analysis

Listings 1 and 2 present chunks of the source code

from both algorithms; conﬁguration and device con-

trols have been suppressed, keeping the focus on busi-

ness logic. The full code can be found at the GitHub

(The garage door, 2022).

1 // ...

2 void loop () {

3 s e r ver . hand l eCli e n t () ;

4 }

5 bool is O p ened () {

6 r e t urn dig i t alRe a d ( m agn e t _sw i t ch ) == HIGH ;

7 }

8 void h a n dle r S tat u s () {

9 if ( is V a lid R e que s t () ) {

10 const siz e _ t b uffer S ize = 2 * (

JS O N_AR R AY_ S I ZE (2) + J SON _ OBJE C T_S I Z E (6) );

11 D y nam i c Jso n Doc u men t r eque s t Args ( bu f ferSi z e ) ;

12 d e s eri a lize J son ( reques t A r g s , serv e r . arg ( "

plain " ) );

14 D y nam i c Jso n Doc u men t doc (1 2 8 ) ;

15 doc [ " s uccess " ] = true ;

16 doc [ " reque s t Id "] = req u e stAr g s [ " requ e s tId " ] ;

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

226

100

200

300

400

500

C JS (80MHz) JS (160MHz)

Time in milliseconds

(a) RF Request

0,5

1,5

2,5

3,5

C JS (80MHz) JS (160MHz)

Time in miliseconds

(b) STATUS request

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

C JS (80MHz) JS (160MHz)

Energy Milliwatt-hours

(mWh)

0,02

0,04

0,06

0,08

0,1

0,12

0,14

C JS (80MHz) JS (160MHz)

Energy Milliwatt-hours

(mWh)

(d) STATUS request

Figure 2: Execution time / Energy consumption by endpoint.

17 doc [ " isOpen e d " ] = i s Opene d () ;

18 s e n dRes p onse ( doc ) ;

19 }

20 }

21 void ha n d lerR F ( ) {

22 if ( is V a lid R e que s t () ) {

23 const siz e _ t b uffer S ize = 2 * (

JS O N_AR R AY_ S I ZE (4) + J SON _ OBJE C T_S I Z E (11) ) ;

24 D y nam i c Jso n Doc u men t r eque s t Args ( bu f ferSi z e ) ;

25 d e s eri a lize J son ( reques t A r g s , serv e r . arg ( "

plain " ) );

26 D y nam i c Jso n Doc u men t cmd = r e ques t Args [ " i n p u ts

" ][0][ " payloa d " ][" co m m ands " ][0][ " exec u t ion "

][0];

27 const char * a ction = cmd [" com m a n d " ];

28 const int perc = cmd [" par a m s " ][" o p enPe r c ent "

];

29 const long RFCode = c md [" pa r a m s " ][ " R F C o d e " ];

30 if ( s t r c mp (action , " ... com m a nds . Open C l ose ")

== 0 ) {

31 bool exec u t ed = fa l s e ;

32 Str i n g m e ssage ;

33 if ( perc == 1 0 0 ) {

34 if ( ! isO p e ned () ) {

35 exe c u ted = p erfor m R F ( R F Code );

36 mess a g e = " Op e n i ng t he door ";

37 } e l s e {

38 mess a g e = " Door is alrea d y open " ;

39 }

40 } else {

41 if ( isOpe n e d () ) {

42 exe c u ted = p erfor m R F ( R F Code );

43 mess a g e = " Cl o s i ng t he door ";

44 } e l s e {

45 mess a g e = " Door is alrea d y c l o s e " ;

46 }

47 }

48 D y nam i cJso n Doc u men t doc ( 1 2 8 ) ;

49 doc [ " succes s " ] = e x ecute d ;

50 doc [ " reque s tId "] = req u estA r g s [" req u e stId " ] ;

51 doc [ " messag e " ] = m e ssage ;

52 s e n dRe s p onse ( doc ) ;

53 } e l s e {

54 ser v e r . send (400 , " text / plain " , " I n v alid

com m a n d " );

55 }

56 }

57 }

Listing 1: C chunk of code.

Listing 1 represents the C implementation in

which the endpoints are deﬁned on method “hander-

Status” (lines 8-20) and “handlerRF” (lines 21-56).

Entry parameters and return are expected in JSON

format, and for this reason, it requires manual man-

agement of the space in memory in order to allocate

the data (lines 10; 23).

Moreover, Google’s operating model presupposes

that the garage door control has an open percentage

level. In this sense, we consider the value of 100 per-

cent to open the door and any value different from

this to close one. Listing 2 shows the JavaScript im-

plementation.

1 // ...

2 c o n s t L ight E xpre s s = r e q u ire (" ligh t - ex p r e ss ");

3 c o n s t N o deMcu = r equire ( " nod e - mcu " );

4 c o n s t node = n ew Nod e M cu ();

5 c o n s t s e r ver = new L igh t E xpre s s ();

6 s e r v er . p o s t ( " / rf ", ( req , r e s ) = > {

7 c o n s t cmd = req . b o d y . inp u t s [0]. p a y l oad . comma n d s

[0]. e x ecuti o n [0];

8 c o n s t r e s ult = node . perf o r mRF (

9 cmd . c o m m and ,

10 cmd . p arams . openPerce n t ,

11 cmd . p arams . RFCode

12 );

13 if ( r e s u lt ) {

14 r e s ult . r eque s t Id = data . req u e stId ;

15 res . e nd ( JSON . s t ring i f y ( r e s ult )) ;

16 } e l s e {

17 res . write H e ad ( 4 0 0 ) ;

18 res . e nd (" In v a l id comma n d " );

19 }

20 }) ;

21 s e r v er . p o s t ( " / status " , ( req , r e s ) = > {

22 c o n s t d a t a = r e q . body ;

23 c o n s t r e sult = {

24 re q u estI d : d a t a . requestId ,

25 is O p ened : node . isOpe n e d () ,

26 };

27 res . e n d ( JSON . s tring i f y ( r e sult )) ;

28 }) ;

29 s e r v er . l i sten (80) ;

Listing 2: JavaScript chunk of code.

Note that the business logic is, apparently, differ-

ent between the two algorithms. For instance, the log-

ical process from lines 30 until 47 on Listing 1 does

not appear on Listing 2. This feeling occurred be-

Improving Developer Productivity on Internet of Things using JavaScript

227

cause the chunk of code was isolated in a common

class to reuse it on other application layers. Listing 3

exposes the standardized code.

1 c l a s s E xec u t ion H and l e r {

2 p erfor m R F ( action , perc , R FCode ) {

3 if ( a c t i on == " ... c o mmand s . O p e nClos e " ) {

4 let m e ssage ;

5 let e x ecute d = f alse ;

6 if ( perc == 1 0 0 ) {

7 if (! this . i s Opene d ( ) ) {

8 this . s e ndRF ( RFCode );

9 mes s a g e = " Op e n i ng t he door ";

10 exe c u ted = t r u e ;

11 } e l s e {

12 mess a g e = " Door is alrea d y open " ;

13 }

14 } else {

15 if ( this . isOp e n ed ()) {

16 this . s e ndRF ( RFCode );

17 mess a g e = " Cl o s i ng t he door ";

18 exe c u ted = t r u e ;

19 } e l s e {

20 mess a g e = " Door is alrea d y c l o s e " ;

21 }

22 }

23 ret u r n {

24 s u c cess : executed ,

25 m e s sage : message ,

26 };

27 }

28 }

29 }

Listing 3: JavaScript standard class.

The class ExecutionHandler encapsulates the ap-

plication logic, and it should be noted that the meth-

ods “isOpened” and “sendRF” do not exist in this

class. In this case, we follow best practices for de-

veloping adopting the Template Method design pat-

tern, aiming the speciﬁc implementation in a sepa-

rated class. This is essential to promote ﬂexibility and

contribute to interoperability among layers since each

microcontroller may have distinct hardware speciﬁca-

tions. Finally, Listing 4 show the speciﬁc board class.

1 c l a s s N o deMCU ext e n ds Exe c utio n Han d l er {

2 i sOpene d ( ) {

3 retu r n d igit a l Read ( D2) == 1; ;

4 }

5 s e n dRF ( c o d e ) {

6 req u i re (" RcSw i t ch ") . c o n n ect (6, D4 , 3) . s e n d (

cod e , 28) ;

7 }

8 }

Listing 4: JavaScript modeMcu class.

Listing 4 represents the custom implementation

for the ESP8266 NodeMCU board. For example, if

we needed to implement to another microcontroller,

like Raspberry PI, we would need to create only one

class to give the abstract methods, and the rest of the

structure could be reused. Table 2 presents the static

code analysis from the algorithms; the values inside

the table represent a number on a magnitude scale ac-

cording to each criterion.

Table 2: Code analysis details.

Metric C JavaScript

Program length 803.0 440

Program vocabulary 140 100

Estimated length 905.56 567.29

Purity ratio 1.13 1.29

Volume 5724.81 2923.30

Difﬁculty 52.03 45.00

Program effort 297887.75 131548.35

Time to program (h) 4.6 2.03

Cyclomatic complexity 2.1 1.8

As before illustrated, the measures shown in Ta-

ble 2 point to the overall quality of the produced pro-

grams. We conducted the code analysis over the C ﬁle

and all JavaScript ﬁles; the JavaScript measurements

mean the average ones. In contrast to the performance

examination, JavaScript overcomes C in all items, and

in some cases, the results can be almost twice:

• Program length: The size of the program;

• Program vocabulary: Number of operators and

operands that composes the program;

• Estimated length: Metric of size estimated remov-

ing everything from program except operators and

operands;

• Purity ratio: This metric assesses the code length

based on its actual length. This is an optimiza-

tion indicator, so the lower the ratio is, the greater

the chance that excessive code implements func-

tionality, and a higher ratio (above 1.00) indicates

optimized code;

• Volume: Its measures the size of the implementa-

tion of an algorithm;

• Difﬁculty: Difﬁculty level or error proneness of

the program is calculated from the number of

unique program operators;

• Program effort: Represents the mental activity a

programmer performs to transform an algorithm

into a program;

• Time required to program: It represents the time

to develop or understand a program;

• Cyclomatic complexity: It indicates the complex-

ity of a program based on the number of deci-

sion statements in the code, methods, and lines of

code.

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

228

Regarding the cyclomatic complexity index, this

measure represents how complex each code was con-

sidered. Empirical veriﬁcation shows that the C algo-

rithm got a higher complexity index than JS. Table 3

shows the detailed complexity analysis.

Table 3: Cyclomatic complexity details.

lang. nloc

token

Funct. count CCN

C 102 78.6 8 2.1

JS 74 51.8 6 1.8

Number of lines of code without comments;

Token count of functions

Cyclomatic Complexity Number

Although the advantage of JavaScript over the C

language is clear, it was conducted from a source de-

veloped and proposed by us. Thus, we decided to

apply the same tools over an external set of algo-

rithms to compare the results and ﬁnd some behav-

ior patterns. For that, we selected the Ostrich Bench-

mark Suite (Khan, Faiz and Foley-Bourgon, Vin-

cent and Kathrotia, Sujay and Lavoie, Erick, 2014).

This benchmark provides some facilities for evaluat-

ing JavaScript against C because it gives the same im-

plementation of the algorithm in both languages.

The code analysis results

from the Ostrich bench-

mark showed that JavaScript has a balance or superior

behavior; it matches with the analysis performed from

code produced in this experiment, leaving us conﬁ-

dent about the result achieved. Also, it allows us to

indicate JavaScript as an alternative for the Design

Space Exploration phase.

Nonetheless, IoT solutions are not simple as we

proposed. But, the experiment demonstrated that JS

could enhance the reuse of code and enable the build

of standard components. For instance, on automa-

tion systems that need to consider different hardware

sensors and actuators, JavaScript provides the tools

to create solutions, frameworks, and libraries to inte-

grate all of them, increasing the developer experience.

Regarding performance, It is strongly related to

the JavaScript engine. Few engines are available

on constrained devices, and the consumption of re-

sources depends on how optimized it is. The algo-

rithm by itself has a signiﬁcant contribution to how

the application performs, which can vary accord the

JS engine. So programming on IoT devices is not a

trivial task. We need to ﬁnd the balance between de-

velopment, execution, and resource consumption.

Moreover, JSON format has become a common

format to transfer data inter applications. To use it on

The full analysis can be found in the appendix at the

GitHub repository (Paper Appendix, 2022)

the C algorithm, we need external libraries and per-

form calculations to allocate the objects in a balanced

way. On the other hand, JavaScript can facilitate some

action, and their event-based model has a strong ad-

herence to the IoT execution model.

JavaScript architecture for this proposal was pro-

jected to be simple and understandable, and at the

same time to enhance the software quality and stan-

dardize the developer process. These approaches in-

crease the level of abstraction and improve design

productivity. Also, it is clear that software quality

has a strong relation to the consumption of resources

(Oliveira et al., 2008), (Papadopoulos et al., 2018).

Finally, the developing application for heteroge-

neous context like IoT, behind challenging, requires a

simple programming model to be feasible (Krishna-

murthy and Maheswaran, 2016). Also, the advance of

virtual machines like Espruino, Duktape, JerryScript,

and Moddable make JS a real option to programming

constrained devices.

5 FINAL REMARKS

This paper evaluated whether JavaScript could be

used as alternative to C language for coding on the

IoT-context. We were able to develop two version

of the same application and collect information about

the consumption of resources such as execution time,

memory, battery and analyzed the source code using

software quality metrics.

We could identify that the JavaScript performance

penalty is acceptable compared to the gain in abstrac-

tion and reuse in embedded system design. In addi-

tion, embedded software is not a stand-alone artifact.

Thus, using the same language in all application-stack

simpliﬁes and standardizes the development process,

implying positively in a more suitable environment

for interoperability, reducing cost, and optimizing

maintainability.

In future studies, we intend to explore which as-

pects of JavaScript language impact more device per-

formance, mainly related to memory consumption.

Also, we will deepen the investigation of how to

JavaScript engine could affect this process since it is

key to enable JavaScript as a language for the IoT en-

vironment.

ACKNOWLEDGMENT

This study was ﬁnanced in part by the Coordenac¸

de Aperfeic¸oamento de Pessoal de N

ıvel Superior -

Improving Developer Productivity on Internet of Things using JavaScript

229

Brasil (CAPES) - Finance Code 001.

REFERENCES

Bhattacharya, P. and Neamtiu, I. (2011). Assessing pro-

gramming language impact on development and main-

tenance: A study on c and c++. In 2011 33rd Inter-

national Conference on Software Engineering (ICSE),

pages 171–180. IEEE.

Binkley, D. (2007). Source code analysis: A road map.

In Future of Software Engineering (FOSE ’07), pages

104–119.

Components Info (2021). Fs1000a 433mhz rf trans-

mitter. https://www.componentsinfo.com/fs1000a-

433mhz-rf-transmitter-xy-mk-5v-receiver-module-

explanation-pinout/. Accessed: Mar. 2022.

Ebert, C. and Jones, C. (2009). Embedded software: Facts,

ﬁgures, and future. Computer, 42(4):42–52.

Eclipse Foundation (2020). Iot developer survey

2020. https://outreach.eclipse.foundation/eclipse-iot-

developer-survey-2020. Accessed: Mar. 2022.

ESP8266 NoDEMCU-12E (2021). Espressif ofﬁcial doc-

umentation. https://www.espressif.com/en/support/

documents/technical-documents. Accessed: Mar.

2022.

Espruino (2021). Javascript interpreter for microcontrollers.

https://www.espruino.com. Accessed: Mar. 2022.

Farshidi, S., Jansen, S., and Deldar, M. (2021). A deci-

sion model for programming language ecosystem se-

lection: Seven industry case studies. Information and

Software Technology, 139:106640.

Google Actions (2021). Google smart home platform. https:

//developers.google.com/assistant/smarthome. Ac-

cessed: Mar. 2022.

Halstead, M. H. (1977). Elements of Software Science (Op-

erating and Programming Systems Series). Elsevier

Science Inc., USA.

Hong, G. and Shin, D. (2020). Segment-based multiple-

base compressed addressing for ﬂexible javascript

heap allocation. IEEE Access, 8:185405–185415.

Joshi, P. V. and Gurumurthy, K. (2014). Analysing and im-

proving the performance of software code for real time

embedded systems. In 2014 2nd International Con-

ference on Devices, Circuits and Systems (ICDCS),

pages 1–5. IEEE.

Khan, Faiz and Foley-Bourgon, Vincent and Kathrotia, Su-

jay and Lavoie, Erick (2014). Ostrich benchmark

suite.

Kienle, H. M., Kraft, J., and Nolte, T. (2012). System-

speciﬁc static code analyses: a case study in the com-

plex embedded systems domain. Software quality

journal, 20(2):337–367.

Krishnamurthy, J. and Maheswaran, M. (2016). Chapter 5

- programming frameworks for internet of things. In

Buyya, R. and Vahid Dastjerdi, A., editors, Internet of

Things, pages 79–102. Morgan Kaufmann.

Liggesmeyer, P. and Trapp, M. (2009). Trends in embedded

software engineering. IEEE software, 26(3):19–25.

Meyerovich, L. A. and Rabkin, A. S. (2013). Empirical

analysis of programming language adoption. SIG-

PLAN Not., 48(10):1–18.

Mushtaq, Z., Rasool, G., and Shehzad, B. (2017). Multi-

lingual source code analysis: A systematic literature

review. IEEE Access, 5:11307–11336.

Oliveira, M. F., Redin, R. M., Carro, L., da Cunha Lamb,

L., and Wagner, F. R. (2008). Software quality met-

rics and their impact on embedded software. In 2008

5Th International Workshop on Model-based Method-

ologies for Pervasive and Embedded Software, pages

68–77. IEEE.

Oshana, R. and Kraeling, M. (2019). Software engineering

for embedded systems: Methods, practical techniques,

and applications. Newnes.

Papadopoulos, L., Marantos, C., Digkas, G., Ampatzoglou,

A., Chatzigeorgiou, A., and Soudris, D. (2018). In-

terrelations between software quality metrics, perfor-

mance and energy consumption in embedded applica-

tions. In Proceedings of the 21st International Work-

shop on software and compilers for embedded sys-

tems, pages 62–65.

Paper Appendix (2022). Appendix a: Source code

analysis from ostrich benchmark algorithms on

github repository. https://github.com/fernandotetu/

the-garage-door-opener/blob/main/Appendix

A.pdf.

Accessed: Mar. 2022.

Pimentel, A. D. (2016). Exploring exploration: A tutorial

introduction to embedded systems design space explo-

ration. IEEE Design & Test, 34(1):77–90.

RFC 7228: Terminology for constrained-node network

(2021). Internet engineering task force (ietf). https:

//tools.ietf.org/html/rfc7228. Accessed: Mar. 2022.

Severin, T., Culic, I., and Radovici, A. (2020). Enabling

high-level programming languages on iot devices. In

2020 19th RoEduNet Conference: Networking in Ed-

ucation and Research (RoEduNet), pages 1–6.

Software Engineering Research Group at Politecnico

di Torino (2021). Halstead metrics tool. https:

//github.com/SoftengPoliTo/Halstead-Metrics-Tool.

Accessed: Mar. 2022.

Terry Yin (2021). Lizard cyclomatic complexity analyzer.

https://github.com/terryyin/lizard. Accessed: Mar.

2022.

The garage door (2022). Github repository. https://github.

com/fernandotetu/the-garage-door-opener. Accessed:

Mar. 2022.

Thole, S. P. and Ramu, P. (2020). Design space

exploration and optimization using self-organizing

maps. Structural and Multidisciplinary Optimization,

62(3):1071–1088.

Transforma Insights (2021). The inter-

net of things (iot) market 2019-2030.

https://transformainsights.com/news/

iot-market-24-billion-usd15-trillion-revenue-2030.

Accessed: Mar. 2022.

UM24c USB Tester (2021). Hangzhou ruideng technolo-

gies. https://rdtech.en.alibaba.com/. Accessed: Mar.

2022.

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

230