We have been considering moving JavaScript into our core curriculum for vocational-readiness reasons. However, our core CS curriculum focuses on concepts that won't become out of date.

There are certain languages that are pure, or close to pure, and lend themselves to teaching certain concepts. Java (or Eiffel) for Object Oriented Programming makes sense. Scheme, OCaml, SML, or especially Haskell is similar for functional programming. Many other languages can, of course, be used for these concepts! But sometimes the language itself brings advantages to bear when learning fundamental concepts.

We have wide discretion about what goes into our curriculum, but we are a little unsure about what core programming or theoretical CS concepts would be natural to teach using JavaScript. We are considering functional programming, but that feels a bit Frankensteinian. Would concurrency be a great fit? Event-based programming? Is there something else that we are missing entirely?

  • $\begingroup$ When you say "core programming or theoretical CS concepts" do you mean that answers can range from trade-skill to ivory-tower academic suggestions? $\endgroup$ Commented Dec 13, 2018 at 8:41
  • $\begingroup$ @PeterTaylor I suppose I mean, "concepts that will never go out of date". So algorithms or math are obvious shoe-ins, but some trade skills would also most definitely fit that description. $\endgroup$
    – Ben I.
    Commented Dec 13, 2018 at 15:43
  • $\begingroup$ JavaScript. Jack-of-all-trades, master of none. Best used in that role? Not sure what role a jack-of-all-trades languages has in a CS curriculum (other than as an introductory language), which is why this is a comment and not an answer. $\endgroup$ Commented Feb 18, 2019 at 18:47
  • $\begingroup$ @BenI. 4 years later, do you have new insight for your own question ? $\endgroup$ Commented Mar 7, 2023 at 7:50
  • $\begingroup$ @Qiulang邱朗 Nope, not a thing. My favorite insight here comes from Michael0x2a's answer about frameworks, but we never did integrate JavaScript into our core. It didn't seem to fit naturally enough with what we otherwise needed to teach. Cores move slowly, however, so this is all still an ongoing conversation. $\endgroup$
    – Ben I.
    Commented Mar 7, 2023 at 12:17

5 Answers 5


Maybe a bit of an orthogonal answer, but let me try to refocus your thinking. I don't think that teaching a lot of languages, especially if they are similar to one another in some way is a big advantage for students. Giving them experience with different paradigms (ways of thinking) on the other hand is a big advantage. While I prefer Java (for its libraries), Ruby is actually a more pure OO language as, is, of course, Smalltalk and its successors. Scheme or Haskell can be used for FP, of course, and one has actual syntax.

Javascript, on the other hand is another OO language. It is different from the usual candidates, however, since it is prototype, rather than class, based. But that is a detail that an experienced OO programmer can become familiar with outside of any course.

But, many universities have a Language Principles course in the curriculum in which students study the fundamental ideas of languages without necessarily building a compiler for any of them. An older book covering this is by Ravi Sethi. You need to be careful that you focus on "principles of" and not "examples of" languages, however. But it is a good place to take a meta level view of languages and paradigms.

But if you want to have students learn a new language, especially one for which they also grok the basic paradigm, a project course is a good way to do it. Students build something significant in a new language. If you design the project you could also require aspects that they haven't seen much of before, such as concurrency.

