JavaScript Dominance Not Assured – InApps Technology 2022

Much like how a stopped watch is right twice a day, it seems that, in the world of technology, if you just stay around long enough, the methods you knew long ago become the way to do things once again. This week, an article by Klint Finley over at GitHub’s ReadME Project tells a tale of the old becoming new again, with an exploration of all of the backend languages that are coming to the frontend.

Since the early days of networked computing, Finley writes, technology has been a pendulum swing, back and forth between server-side and client-side processing, with the past decade dominated by client-side JavaScript. “But a new crop of tools is sending the pendulum swinging back towards the server,” he writes.

Now, for those of you who remember creating web pages with those old backend languages (PHP forums in the early aughts, anyone?), you might regard the idea of returning to them once again as heresy. And on this point, Finley certainly sides with you, as he recounts the “(not so) good old days of web development”, as he puts it. This is not an argument to return to the methods wherein backend languages need to recreate full web pages with every single update, as was the case with those PHP applications of yesteryear. Rather, this new crop consists of tools like Phoenix, a framework for the programming language Elixir, and a feature called LiveView, which renders UI elements on the backend before sending them to the browser. Finley also points to other tools that take a similar approach, such as Laravel Livewire and StimulusReflex.

While the title of the piece might suggest that JavaScript should move out of the way, Finley ends on more of a balanced note, writing that “Perhaps what we’re seeing is not so much a pendulum swing, but a state of equilibrium where computing happens on both client and server in equal measure depending on the needs of the user.”

This point is one we’ve seen increasingly lately in the world of frontend (or backend as frontend, as it were) development. For example, when we recently looked at htmx as an alternative to JavaScript single-page applications (SPAs), both htmx creator Carson Gross and Svelte framework creator Rich Harris ended on a similar note of the idea of “transitional apps,” wherein not one approach would be relied upon entirely.

Much of the discussion of the article, which reached the top of Hacker News, is not necessarily in disagreement with the assertions put forth, but rather in what was not mentioned.

All the goodness of the browser as a platform will be available in whatever language you want, likely in a way that smells a whole lot like react or Vue. It will take a minute to ramp up to speed. But it’s the future.

— Adam Jacob (@adamhjk) February 10, 2022

Both WebAssembly and htmx were among the top two approaches seen as missing from the landscape, with both seemingly offering alternatives to the recent domination of JavaScript and its ubiquitous frontend frameworks. But while we call out these two as the primary contentions listed, the comments on Hacker News are a laundry list of different languages and approaches that might suffice. Whatever the way, it surely seems that JavaScript’s potential world domination is anything but certain.

pic.twitter.com/sgNDWs7tuc

— htmx.org (@htmx_org) February 8, 2022

This Week in Programming

• Test Drive Tech with IBM’s Dev Sandbox: IBM has previewed a Developer Technology Sandbox to help developers explore new technologies, a process that the company describes as normally being “a bit like being asked to assemble a car before giving it a test drive.” With the IBM Developer Technology Sandbox, by contrast, developers get “a turnkey solution” in the form of a “browser-based, no-code/low-code sandbox” that currently offers nine different technologies, such as video insights using Watson or anomaly detection from IBM Research. Not only can you try out the pre-built applications, but you can edit them and export the code directly to your own GitHub repository.
• Flutter Gets Stable Windows Support: When Flutter 2 launched last year, it was a significant expansion of platforms for which it could be used to target. At the time, Google wrote that it would allow developers to “use the same codebase to ship native apps to five operating systems: iOS, Android, Windows, macOS, and Linux; as well as web experiences targeting browsers such as Chrome, Firefox, Safari, or Edge.” The statement, however, was a bit aspirational, as full production support for desktop was yet to be released. In the case of Windows, this is no longer the case, as Google has announced Flutter for Windows. “Today marks a significant expansion of this vision with the first production release of support for Windows as an app target, enabling Windows developers to benefit from the same productivity and power that mobile developers have been enjoying,” they write. With this release, Flutter apps will be able to “use every part of the Flutter framework, and on Windows, it can also talk to the Win32, COM, and Windows Runtime APIs either directly through Dart’s C interop layer, or using a platform plugin written in C++.” All of this lands in Flutter 2.10, alongside various other features, performance improvements and bug fixes, and they say that stable support for macOS and Linux is on the way.

• Google’s Summer of Code Opens to Orgs: This year’s Google Summer of Code (GSoC) is marching forward and is now open for mentor organization applications, which means that open source projects and organizations can now apply to participate until Feb. 21 at 10 a.m. PT. The program, which pairs new open source contributors with open source projects, actually extended its eligibility last year by getting rid of its requirement that participants be students, and instead it is not open to all new open source contributors over the age of 18. This year’s program will be the 18th edition, with projects from 175 to 350 hours over the course of 12 to 22 weeks. If you’re part of an open source project that wants to help some new developers get into open source, GSoC is certainly one way to do it, and now’s the time to apply. As for you developers who wish to get in on the action, that application period opens soon. Check out the detailed timeline for all of the deadlines.

• The Time to Quit Using Old Visual Studio Versions is Now: For those of you still using older versions of Visual Studio, the time to upgrade is coming soon, as detailed in a blog post outlining the end of support for various versions. This all comes as part of a push to, well, stop supporting old software, but also to push developers onto Microsoft’s latest IDE, Visual Studio 2022, which arrived at the end of last year. Make sure to check out the post for all the dates, but know that the updates apply not only to much older versions, such as Visual Studio 2012 and Visual Studio 2017, but even more recent versions such as Visual Studio 2019 version 16.7. Microsoft offers this quick summary: “It’s time to complete your migration from Visual Studio 2012 to a later supported version. It’s time to move off the Preview Channel of Visual Studio 2019 to Visual Studio 2022 Preview. It’s time to move off Visual Studio 2019 version 16.7 to Visual Studio 2019 version 16.11 or Visual Studio 2022.”
• More Thoughts on the Future of Rust: Last up this week, Rust core developer Niko Matsakis offered up his thoughts on where he’d like to see the language go next. “To me, the theme that keeps coming to mind is dare to ask for more. Rust has gotten quite a bit nicer to use over the last few years, but I am not satisfied. I believe that there is room for Rust to be 22x more productive and easy to use than it is today, and I think we can do it without meaningfully sacrificing reliability, performance, or versatility,” Matsakis writes. In the blog post, he explains how he’d like to see more in terms of making Rust easier to learn, more in making Rust asynchronous (Matsakis is part of the async working group), and more in terms of Rust tooling. The overall theme, if you didn’t catch on, is that he wants Rust to be more. “It can sometimes be very tempting to say, ‘Rust is good enough, you don’t want one language for everything anyway’ and leave it at that,” he writes. “For Rust 2024, I don’t want us to do that. I think Rust is awesome. But I think Rust could be awesomer.” Read on for all his ideas of just how much awesomer Rust could be.

Every few years someone says “what if the internet were 3D!!! And websites were PLACES!!!” and then invents the worst internet experience possible

— Jules Glegg ️‍⚧️ (@heyjulesfern) February 6, 2022