Skip to main content

Advertisement

SpringerLink
Log in

Factors and actors leading to the adoption of a JavaScript framework

  • Published:
Empirical Software Engineering Aims and scope Submit manuscript

Abstract

The increasing popularity of JavaScript has led to a variety of JavaScript frameworks that aim to help developers to address programming tasks. However, the number of JavaScript frameworks has risen rapidly to thousands of versions. It is challenging for practitioners to identify the frameworks that best fit their needs and to develop new ones which fit such needs. Furthermore, there is a lack of knowledge regarding what drives developers toward the choice. This paper explores the factors and actors that lead to the choice of a JavaScript framework. We conducted a qualitative interpretive study of semi-structured interviews. We interviewed 18 decision makers regarding the JavaScript framework selection, up to reaching theoretical saturation. Through coding of the interview responses, we offer a model of desirable JavaScript framework adoption factors. The factors are grouped into categories that are derived via the Unified Theory of Acceptance and Use of Technology. The factors are performance expectancy (performance, size), effort expectancy (automatization, learnability, complexity, understandability), social influence (competitor analysis, collegial advice, community size, community responsiveness), facilitating conditions (suitability, updates, modularity, isolation, extensibility), and price value. A combination of four actors, which are customer, developer, team, and team leader, leads to the choice. Our model contributes to the body of knowledge related to the adoption of technology by software engineers. As a practical implication, our model is useful for decision makers when evaluating JavaScript frameworks, as well as for developers for producing desirable frameworks.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2

Similar content being viewed by others

Notes

  1. DOM is an application programming interface (API) set and a model that defines the logical structure of web documents and the way a document is accessed and manipulated (van Kesteren et al. 2015).

  2. AJAX is a set of web development practices and techniques for enabling asynchronous web applications on the client-side (Garrett 2005)

  3. XMLHttpRequest is a specification for an API that provides client-side functionality for transferring data between a client and a server (van Kesteren et al. 2014).

  4. CSS is a set of style rules that apply visual properties to elements of a web document (Atkins et al. 2015)

  5. They were 1573 when we first submitted the present paper.

  6. We thank an anonymous reviewer for suggesting to look into UTAUT,

  7. Mediating factors to technology adoption are gender, age, experience, and voluntariness of use (Venkatesh et al. 2003). We do not consider these mediating factors as we do not test the theory in this study.

  8. Stol et al. (2016) have conveniently summarized the major proposals for grounded theory, including coding techniques.

  9. Our quotations are verbatim excerpts, except for spelling and punctuation corrections. If we applied changes to wording (for comprehensibility), these are indicated by square brackets.

  10. One reason for our reworked definition is that, in our interpretation of the data, our participants saw their job-related productivity proxied both by application performance and ease of their daily operations, that is effort expectancy as we describe in the next sub-section. This is in line with the general open debate regarding what developers’ productivity actually is (see for example, Cheung et al. 2014; Fagerholm et al. 2015; Kettunen2013), as well as when applying UTAUT in the context of software engineering, where performance expectancy can be interchanged with effort expectancy (Hong et al. 2011; Stefi 2015). We opted to support our participants both ways, and concentrate gains in the product’s performance as performance expectancy, while ease of use and programming effort belong to effort expectancy in the next sub-section.

  11. Several implications emerged from the data, and we first report them near the relevant evidence.

  12. See footnote 10.

References

Download references

Acknowledgments

We would like to thank all the participants of this study.

Our gratitude goes to the editor and three anonymous reviewers whose feedback improved our original efforts immeasurably.

Daniel Graziotin has been supported by the Alexander von Humboldt (AvH) Foundation.

Author information

Authors and Affiliations

  1. Faculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy

    Amantia Pano

  2. Institute of Software Technology, University of Stuttgart, Stuttgart, Germany

    Daniel Graziotin

  3. Faculty of Information Technology, University of Jyväskylä, Jyväskylä, Finland

    Pekka Abrahamsson

Authors
  1. Amantia Pano
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Daniel Graziotin
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Pekka Abrahamsson
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Daniel Graziotin.

Additional information

Communicated by: Emerson Murphy-Hill

Appendix

Appendix

1.1 Interview skeleton

We developed a generic open-ended interview skeleton, which was maintained to guide the interviewer toward the logical flow of the questions to be asked.

  1. 1.

    How long have you been developing for the Web?

  2. 2.

    Which was your first programming language for the Web?

  3. 3.

    Which languages do you use for the front-end/back- end?

  4. 4.

    Do you rely on any frameworks for developing? If yes which ones? If no, do you develop in pure JavaScript?

  5. 5.

    When did you start learning Java/JavaScript?

  6. 6.

    Have you ever used JavaScript frameworks? Which ones?

  7. 7.

    Which libraries did you use?

  8. 8.

    Why did you choose this scripting framework?

  9. 9.

    What did you like most about this framework/library?

  10. 10.

    How long did it take you to learn the framework?

  11. 11.

    What do you think of the quality of the framework?

  12. 12.

    Would you recommend this framework to others?

  13. 13.

    Do you think the framework you used was mature enough? How?

  14. 14.

    Were there any functionalities that you liked or disliked?

The question draft was used as a guideline for several interviews, except for special cases, such as those where the participants had developed their own JavaScript frameworks or were not using any JavaScript framework but were programming in pure JavaScript language. In these cases they were posed questions like:

  1. 1.

    Which features similar to other frameworks did you include?

  2. 2.

    How do you decide which new features to integrate into your framework?

  3. 3.

    When did you decide to move from frameworks to pure JavaScript?

  4. 4.

    Would you generally recommend pure JavaScript or frameworks?

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Pano, A., Graziotin, D. & Abrahamsson, P. Factors and actors leading to the adoption of a JavaScript framework. Empir Software Eng 23, 3503–3534 (2018). https://doi.org/10.1007/s10664-018-9613-x

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10664-018-9613-x

Keywords

Search

Navigation