But I would recommend against forcing the use of a language in a way that isn't natural to its design. While Java now has functional elements, I wouldn't use it to teach about FP as a paradigm. Frankenstein built a monster, of course. No need to repeat it.

  • $\begingroup$ Sadly, Java is a strict requirement imposed from the outside, which is precisely why we are not using languages like Ruby. We use Python for AI/ML, C for stack/heap management and pointers, and 6502 for assembly. JavaScript may be effectively being imposed on us, and the question is really about how to make the best use of it. It doesn't seem (to me!) like it's a great fit for anything substantive, so I'm hoping I'm missing something. $\endgroup$
    – Ben I.
    Commented Dec 12, 2018 at 17:17
  • $\begingroup$ "You need to be careful that you focus on "principles of" and not "examples of" languages, however." Kinda depends on what your goal is. I took a course called Comparative Programming Languages which looked at a fair few examples of languages, and was quite eye-opening about the process by which new languages are designed to try to fix shortcomings in previous ones. Since (allegedly) most CS grads end up designing at least one language in their lifetimes, there's value in thinking about the nitty-gritty of language design and not just about paradigms. $\endgroup$ Commented Dec 13, 2018 at 8:37
  • $\begingroup$ @PeterTaylor, that is a different course, as its name implies. $\endgroup$
    – Buffy
    Commented Dec 13, 2018 at 11:40
  • $\begingroup$ Who is forcing you, can you show them what harm it will do. I realised when creating software, that I was saying “No” to bad management depressions, and that this was not working. I then started saying “Yes I can do that, and the cost will be …”. The new response was, “Oh, don't do that, it is a terrible idea” $\endgroup$ Commented Dec 18, 2018 at 12:20
  • $\begingroup$ @ctrl-alt-delor, I'm pretty sure the OP is referring to the APCS exam structure. The exam is in Java and students need to know it to get AP credit. It is a really big deal for students as it can mean college credit and skipping a few elementary courses in college. $\endgroup$
    – Buffy
    Commented Dec 18, 2018 at 12:22

One idea which might be a bit too trade-schooly but which I offer in case you disagree: the practice of software engineering.

One big difference between Java and JavaScript is that Java has enormous standard libraries, and JavaScript has very little. In consequence, JS forces you to either reinvent the wheel or learn to use a package management system.

Use of revision control would also fit into the title I proposed, and obviously that can be done with almost any language.

It would take a lot of work to set up, but you could even do a kind of open group project where the class is divided in quarters for the first half of the practical side, with each group given a spec for a library and instructed to publish their implementation to an in-house repository. Then in the second half each individual must develop a project which uses the four libraries. Wrap up with written feedback on why they chose the dependencies they chose for the second half, and read out selected feedback to the class. The goal would be to learn by experience the value of documentation and encapsulation.


All programming languages are tools. Whether one is a programmer, a computer scientist, a student, or an instructor, the tool status of programming languages remains constant. Selecting the right tool for the job, out of those which are available at the time, becomes an exercise in itself. The second half of the exercise is how to use the tools you do have to achieve your objectives, even when the tool available is not the one you would prefer, nor even in the top tier of the tools best suited for the task.

JavaScript just might not have anything about it which makes it better than others available to you for covering, or demonstrating, any of the "core programming or theoretical CS concepts." Such a position, however, does not disqualify it for use as a teaching tool. Neither in your situation, nor in a general sense.

As stated, the choice to move JavaScript into your core curriculum is "for vocational-readiness reasons," rather than for some concept it demonstrates uniquely well. Perhaps, then, it ought to be used as a tool in the same direction. Not being a certified prognosticator my predictions are not worth much. Nevertheless, I think JavaScript will be a work-place tool for some time to come. Teaching it to your students is likely to be of value to them, even if there is no shining spot in theoretical concepts for it.

You can still use JavaScript as a tool to teach some concepts - educational concepts. Use the learning of JavaScript to teach them how to learn. Both how to learn in general, and how to learn a new coding language. Should they get into a career path that never sees the need for JavaScript code, they are still very likely to encounter the need to learn a new language at least once in their career, if not in their further education. Perhaps you can also include education on how to evaluate a language for its strengths and weaknesses, or a segment on how, and why, new languages are created.

Using such an approach enables inclusion of JavaScript in the curriculum and offers multiple objectives in the "vocational-readiness" direction. It also avoids following in Dr. Frankenstein's footsteps.


I was wondering the other day. Who would I hire?

  • Someone with good theory knowledge, that used educational languages (Eiffel for OO, scheme for functional, both for simple and creating DSLs). Or
  • Someone with some knowledge of the languages that we use here.

