Programming language rankings get regular headlines, and they should, at least from trend trackers like us. Among my favorite is the RedMonk quarterly, published this week. I like the methodology of their system, which extracts data from GitHub and Stack Overflow and combines them for "a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction."
In other words, it correlates what the cool kids are talking about with actual language usage "in an effort to extract insights into potential future adoption trends." It's a mix that makes it meaningful.
The latest ranking was posted by veteran industry analyst Stephen O'Grady on his RedMonk blog. "GitHub and Stack Overflow are used here, first, because of their size, and second, because of their public exposure of the data necessary for the analysis," he wrote.
O'Grady's post includes thoughtful observations about JavaScript, TypeScript, Ruby, Go, R, Kotlin, Rust, and Dart.
There's quite a lot of change afoot in the programming world, the analysts found, but constant has been the rise of Python, which has maintained its top ranking ahead of Java. "Java was extremely hot on Python's heels – and was in fact closer to the number one ranking than to PHP behind it – but Python's ability to defend its new high ranking is notable," O'Grady wrote.
Half of the Top 20 languages experienced "a degree of movement," O'Grady added, "which is very unusual. It's difficult to attribute this definitively to any higher level macro trends, but the data is consistent with an industry that picked the pace back up in the last two quarters of the year after the initial chaos of lockdowns and so on gave way to livable if extremely suboptimal new routines."
JavaScript is holding its own in the rankings. "[I]t is worth noting just how robust JavaScript's performance remains," O'Grady observed. "In spite of all of the competition from up and coming languages, all the discussion of fragmentation and even criticisms of JavaScript the language itself, it remains remarkably popular.
JavaScript pull requests are up 453% since Q1 of January of 2018, and they were up 96% from the last quarter "on an already massive base of commits." '
'Simply put, JavaScript remains – its detractors notwithstanding – a force of nature like no other within the industry," he wrote, "and there are no indications in the data that this is likely to change any time soon."
TypeScript, which is a superset of JavaScript, moved up for the sixth of its latest eight quarterly RedMonk rankings, "and its popularity is evident when one looks around the industry." Ruby is on a gentle long-term downward trajectory, the analysts found. Go is slipping, too. R, a language for statistical computing and graphics, appears to be on a slow upswing. Both Kotlin and Rust showed signs of growing popularity. And Dart, an open source, purely object-oriented, optionally typed, and a class-based language, has risen since the advent of the Flutter framework.
Th RedMonk report surrounds a cool plotting of the language rankings with detailed analysis of key trends over the past quarter. As far as I'm concerned, it's a must read.
Posted by John K. Waters on March 4, 20210 comments
Foojay.io, the community site for developers who use, target, and run their applications on top of Java and OpenJDK, today announced the companies who will make up its advisory board. The roster includes Azul, Datadog, DataStax, JFrog, Payara, and Snyk. This board will guide the direction, content and oversight of the site, with a focus on growing the community and meeting its mission to provide free information for everyday Java developers.
In case you missed it (which I must confess, I did), Foojay is a nascent-but-evolving-at-warp-speed Java information consolidation site for everyone from hard-core, in-the-trenches Java jocks to the Java curious. And it is a thing of beauty. It organizes information from multiple sources into logical categories and delivers the warts-and-all info you won't see on the vendors' sites.
The site has articles, definitions (via the adorably named "Foojaypedia"), an events calendar, a Java Version Almanac that goes back to the Java 1 released in 1996, and up to Java 16. It lists OpenJDK vendors and distributions. There's a "What's New in OpenJDK/OpenJDK Update Release Details" section, and a section called "OpenJDK Command Line Arguments," with info on all the JVM command line arguments from Java 6 onwards. And the "Foojay Today" section publishes blog posts.
Running the project is the inimitable (and unpronounceable) Geertjan Wielenga, senior director of Open Source Projects at Azul and author of the must-read book Developer, Advocate! He talked with me about the project, which was started in April of last year, and has grown rapidly beyond early expectations. He said he thinks of it as a Java dashboard curating all the latest information for developers using Java daily,
"Back when I worked at Sun Microsystems," Wielenga told me, "you could go to Java.net and find blogs, opinion polls, and information about Java on a common community platform. And it was easy, because there was only one JDK and there were new releases only every year or so. And there was only one vendor. Since then, you could say Java has diversified, or you could say it has fragmented, but either way, we now need a layer on top of all these different OpenJDK vendors, distributions, releases, and various disparate Java communities, so that somebody starting from scratch has a place to go, and so does someone wanting a launching pad for being productive in a safe place."
The ultimate goal is to create a community like Java.net, Wielenga said.
"Foojay is an example of the strength and longevity of the Java community that is greater than any single company," said Stephen Chin, VP of Developer Relations at JFrog, in a statement. "It is composed of active, passionate, and caring individuals who want to share their expertise and help mentor the next generation of developers. We're excited to be part of the conversation and help the community leverage modern CI/CD and cloud-native technologies for our beloved Java."
Posted by John K. Waters on February 4, 20210 comments
The Eclipse Foundation's move to Europe continues apace with the formal establishment last week of the Eclipse Foundation AIBL, its new international non-profit association in Brussels, Belgium. The new European entity launches with the support of founding members Bosch, Daimler TSS, IBM, and SAP, the Foundation said in an announcement.
The Eclipse Foundation is one of the world's leading open-source software foundations, steward of the Eclipse IDE, enterprise Java, and the Eclipse MicroProfile, and the heart of a global ecosystem of developers, companies, and public sector entities. By moving its legal residence from the United States to Belgium, the Foundation has created "a global institution that builds on its existing membership base, active developer community, and strong institutional relationships to enable collaboration and the free flow of open source software innovation throughout the entire world," the announcement reads.
I talked with the Foundation's executive director, Mike Milinkovich, who has led the organization since its founding nearly 17 years ago, about the move last year. This seemed like another milestone moment to catch up, and he reminded me that "this is a proh-sess, not an event." (Canadians.)
"This is going to end up being a couple of years from the time we started to the time we're done" he said, "before we can say that we've fully completed the transition and emerged on the other side with our organization as it's going to be in the long term."
When Milinkovich talks about "the transition," he's not talking about shipping office furniture, of course. The move of the Eclipse.org Foundation, Inc., from a Delaware-based 501 C (6) non-profit organization to a Belgium-based 501 C (6) non-profit (also recognized by U.S. laws) involves some heavy lifting on the software side, and a couple of moving vans worth of membership agreements; working group documentation; intellectual property, trust policy, and trademark guidelines; and now, with Jakarta EE, platform specifications. Nevermind remapping of the Foundation's bylaws from the U.S. to a different legal framework.
"It's going to end up being a couple of years from the time we started to the time we come out on the other side, fully completed," he said.
The story of how the Eclipse Foundation got here stems from the organization's discovery of an already large European footprint.
"It started in October 2019, when, during a Foundation strategy session held in conjunction with the EclipseCon Europe event just outside Stuttgart, Germany," Milinkovich explained. "We were doing strategy setting for the following year, and one our European based directors said that we seemed to be doing really well in Europe, and wondered if we could do an analysis of where we were Europe. And so we started crunching some numbers and we found out that 70% of our paying members and 70% of our developers were based in Europe. We had, gradually over time, become a very Euro-centric organization; in terms of the number of employees, projects, and developers we had over there, we actually already were the largest open-source foundation in Europe. Seeing the numbers in black-and-white really brought it all home."
"And if we didn't do something," he added, "someone else would."
The move has been "remarkably smooth so far," Milinkovich said. To keep track of the Foundation's progress, be sure to subscribe to the organization's blog.
And while you're at it, keep reading this one.
Posted by John K. Waters on January 21, 20210 comments
One of the biggest events in the Java universe last year was the official release of the Eclipse Jakarta EE 9 Platform, Web Profile specifications, and related TCKs. It moved enterprise Java fully from the javax.* namespace to the jakarta.* namespace. That's about all it did, actually, but it was an extremely consequential change.
I talked with lots of people about the latest shift in the evolution of enterprise Java, and one of the guys I was most excited to connect with on this topic was Bruno Souza, founder and leader of the Brazil-based SouJava, the largest Java User Group (JUG) in the world. Souza was one of the initiators of the Apache Harmony project to create a non-proprietary Java virtual machine, he serves on the Executive Committee of the Java Community Process (JCP), and he's on the board of advisors at Java-based Platform-as-a-Service (PaaS) provider Jelastic.
"I was very excited about Jakarta EE, and we [at SouJava] were onboard from the very beginning," Souza told me. "I think it was a very courageous move for Oracle to get all this awesome and extremely valuable IP and donate it to the Eclipse Foundation.… [When] you have this big player that does everything, it's very hard for anyone to come in and help. Oracle was this big guy doing everything, and so, everyone was just kind of doing small things around design… The only way to get a Java EE [community] that was more open and participatory was for Oracle to reduce its participation. And they did it!"
Souza offered kudos to the Eclipse Foundation and its executive director, Mike Milinkovich, even though Oracle refused to give up the javax.* namespace, forcing the foundation to adopt jakarta.*, and he believes the change will be better for the enterprise Java community in the long run. Souza was also on the side of the slow move, he said, and not a supporter of the so-called Big Bang, the plan for a complete change-over from javax.* to jakarta.*, which the foundation did employ.
"Mike was a superb negotiator in all this," he said, "I don't think people realize what a huge thing this was…. The Java trademark is very valuable and it impacts a lot of different things, so I do understand [Oracle's position]…. And I wasn't a fan of the Big Bang, but honestly, I got convinced, and when the decision was made, I got behind it. Instead of us having this process that's going to take years and years and years, let's do it once, 'ripping off the band aid,' so everyone can get mad this one time, and we move on from there."
The release of Jakarta EE 9 might not seem like a big deal, Souza said, because it was primarily a shift of name spaces with very little in the way of upgrades. But now that that herculean task is complete, the community has the ability to innovate free of potential constraints from a dominant commercial player.
"My expectation is that now people will feel that this change was slow," he said, "but if you look at the long history of Java EE, it's relatively fast, and the process is going to get a lot faster…. And I think people want an ecosystem they can trust."
I asked Souza about what seems to be the background role played by the JCP in this exceedingly consequential change in the Java world.
"The JCP is the standards organization, and the truth is, innovation does not happen within the JCP," he said. "Innovation has always happened outside the JCP, in the field, where you can experiment, go as fast as you want, and break things. The standards process is not the place to innovate. But I will say that the JCP was very clear and very much at peace with that idea. And the elephant in the room is that the JCP is an Oracle entity. It's very open, and we've made it even more open in the last few years. And at the same time I think that there's always a barrier to how open you can be when you're inside a company. With Jakarta EE, we broke from this barrier and now we have an independent organization, which Oracle and IBM and others are part of, that can run a standards process. So, I don't see the JCP as reducing in size, but Java as growing."
You can hear the rest of my conversation with Bruno Souza, in which he reflects on the future of Java, on The WatersWorks Podcast. It's available on Apple Podcasts, Spotify, and most other providers.
Posted by John K. Waters on January 7, 20210 comments
Bionic, a company offering a new application intelligence platform, emerged from stealth recently and caught my eye. The platform was designed to provide enterprises with the ability to understand and control the "chaos" created by the "onslaught" of application changes pushed to production every day."
"Basically, we realized is that, with everybody moving to cloud containers, Kubernetes, Agile, and DevOps, it's empowering developers like never before," Idan Ninyo, co-found and CEO, told me. "And they're releasing more and more changes into production every day. The result is developers are so empowered and independent it creates this chaos, because every developer can kind of do whatever he wants."
The Palo Alto, Calif.-based company was founded in 2019 by Ninyo and CTO Eyal Mamo to manage this chaos, Ninyo said. Both co-founders spent over five years in Unit 8200, the Israeli Intelligence Corps unit of the Israel Defense Forces responsible for collecting intelligence and code decryption.
Bionic's application intelligence platform automatically reverse engineers applications to deliver a comprehensive inventory with architecture and dataflows, monitoring critical changes in production, and enabling developer "guardrails" to enforce architecture. Bionic is agentless and designed to work across all environments, from on-premises monolithic apps to hosted cloud-native microservices.
Ninyo emphasized that Bionic's offering is not an observability solution.
"You can think about this technology as a kind of automated reverse engineering engine that deciphers the architecture when the developers get out of the binary or the script or whatever it is. And by doing so, we can create a full map of the production environment within minutes. after the point. Our current customers include developers, DevOps platform engineers, security--basically everybody needs this data."
The current pandemic could have thrown a wrench into the company's plans, but because it turned out to be something of an accelerator of digital transformation initiatives, Ninyo said, the platform has seen a rapid adoption uptake. (He and his partner ran the launch from Tel Aviv.) Bionic's app intelligence platform is currently in use by IT, operations, and security teams at pharmaceutical, financial services, and technology companies.
"The pandemic accelerated digital transformation efforts across almost all organizations, especially since employees are working from home and enterprises are becoming more reliant on their digital offerings," Ninyo said in a follow-up email. "That has made the issue of application chaos ever more acute for enterprise IT teams. All these organizations realize that they must maintain compliance, reduce risk, and improve resiliency without slowing down the rate of development."
Posted by John K. Waters on December 17, 20200 comments
Developers continue to adapt to the advent in nearly everything of Artificial Intelligence (AI), or more precisely, machine learning (ML) and deep learning (DL). And the tools are evolving with them and this growing demand.
One example is the OpenVINO toolkit. OpenVINO stands for Open Visual Inference and Neural Network Optimization. It's a toolkit developed and open sourced by Intel to facilitate faster inferencing in deep learning models on Intel hardware. It's based on convolutional neural networks (CNN), a deep learning algorithm designed for working with two-dimensional image data, although it can also be used with one-dimensional and three-dimensional data. The open-source version is licensed under and Apache License v2.
I talked with Bill Pearson, VP of Intel's IoT group, about his company's distro of OpenVINO.
"I suppose the key thing this tool does is to simplify the process of helping developers with their high performance inferencing needs," Pearson told me. "We're seeing a number of different use cases and requirements for doing inference--which silicon do I need, and what programming models on top of it. This can be quite confusing, so with OpenVINO, we created an API-based programming model that allows you to write once and deploy anywhere. What that means practically is, we take all the complexity of writing for FPGA, GPU, CPU, or whatever. We hide that complexity, so the developers have a consistent interface that lets them literally write once and then deploy to any of those different architecture types, depending on their needs and their requirements."
The first set of use cases Intel focused on were all computer vision related, Pearson said, because that's where most developers needed with inferencing. But with the most recent release of the toolkit, Intel is looking at inference beyond computer vision.
OpenVINO 2021.1, announced in October, is designed to enable end-to-end capabilities that leverage the toolkit for workloads beyond computer vision. These capabilities include audio, speech, language, and recommendation with new pretrained models; support for public models, code samples, and demos; and support for non-vision workloads in the DL Streamer component.
This release also introduces official support for models trained in the TensorFlow 2.2.x framework; support for 11th generation Intel Core processors (formerly code named Tiger Lake); and new inference performance enhancements with Intel Iris Xe graphics, Intel Deep Learning Boost (Intel DL Boost) instructions, and Intel Gaussian & Neural Accelerator 2.0 for low-power speech processing acceleration.
It comes with the OpenVINO model server, which is an add-on to the Intel distro, and a scalable microservice. "This add-on provides a gRPC or HTTP/REST endpoint for inference, making it easier to deploy models in cloud or edge server environments," the company said in a statement. Also, it's now implemented in C++, which enables reduced container footprint (for example, less than 500 MB), and delivers higher throughput and lower latency.
There's also a beta release due this quarter that integrates the Deep Learning Workbench with the Intel DevCloud for the Edge. The result: developers can now graphically analyze models using the Deep Learning Workbench on Intel DevCloud for the Edge, instead of being stuck on a local machine only, to compare, visualize, and fine-tune a solution against multiple remote hardware configurations. And there's another add-on: the OpenVINO model server, which provides a gRPC or HTTP/REST endpoint for inference, making it easier to deploy models in cloud or edge server environments. It's now implemented in C++, to enable reduced container footprint (for example, less than 500 MB), and deliver higher throughput and lower latency.
"We have to deliver features, of course, but we also need to deliver on performance," Pearson said. "With this release, that's what we've done. Applying CNN is helping us to take advantage of modern AI, to be able to get models that do a much better job at delivering what we'd expect from inference, and to be able to detect that defect or notice that object."
Pearson offered a customer example: "There are some great you know customer examples where we've seen this be the true. The earliest things we've seen are in finding manufacturing defects. There's an aluminum engine provider, who was doing inspections the old way--by hand. They had to wait for these objects to cool so that a person could turn it and look at it. You can imagine that doing that with a computer and a camera is going to be much more accurate and much quicker. And we've just seen this expand way beyond that to use cases in health care for medical screenings, and things like sewer pipe inspections--which basic, but essential--and in businesses like retail, where we're going through these frictionless checkout systems and trying to be able to see what objects are going through the scanner and track tell what what's being processed"
Intel OpenVINO is available today on its DevCloud.
Posted by John K. Waters on December 15, 20200 comments
The Eclipse Foundation's Jakarta EE Working Group today announced the release of the Jakarta EE 9 Platform, Web Profile specifications, and related TCKs. The Foundation made the announcement during its JakartaOne Livestream event, currently underway online.
This is the release that moves enterprise Java fully from the javax.* namespace to the jakarta.* namespace. It "provides a new baseline for the evolution and innovation of enterprise Java technologies under an open, vendor-neutral, community-driven process," the Foundation said in a statement. The fact that it doesn't do much more than that is the key virtue of this release, says the Foundation's executive director, Mike Milinkovich.
"It's important to understand that announcing a release in which the only thing we did was change the namespace was very much by design," Milinkovich told me. "When you're taking about a 20-year-old, multibillion-dollar ecosystem, and moving it forward, it's really important that you do it in a way that makes it as easy as possible for the ecosystem to come along with you."
The Foundation's Jakarta Working Group was established in March 2018, so they've been at this for a while. And the group has faced a few headwinds along the way--perhaps most notably Oracle's refusal to give up the javax.* namespace. The plan for a complete change-over from javax.* to the jakarta.* was, of course, controversial. The move even had a nickname: "The Big Bang."
"To be fair to Oracle, it's a two-decades-old platform they acquired from Sun Microsystems that had lots of legal constraints on it," Milinkovich said, "agreements that go back many decades. At the end of the day, I don't think there was any ill will or anything like that [from Oracle], and I even have to acknowledge that the engineering teams that we worked with from Oracle--who have made all this possible--were fantastic. It's unfortunate that we weren't able to just carry the javax.* namespace forward, because that would have been easier for everybody. But it just turned out to be an unsolvable set of constraints."
This namespace change firmly establishes Jakarta EE 9 as a foundation on which cloud-era innovations can be built for future Java infrastructure, the Foundation says. Also, Jakarta EE 9 enables enterprise end users and enterprise software vendors to migrate from older, previous versions to newer cloud-native tools, products, and platforms.
"Just changing the namespace is going to have a big impact," he said. "It allows the vendors who sell application servers--like WebLogic, WebSphere, JBoss, Open Liberty, Payara, etc.--the tooling ecosystem--IntelliJ, JetBrains, Apache NetBeans, our own Eclipse IDE--and the other Java runtimes--Spring Boot, Micronaut, Orcas, and the like--to migrate forward with the least possible disruption. We are now free to innovate in our own namespace."
Approximately 90 percent of the Fortune 500 are running enterprise Java apps in production, the Foundation has said, and the Jakarta EE 9 specifications "give new life to this massive installed base."
The enterprise Java ecosystem is generating more interest from vendors than it has in years, Milinkovich said, which is something of a validation of the Foundation's approach.
"On the vendor side, it had been whittled down to IBM, Red Hat, Payara, Tomitribe, and Fujitsu," he said. "But now, we're getting a lot more vendor engagement, participation, and support. All good things."
With this release the Eclipse Foundation is also announcing the
certification of Eclipse GlassFish 6.0.0, as well as several solutions working on compliance for 2021, including:
● Apusic AAS
● Fujitsu Software Enterprise Platform
● IBM Websphere Liberty
● Jboss Enterprise Application Platform
● Open Liberty
● Payara Platform
● Piranha Micro
● Primeton AppServer
● TMax Jeus
● WildFly
It's worth keeping in mind that specification approval was fresh territory for the Eclipse Foundation, and it had to put together a brand new specification process. Jakarta EE is being developed and maintained under the Jakarta EE Specification Process, which replaces the Java Community Process (JCP) for Java EE.
Accepting the stewardship of enterprise Java and shepherding its successful journey to Jakarta EE is a real feather in the Foundation's cap, Milinkovich said.
"I think a lot of other organizations might have given up along the way," he said, "but the persistence, experience, and intellectual property sophistication we have at the Foundation led us to find a path that got us to where we are."
The Jakarta EE roadmap for 2021 includes at least one more (huge) baby step in Jakarta 9.1: the move of the base platform from Java SE 8 to Java SE 11. Efforts are already under way for that release, though Milinkovich didn't offer a release date.
"I don't know when it's coming, but we're turning the crank as fast as possible," he said.
Moving the base Java platform from Java SE 8 to Java SE 11 is a logical next step in this process. Java eight is still the most widely used version of Java, and Java 11 is next in popularity.
"By moving this Java platform forward we're helping to modernize the Java ecosystem," Milinkovich said.
Posted by John K. Waters on December 8, 20200 comments
On Friday, December 4, JavaScript turns 25. The venerable client-side scripting language had a wobbly start when Mozilla co-founder Brendan Eich unveiled it in 1995, but today it runs on every Web browser, cell phone, Internet-enabled TV, and smart dishwasher.
When Java turned 25 in May of this year, online course provider Pluralsight shared the insights of its Java course authors on the impact of that juggernaut of a programming language and platform with ADTmag readers. The technology workforce development company turned to its popular JavaScript course authors on the occasion of the senior scripter's silver anniversary "to reflect on its impact and continued influence on the world, as well as their own personal journey with the programming language."
In addition to the wisdom of its teachers, Pluralsight is offering free access to 25 of its most popular JavaScript courses throughout December (five free courses a week). Also, check out the relaunched JavaScript.com, which includes new resources "designed to help JavaScript developers of all abilities."
How important is JavaScript today compared to when it first launched?
Cory House, @housecor: When JavaScript first launched, it was unclear if it would take off. It was written in a few days, and initially only offered in a single browser. Microsoft's first browser shipped with their own flavor of JavaScript, called JScript. Today, JavaScript makes the world go 'round. It runs on every computer. Every phone. TVs. Even some appliances. A huge portion of humanity relies on JavaScript every day without realizing it.
Jonathan Mills, @jonathanfmills: When JavaScript first launched, it was just there to help a webpage be interactive. JS is no longer contained to the browser. Now JavaScript has grown into a massive ecosystem that has impact in every area of software development. As a JS developer, I can write applications on the backend, frontend, mobile device, and IoT devices.
Nate Taylor, @taylonr: The easy answer is to talk about how JavaScript is used today across the entire spectrum of software development. From web applications, mobile applications, servers and even as stored functions in databases. And while that's true, I think it neglects the importance of JavaScript when it first launched. Prior to JavaScript's introduction, the web was not much more than static hypertext delivered in a browser. Without JavaScript, we likely don't have the web that we do today, but we didn't necessarily understand that when it was first released.
What makes JavaScript such a timeless programming language?
House: JavaScript is timeless because it's approachable, multiparadigm, and ubiquitous. There are multiple ways to accomplish a given task. You can code in an object-oriented or functional style. And since JavaScript has a C-like syntax, it feels familiar to people who have worked in other C-like languages. JavaScript remains "timeless" by continually embracing good ideas from other languages.
Mills: Honestly, I think it's a combination of simplicity and flexibility. The learning curve of JavaScript is much lower than the typical enterprise languages of C# and Java, so it is easy to pick up. But its flexibility in running everywhere and its very lightweight nature make it easy to get things done everywhere. The combination of those two things make JavaScript an easy tool to reach for given any job.
Taylor: I think the number one thing is the community. It's driven by countless engineers who are constantly exploring and trying out new things. Because of the community, we now have NodeJS, so that we can run JavaScript on the server. We have libraries like RamdaJS, which brings in concepts from functional programming languages and makes them accessible to JavaScript developers. We even have TypeScript as a super-set of JavaScript. And through all of that, the language has grown and adapted. In some ways, the fluidity of the language that causes so many of us problems when we first learn it, is part of what keeps it going even today.
What would the web or e-commerce look like if we didn't have JavaScript?
House: Without JavaScript, the web would be similar to the late 90's. Simpler and lighter-weight, but also less feature-rich. We'd have to post back to the server on every request, leading to a clunkier user experience.
Mills: While it's almost impossible to say what it would look like without JavaScript, I will say it would be fundamentally different.
Taylor: It would be slower and more frustrating. Imagine signing up for a service. The only way to know if your username was available would be to submit the entire form to the server and have it tell you if that was available. If the name was taken, you'd have to fill out the entire form again and resubmit. Eventually you would either find a unique name, or you'd give up. But with JavaScript, we're able to do this behind the scenes. While you're filling out the form--sometimes while you're typing the username--you can receive instant feedback if that name is available.
Additional problems would exist for e-commerce, as well. A common situation today is to see something in your cart and decide to change the quantity, or possibly even save it for later in a wish list. Those are relatively straightforward JavaScript calls. Without that, you would again be forced to resubmit the entire form until you were ready to proceed.
When did you first learn JavaScript? What impact has it had on you personally?
House: I learned JavaScript in the late 90s. It was awful. The debugging experience was horrendous. I often couldn't tell clearly what had failed. It ran significantly differently on Internet Explorer than Netscape. It was so painful early on that I embraced Flash and expected it to overtake HTML and JavaScript in popularity. Clearly, I was wrong! As JavaScript matured, so did related libraries and browsers. Today, coding in JavaScript is a wonderful, rapid feedback experience.
Mills: For the vast majority of my career I have been a backend developer in the .NET and Java space. But as the ecosystems grew and the sheer weight of projects increased, I found myself looking for alternatives that would let me solve business problems faster. I made the transition to node and AngularJS a while ago and have never looked back. The speed and reliability of the tooling is something I really enjoy.
Taylor: Sometime around 2009 was when I first started learning JavaScript. I didn't care for it, because I liked working on thick client applications in C#. That said, I did see its usefulness, particularly on one-side project[s], where I was able to use jQuery for a grid that was displaying data. Experimenting with that bit of JavaScript helped open several doors for me. It allowed me to interview for a web developer position that ended up changing the course of my career.
In addition to helping me land jobs for my 9-to-5 work, JavaScript also indirectly led me to more teaching as I advanced in my career. I found that JavaScript offered different ways of solving problems than I was used to. And in explaining those ideas to other developers I realized that I enjoyed helping others learn and grow. It was exciting to see developers grasp new ideas.
What does the future look like for JavaScript? What's coming next year, 2-3 years from now, etc.?
House: For around 10 years, JavaScript didn't change at all. Thankfully, today new JavaScript releases occur every June. In the short term, I expect to continue to see mostly minor enhancements that implement good ideas from competing languages. Longer-term, I expect to see JavaScript decreasingly used as a compile target. People will increasingly use languages that compile to JavaScript. Today, TypeScript is popular example, but we may see other more popular, higher-level alternatives in the future. And while Web Assembly is likely to grow increasingly popular in the coming years, it will continue to interface with JavaScript to get things done.
Mills: One of the primary complaints I have heard about JavaScript is that the massive open-source ecosystem is so hard to navigate and new frameworks pop up every day. I find that is less the case now than it was a year ago, and that trend will continue. I find most developers are using one of frameworks on the frontend (React and Vue), and almost everyone I know is using Express on the backend, and I see that trend continuing. Improvements will be made and features added, but for the most part, I think the ecosystem has solidified to a point that you can reliably pick up a tool and know that it will be around for a while.
Taylor: I think we've finally moved past the phase of JavaScript where everyone was making jokes about how fast a new library came out, and now we're to the point where we're trying to use it to provide real value to our users and clients. As a result, I think we'll continue to see JavaScript maturing. It will continue to get new features that help ease development in JavaScript. We'll continue to see more and more uses in areas that we don't immediately expect. It wasn't that long ago that it was not possible to write a mobile app in either Java or Swift, but now with frameworks like ReactNative, it's possible to use the same JavaScript skills that developers already have to create mobile apps.
Posted by John K. Waters on December 1, 20200 comments
This week's KubeCon + Cloud Native online event, wrapping up today, dominated our headlines this week, and for good reason. The flagship conference of the Cloud Native Computing Foundation (CNCF) was chock-a-block with vendor announcements and Kubernetes community news.
Among the noteworthy news from the CNCF itself was the publication of the results of its 2020 survey. Based on the responses of 1,324 members of the global cloud native community, the survey "takes the pulse" of that community to provide some clarity on where and how cloud native technologies are begin adopted.
My list of key takeways from this survey includes:
- The use of containers in production has increased to 92%, up from 84% last year, and up 300% from our first survey in 2016.
- Kubernetes use in production has increased to 83%, up from 78% last year.
- There has been a 50% increase in the use of all CNCF projects since last year's survey.
- Usage of cloud native tools:
- 82% of respondents use CI/CD pipelines in production.
- 30% of respondents use serverless technologies in production.
- 27% of respondents use a service mesh in production, a 50% increase over last year.
- 55% of respondents use stateful applications in containers in production.
Public cloud continued to be the most popular data center approach in this year's survey (that's three years in a row). It increased slightly in usage from last year (64%, up from 62%). Private cloud or on-prem usage had the most significant increase (52%, up from 45%). Hybrid decreased slightly (36% down from 38% in 2019). Multi-cloud usage, a new survey option this year, accounted for 26%.
"For the purpose of this analysis, hybrid cloud refers to the use of a combination of on-premises and public cloud," the report explains. "Multi-cloud means using workloads across different clouds based on the type of cloud that fits the workload best. The portability that Kubernetes and cloud native tools provide makes it much simpler to switch from one public cloud vendor to another. The addition of multi-cloud as an option this year does not necessarily explain the drop in hybrid unless respondents use a different definition."
The survey compiled responses from the community gathered between May and June 2020. Of those responding, 54% indicated their organization is part of the CNCF End User Community, which comprises more than 140 companies and startups "committed to accelerating cloud native technologies and improving the deployment experience." Many of the respondence were based in Europe and North America, but it was a worldwide survey: 38% were from Europe; 33% from North America; 23% from Asia; and 6% from South and Central America, Africa, Australia, and Oceania. Two-thirds of respondents were from organizations with more than 100 employees, and 30% were from organizations with more than 5,000 employees, showing a strong enterprise representation.
This is a thoughtful survey with more stats on release cycles, normalized use of containers, Kubernetes environments, "container challenges," and more.
Posted by John K. Waters on November 19, 20200 comments