I think I would hire the people that learnt the educational languages, and so have a better understanding. I can then train then in the language that I use.

I see little value in the panic to teach what will be used at work. They will get this experience when they start work, or if they do a project using these tools (after learning to do it properly). And work will not teach them what they missed at school/college/university.

  • 1
    $\begingroup$ I'm afraid that you would be an outlier among employers. Sadly, I admit, too many want to hire those skilled in the technology of the moment, not thinkers. There are exceptions, of course. $\endgroup$
    – Buffy
    Commented Dec 18, 2018 at 12:23
  • $\begingroup$ @Buffy I think you are correct. Most job advertisements just list a bunch of skills. (They should read Bloom). However it may help them keep there job, and to acquire these skills. You can then use some shotgun approach to getting the skills: T shaped learning, learn the important stuff deep, and learn a load of stuff shallow. This helps with the tick boxes, and is a good thing anyway. $\endgroup$ Commented Dec 18, 2018 at 12:31
  • $\begingroup$ Unfortunately, my experience has been that @Buffy is correct. Also unfortunate is that the "technology of the moment" is a moving target and frequently changes between the time the students learn it and when they are ready for the job market. I suspect that the OP is aware of that disconnect and wants to teach the students what they can use, regardless of the "current trends" some years into the future. $\endgroup$ Commented Dec 19, 2018 at 1:57
  • $\begingroup$ @GypsySpellweaver ‘ "technology of the moment" is a moving target and frequently changes between the time the students learn it and when they are ready for the job market.’ — yet another reason not to teach technology of the moment, and to use the best languages for learning. $\endgroup$ Commented Dec 19, 2018 at 7:45

One interesting idea might be to ask your student to try re-implementing different parts of the web ecosystem, which would naturally involve using JavaScript.

For example, one project might be to guide your students through writing a simplified version of libraries like React or Angular -- probably after having your students use those libraries directly so they know what they're trying to emulate. This can be an opportunity to teach about some of the more interesting programming paradigms like functional reactive programming. (React was originally written in Ocaml, so you could maybe dovetail things there).

Alternatively, you could instead turn this into a mini compilers or parsing lesson: when writing React code, you can optionally embed HTML-like expressions (JSX) in your code. You could maybe explore having your students write a pre-processor for JSX: parsing and manipulating AST representing HTML-like expressions is probably going to be easier then manipulating ASTs representing full-fledged programs. (The one complication is that JSX is intermixed with JavaScript. So, to simplify this assignment, you should probably provide a regular JS parser the students can hook into/invoke.)

More broadly, I think teaching your students how more complex libraries or framework work is likely to be a more valuable and long-lasting skill compared to just teaching whatever language or library is trendy today. I don't think it particularly matters which library or framework you're implementing: the main value comes from the act of exploring some non-trivial implementation, and from "peeking" under the layers of abstraction we're already used to. And if you can give students exposure to JS (or whatever other language) at the same time, great.

A somewhat different idea is to double-down on compilers-related stuff -- JavaScript is actually a somewhat common target language (e.g. see languages like TypeScript or CoffeeScript that transpile to JS). For example, you could start by transpiling some homespun language into JS (or a simple language like lisp), then ask them to write an interpreter for their custom language, then finish off by asking your students to write a compiler generating webassembly. There's a lot of existing tooling/scaffolding you could probably use here to try and smooth out some of the rough edges. And to keep things simple, you'll have the student implement all of this in JS (or maybe TypeScript?), because why not.

The main disadvantage of these ideas is, of course, that it'll likely take a non-trivial investment of time to pull off. If you have only a few weeks to cover JavaScript, you'd likely need to significantly scope these project ideas down, or just not use them altogether. As the others have said, you'll probably want to avoid gratuitously welding two unrelated CS topics together, or avoid giving your students the "frankenstein" experience.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.