I thought this was interesting at first. An effort to push the JS environment towards standardization is a much needed initiative.
Then I saw the "initial projects" list.
"Appium, contributed by Sauce Labs, is an open source Node.js server..."
"Interledger.js, contributed by Ripple, enables instant payments and micropayments in any currency..."
"JerryScript, contributed by Samsung, is a lightweight, fully-featured JavaScript engine for Internet of Things..."
"Node-RED, contributed by IBM, is a flow-based programming environment built on Node.js..."
This made it very clear that the founding members of the "JS Foundation" are not interested in developing and promoting the best open source tools, those tools which are most deserving of broad adaption. To them, this is a way to promote their own tools. They aren't doing this for the good of the of JS ecosystem, they are doing it to push their own brands on developers.
Creator of Lodash here. From my experience the foundation is a pretty chill, hands off, non-profit. I sought out and voluntarily joined the Dojo Foundation early in Lodash's development (~2013). At the time the Dojo Foundation was the only JS foundation I knew of that was open to outside projects (the jQuery Foundation was really only for jQuery projects back then). Eventually the Dojo Foundation and the jQuery Foundation merged. It was great! Regardless of the name the foundation has proven valuable. Whether it's CLA management, PR bots, conduct reviews, representation at TC39, help with trademarks, licenses, legal, etc. they've always been friendly and more than happy to help. When possible they also hold events to educate and encourage new open source contributors which is pretty cool!
Did the jQuery Foundation have companies as sponsors? I am not familiar with how the jQuery Foundation functioned in the past. But I'm not really interested in the past--I'm curious about the future.
I apologize for not making it clear that my comment on pushing brands on developers was only in reference to the for-profit organizations; I assumed that would be self evident.
Since when has, as relates to the web, standardization above all else been a thing. The web's design was intentionally decentralized and has led to occasional Cambrian Era level explosions of features and tools, that simply manifest. If we "try" to make the next platform, we'll probably fail. If we keep on keeping on, and let it happen, we will certainly succeed.
Centralized, profit driven organizations certainly benefit from having a clear, standard road-map with which to direct their resource deployment so as to maximize return on investment. Their investment. Not to maximize community value.
Standardization of the web will be the death of the web. Building the web-browsers on standards has forced corporations to make their flavor of browser compatible with the world wide web, keeping them from making a proprietary www. But, to standardize a language is a whole other thing. Languages are best when they are maximally flexible, so they do not constrict one from expressing in the world what is currently only in one's imagination.
That is, in my opinion, why despite the crappy design of JavaScript it has been so successful. There are not many languages with less restrictions. Take that away and we'll have a whole bunch of Walmarts, all the same implementation of the same super efficient product with great user experiences for 98% of users. But as the web becomes the global commons, for an Earth with a population of 7.125 billion, well 2% is still 145 million people. So, if you want the perfect solution, the final answer, then standardization requires you to write-off those people, if you want to be intellectually honest about it.
That's a great attitude for the browser--and I completely agree that decentralization is important for the browser--but does your opinion here extend to server-side JS as well?
JS is a language, and my opinion is that languages should be maximally flexible. They must be maximally flexible because a language has the primary function of being the medium through which an individual might transmit their ideas. Since ideas are not limited, languages must not be limited. Server-side JS is still a language. Limiting the language will limit what can be expressed in that language. So, yes, I would say it extends to server-side JS. By simply moving expression upstream it does not change my opinion.
There is that saying, "The Medium Is The Message." The more restrictive the medium, the more restrictive, the more pre-defined, the message is by default. The less restrictive the medium, the less well defined is the default message.
except that we have many languages, each of which is designed for a slightly different purpose. It is generally more useful to have a wide range of single-purpose tools that can do one job very well, rather than a general-purpose tool that can do lots of things badly.
If you want an analogy, think of a knife. It can be used to cut things very well, but also serves as a really bad screwdriver, bottle opener, toothpick, tent peg, etc. Better to have a tool for each of these tasks than cut your thumb open mis-using your knife.
We maybe need one general-purpose language for trying new stuff out (and I'd argue that that language is actually LISP). The rest need to be single-purpose, designed to do a single job.
Javascript is designed to run in browsers, and recently to run on a server (mostly as a web server). Trying to write real-time systems (for example) in javascript is a bad idea; you can do it, but you will cut your thumb open and there are much better languages available to do it in.
I think the core point I'm trying to make is that programming languages are engineer's tools rather than artistic media. We use the tools to build the thing we want. Tell an engineer that the hammer is the thing being built and they'll tell you you're an idiot.
Are you suggesting for browsers to be sandboxed execution environments ?
Then it will be more like Java Applets or Flash applications, I think some restrictions have lead to better index ability(hyperlinks, search engines) , accessibility in web.
A better medium doesn't necessarily mean untamed or freer medium. If restrictions can create a medium which has better accessibility, then maybe they are not so bad.
I see a lot of comments here interpreting this as a push towards standardizing certain tools, yet I don't see anything on the site that suggests that is their mission, nor do I see any way they could possibly effect that kind of change.
There seems to be some kind of messaging problem in that we are reading totally different things into what this foundation is about.
Can you share why you think this foundation is trying to "push [any] brands on developers"? I just don't get it.
"By creating a center of gravity for the open source JavaScript ecosystem, the JS Foundation aims to drive broad adoption and ongoing development of key JavaScript solutions and related technologies and to facilitate collaboration within the JavaScript development community to ensure those projects maintain the quality and diverse contribution bases that provide for long-term sustainability."
This gave me the impression that they were focusing on standardizing tools (the "drive broad adoption" part especially).
As for "pushing brands on developers", well... You can't standardize and encourage broad adoption of a technology if you cultivate and support multiple technologies. Maybe two or three, but there is a need to champion a particular technology as the tool developers should adopt. And the JS Foundation seems to be specifically promoting tools of its members where it can.
Of course, if the interpretation that their goal is to encourage standardization is incorrect, then the point is moot.
Maybe I'm naive, but I didn't get this message either. Personally, I was happy to see webpack on the list. The only problem I've had since adopting it is figuring out best practices for edge cases. It's changed how I develop web apps (works awesome with Azure). Maybe if there was more collaboration I could learn how to use it better.
Pure speculation, but maybe some people see it as a last ditch effort to keep projects like jQuery relevant. I've run across a lot of negative opinions about it. I've known developers who will laugh if they see it in an app. I've seen some interesting uses where people import only specific functionality out of jQuery they want, cutting it way down. https://goo.gl/kWeIJe But honestly I haven't needed it for awhile now.
I don't think that qUnit, jquery*, or requirejs should be in the list of the tools we should be standardizing on today. Beyond that grunt and dojo are arguable. This looks like a list of mostly last-gen tools combined with a few tools that have kept up or still serve a purpose.
In the end, I just don't think it's a great list... webpack, moment, lodash, sure... but jQuery UI, really? I mean bootstrap is a bit long in the tooth today, but still very modern in terms of structure. lodash is setup in a way that you can pick only the parts you need/want... but a lot of these tools just aren't what you probably want to be using starting a project today.
After reading this comment, and given this is a rebrand of the jQuery foundation, I'm thinking the purpose of this may perhaps be just an effort to retain relevance by maintainers of outdated or waning JS tools.
Agreed, at least with webpack. My number one gripe with moment is that I have to shim it in when using webpack. It still expects to be added to global scope, just like jquery. I'd really like to find a modular version, or another project that has as much functionality.
Hello, date-fns author here (a Moment competitor). date-fns was designed for use with webpack, so unlike Moment it won't bloat your build with unused function. If you don't need IANA support, you'll love it https://date-fns.org/
Hi, the date-fns creator here. We don't have extended time zone support (IANA) and have much fewer translations. But all of that is in progress. Regarding date-manipulations date-fns combines all of the Moment functions and even more (that we found in other libraries; ~150 in total). Check it out: https://github.com/date-fns/date-fns
Not sure why this announce is so upvoted (maybe because the title is full of buzzwords?).
If we look at this announce:
* the jQuery foundation (jQuery + jQuery UI) becomes the JS foundation (jQuery + jQuery UI + IBM + Samsung + unknown companies)
* the list of founding members is awkward. IBM to unite the JavaScript community? IBM is the company who creates things like JSONx [1]. These founders have done nothing for the web, for JavaScript or for the open source community. Where are the main actors like Facebook, Google, Microsoft or Netflix?
This new partnership is an attempt to gain visibility by companies that are non-existent in the JavaScript community.
To be clear: the JS foundation will not make the JavaScript ecosystem finally less fragmented and more standardized (the common complaints on Hacker News).
>Where are the main actors like Facebook, Google, Microsoft or Netflix?
I'd argue that the main actors (and others) have driven the web backwards, not forwards. They've done this by the push towards capturing consumers in a walled garden, the rejection of open standards, the embrace of DRM, the selling of user private data for profit, etc.
You listed companies I'd invite to sit on the board of some kind of User Tracking Foundation, but not anything to do with open web development.
> I'd argue that the main actors (and others) have driven the web backwards, not forwards. They've done this by the push towards capturing consumers in a walled garden, the rejection of open standards, the embrace of DRM, the selling of user private data for profit, etc
That could well be. I just don't quite see what that has to do with moving Javascript forward.
That just opens a pedantic conversation on what "forwards" is, which is mostly relative. A PM will think "forward" is faster development, an engineer might view "forward" as better best practices and better mean software quality. "Forwards" to Facebook is more ad impressions.
The real answer is probably a combination of all the above, which qualifies for GP's comment.
I don't see the need for this to cherry pick a few project and push them with the Linux brand. The JS landscape is fragmented for a good reason and I don't see that as problem in fact, rather as a feature. With NPM and YARN we already have a good enough package management system and their platform can help me evaluate if a package is community supported enough. I'm talking about the stats that I can just check: number of stars, contributors and open/closed issue ratios.
If someone understood it better than me please add your thoughts.
First the term. By fragmentation I mean two things: 1) we have many libraries doing the same thing. 2) the implementation is JS is not the same in every environment.
If you are spending most of your time writing other languages which have a standard library, I can understand your opinion.
However, I see fragmentation as:
1) It introduces the opportunity everyone on the planet to give a shot at implementing something that may or may not be better than we consider today the best. For example I used a datepicker in my latest project but in the current it failed and I could replace it in 15 minutes rather than spending hours finding the issue with the "standard one". I'm not really experienced in the C++ world, but I guess people would call me crazy if I proposed a new stdio lib. Maybe there could be better libraries, who knows. It's a settled game there. See jQuery in JS land, it was for many years, "the golden tool". Now we have alternatives for more specialized workflows. Not everybody wears the same hat all the time.
2) EcmaScript is constantly evolving, that causes another fragmentation, but this also allows the dev community to propose changes, implement new features and create a really vibrant feedback loop. If you stick to the latest stable (currently ES5) you are safe to build whatever you like with great stability.
The fact that people can contribute is great, the fact that it is impossible to get started in modern JS development without making dozens of seemingly inscrutable choices is not.
Plain old HTML, CSS, and ES5 still work. You aren't forced to install Node and Gulp and any of those things. So I rather much thing the use of the word "impossible" is way out of line here.
They are the foundations, and I recommended them in this very thread. But that's not what most of us would call "modern JS development". The amount of extra stuff between the foundations and current "best practices" is exactly the problem.
"best practices" is just a phrase. There is no objective proof that what people call "best practices" is at all. Far more often, I've seen it used as a protectionism for not learning or trying new things.
Stuff like minification you probably want a pre-existing tool to do. It's stupidly simple and not that difficulty to integrate into any build process.
But stuff like transpiling is completely optional. ES5 is a really high level language. There isn't anything particularly "wrong" with it, not any more so than most any other language you'll end up using.
Start with understanding \JS... then understand ES6 and CommonJS style modules. From there, understand that babel is just a tool to let you use new syntax, which has stabilized a tot since ES6, there's a few bits for async still baking, but that's to be expected. Beyond this is the node-style callback, and more about Promises and async.
These are the core of it all... from there, it's a matter of picking the lego pieces you want to use. What I described above is no more complex than the JVM or extended .Net APIs, especially when you pick all the target options there... in fact the footprint is a lot smaller. Yes, it's a little harder to build something with the 2000 piece lego generic pack than it is with the guided here's a pirate ship with all the parts laid out. But that's what engineering is all about.
If you're really stuck, start with a boilerplate or starter generator tool, there's a few of them for whatever direction you are leaning. Don't worry about picking "the right one"... there is no true path. No matter what you pick, you're going to hit a wall that conflicts with your sensibilities. Angular has the biggest adoption of any web framework ever and only has a 44% approval rating for reuse. That means a LOT of people pick wrong. Adapt, learn, grow...
But for significant pieces of work it is still a hurdle which you must cross. Unless you're writing vanilla ES5 without any dependencies, you have to consider package management, build tools, how to load your modules, before even getting onto transpilation, minification etc.
I can see what's so great about the JS community, but the fixed cost to get to actual production-ready development is pretty high. And rolling your own bootstrapping tools seem pretty pointless given the longevity of any particular tool being the one to recommend. #jsfatigue!
I disagree. All those things you mention are entirely optional and it is very possible to create high quality code without them. My rule is, don't use them until you run into a problem that the tools solve, then you can use them while understanding exactly what problem the tool is meant to solve.
I do a lot of JS development and I think most dependencies are highly overrated. ES5 is a very high level language already. I use a package manager, but frankly, I'm considering stopping because there is a lot of value to being able to just keep a local copy and include scripts with a script tag. It forces you to manually update and inspect for regressions. You get a much better sense of your total payload size, too.
That's because "modern javascript" is not there yet, it's still in an experimental phase, we need transpilers and other stuff to use features that are not in a finished state. It will get better with time.
So when is Javascript not going to be in an experimental phase? A couple of years ago it would have been 'when browsers support ES6'. Now it's 'when browsers support ES7'. Next year it's going to be 'when browsers support ES8'.
To be fair, ES6 was huge. ES7, and probably ES8, are tiny by comparison with only a few new features. Once browser creators get caught up on ES6 it _shouldn't_ be too hard to stay caught up after that point.
But, most of experimentation isn't around the core ECMA features. The experimentation is happening around the toolchain, the libraries, the frameworks, etc. which are separate from stuff like ES6.
that's not correct, and he did address why it doesn't suck.
because it's not standardized.
some people do better with more complicated things, it's ok to need directions, not everyone does.
Exactly this. All of the upfront choices, will I make the right choice? I've been meaning to jump in and learn. After years of backend development (C#, Python, and some Go), I want to give JS a shot and at least experiment.
It's a daunting process that I keep pushing back as there is no immediate need.
The best thing to remember is that if you're doing it for fun and learning, you don't need anything but a plain old HTML5 and a plain old script tag. Once you feel you need something more than that for a particular project (or for work) you'll be better able to evaluate what's out there.
This. Someone starting out should not be using webpack, react, jquery, lodash, etc. etc. etc. You need to first learn vanilla javascript which requires nothing more than a browser and a text editor.
Realistically, you won't make the right choice. But that's okay. Because of the number and size of most packages, they are easily replaceable.
Like the commenter higher up said, it's not like C#, Python, or Go where if you have an issue with a library, it could take days to find and implement a replacement. The vast majority of libraries in JS land are small and single purpose. Think of it as replacing the air-filter in your car vs the whole engine.
But that can (and is) solved by either just "picking one of the big ones" and moving on, or by using even more tools layered on top to abstract away a lot of those choices (don't know anything about how to start with react? Just use react-create-app and go from there).
Then a couple years later you've learned a lot of arcane details about something that has already fallen out of fashion. It's not the end of the world but it's not optimal.
React is what 3-4yo now... given Redux is less than 2 years, and there was a LOT of churn on flux-like frameworks. But React + Redux will likely not go anywhere for the next 5+ years, it's already pretty well distilled. Similar tooling and alternatives will still be present, but this happens in any vibrant ecosystem. There was a similar burst in the alt.Net space before ASP.Net MVC and razor came out... even then there has been alternatives introduced.
You're not talking about a single application and platform. You're talking about the most flexible set of cross platform rendering engines ever created. How many UI toolkits are there for Windows, Linux and macOS for native apps, now add Android and iOS... The browser targets all of them, and the base app toolkits pretty much target them all, and still being more flexible and capable than what came before. Expand this to the number of tools available. How could this be anything but echoed in the JS sphere.
Given the shear breadth of Web development alone, let alone server-side, IoT, Desktop, embedded, mobile and who knows where else, how can there be anything but a lot of options and diversity.
That is not true at all. It's also not an issue that is going away. This is The Singularity. It's only going to get worse. Either you learn to adapt or you get left behind. And "adaoting" could mean, "learn to quit being a magpie distracted by evwry shiny new thing."
This seems to be true, but I see it as a consequence of how many resources are being devoted to JavaScript by major corporations and legions of developers versus other programming languages. Does Google, MS, Facebook, Apple, etc. ad naseum have entire departments devoted to improving Python, C, Ruby, etc.? Not as far as I know. If there were as many resources being thrown at C as there is at JavaScript I'm sure the churn would be just as high.
I concur with your experience that date-picker is a not yet solved problem. I disagree that I can find in 15 minutes an alternative that carries less risk repeating the same experience.
For the building to rise higher the foundations need some solidifying.
> I'm not really experienced in the C++ world, but I guess people would call me crazy if I proposed a new stdio lib.
Some would. But there are plenty of companies and projects with their own standard libraries. There's also serious (but early-stages) discussion within the C++ standards committee about developing an std2.
What exactly do you mean by js fragmentation? If that, you have power to pick from hundreds of lib/fw and combine them together, then what you call fragmentation is actual real benefit for me. I like to make decisions myself, but if you like the others to take decisions for you, js is probably not for you. The very good example is redux. Redux was once simple state management lib. Take a look at it now https://github.com/xgrommx/awesome-redux. That is real power of js ecosystem.
Obligatory self-plug: the "awesome-redux" list is cluttered and not well organized, and was actually rejected from inclusion in Sindre Sorhus's "awesome-awesome" list because of that ( https://github.com/sindresorhus/awesome/issues/714#issuecomm... ). On the flip side, I keep a list of Redux-related addons and utilities at https://github.com/markerikson/redux-ecosystem-links that is actively maintained and has (hopefully) much better categorization, as well as being a much more comprehensive list of all the useful pieces out there in the Redux ecosystem.
But yes, as I've said in some recent comments: Dan and Andrew found a sweet spot with Redux's design in terms of approach, concepts, and providing building blocks for others, and that's led to an explosion of useful stuff that people have built for their own use cases.
There are two schools of thought. The first is that you should optimise for the platform you're targeting, so a fragmented JS world is a good thing because you optimise for different things depending on where your code is going to run. The second school of thought is that you should optimise for development, and you should have the same language everywhere even if that means slightly less efficient code.
For example, if you write long running services in node then optimising for memory allocation in order to avoid leaks is a good idea. It's less useful for clientside things that generally don't run for nearly as long. Conversely, if you write isomorphic JS that can run in the browser but also needs to run on the server for that first-load advantage, then you'd prefer if things work the same everywhere.
Neither school is 'right' per se. How a language ought to evolve is incredibly subjective.
Yep, and, not that having to learn and become acquainted with shortcomings of new sets of languages/tools every other year isn't a fact of life for many devs that one ought to just accept. But having something run just (or as close as possible to) the same across many platforms make it more likely that that knowledge you acquired will remain among your best options when approaching a wide range of problems for a longer time.
Java 4 FOREVER!!!! f*ck maven... we like complex Ant configs... Generics can go to hell.
I mean this is a bit of hyperbole, but the point is that languages and platforms evolve, and given that JS has a bigger target surface than anything else in the history of computing, with more resources than anything else ever being poured into it, multiplied by approaches and opinions, how can it not be diverse. The world doesn't have the same houses everywhere either... Oh noes, they're building different styles of roofs over there.. the sky is falling.
I see it both as one of JS's greatest strengths, and greatest weakness's.
Certainly, at a prototyping/exploratory level, all of the freedom and choices are great!
For me, however, when you just 'need to get sh*t done', all the choices and configuration required to setup a project becomes a nightmare, commonly referred to now days as js fatigue.
I am looking forward to trying out http://www.electrode.io/ on my next project. Other than that, I have been digging into elm as a way to reduce the choices required and the cognitive load involved in setting a project up. It's great to have 'one true way' of doing things.
I've never understood this complaint. JS is used everywhere from browsers to servers to native apps to IoT. Does there really need to be One True Framework/Linter/Build tool/etc?Is it really that big a problem that people have made a lot of different tools and libraries because they're solving a lot of different problems?
I think the problem is keeping up. It's simple if you can pay attention, but if you're still on angular 1.x because you have other things to worry about, the fragmentation and pace means you can get years behind if you're not careful.
It's not like ruby has another package manager every 6 months.
I agree the many implementations probably are a feature, not a bug, but still induce fatigue. It's too easy to get behind.
Maybe I'm missing something really fundamental, but why try to keep up with everything? It's a huge ecosystem and any given dev/team can only use a tiny bit of it. If a library does everything you need it to, does it matter if you're years behind on it? (modulo e.g. security fixes)
I mean, certainly I agree that trying to keep current on everything would be a nightmare. But surely that's just the result of lots of people sharing lots of libraries, right? If other languages don't have the same problem, isn't that just because people aren't sharing as much code?
I think this is true, but JS also "sucks" in different ways, so not keeping up means expending seemingly unnecessary effort in maintainability, reliability, etc.
Angular 1 is impossible to maintain compared to Angular 2, for instance. Angular 1 fixed a lot of problems vanilla js faced. It's all improvements.
I only very loosely followed Node/npm for the first few years, as I was mostly working on windows. 0.8 kind of worked, and 0.10 was the first version that really worked, and npm was finally baked enough. That said, the few binary modules you came across rarely worked in windows, and there were some rough cuts along the way.
I know what the pain/churn was like then... I mean it's overwhelming, build chains, task runners, configuration files, tools changing left and right, exponential (for a while) growth... Not to mention more functional approaches clashing paradigms, the detour of bower, less vs sass vs whatever... It was a huge shift. But the backdrop has settled a lot... Yes, there are new options out every other day, but it's not like it was for a long while.
Node 0.12 through current is mainly about bringing in new JS engines and performance improvements and less about introducing sweeping changes. Webpack and Babel are now staples... ES6 modules will shake up the npm ecosystem a bit for the next while, but if you're using Webpack + Babel, you'll probably notice it less.
There's still growth, but the churn isn't quite as massive if you just concentrate on the core (JS, npm, webpack, babel) and less about specific modules (lego blocks) until you need a given brick.
The member list is amazingly small. The only well-known names and the only "platinum" names are IBM and Samsung, personally I never heard of any of the rest of the members before. I say "amazingly" for the amount of attention this gets (I first saw it on reddit and a number of other websites). I would expect to see at least Google and Microsoft and possibly Mozilla on there, and whoever represents node.js (the foundation itself, or someone).
The way this usually works AFAIK is that you try to get as much "buy-in" from as many important parties as possible before making the first big public announcement. It seems that in this case that didn't quite work out, and they instead hope to let the announcement itself be what starts the ball rolling to get more members on board.
This doesn't look like an attempt to pick winners, but to support the participating projects. Do you see anything about reducing fragmentation? (Not that that would be bad.)
It seems like it is promoting things that might be expanding JS' reach to other device running the Linux kernel rather than cherry picking projects in the existing common use cases. For example, sponsoring the only node server I've heard of that targets running on mobile devices, and an IoT appropriate interpreter are not like the net zero action of picking a winner among react/angular/ember/etc.
Expanding the jQuery foundation in this way is an exciting change, and one I'm interested to follow and learn from. Ember.js for example has taken some tips from how jQuery grew and managed itself, however we've also avoided what we think were some missteps.
I hope the organizers of JSF can share what works and doesn't with the wider community. If they want to solve fragmentation in JavaScript projects, no one organization will do that. The need to share their ideas where they work well.
I asked a few questions on Twitter yesterday to this end, and if there is a JSF member around I would really appreciate some thoughts:
* What are the motivations for moving to Apache 2.0 as a default license? I expect something about IBM and the patent clause. Does adopting this license attract more corporate participation?
A few years ago, some high profile organizations (W3C, Adobe, Facebook, Google, Hp, Intel, Microsoft, Mozilla, Nokia, Opera) came together to try to help standardize the web platform [1](Javascript, CSS, HTML). That was a HUGE failure - because it was driven by business rather than developers. How will the "Javascript foundation" do better?
I don't see how WebPlatform was about standardizing. The standards bodies already exist: W3C (with its various WGs), WHAT WG, TC39. The main goal of WebPlatform was to provide a consistent documentation for all standard web technologies -- which largely relied on volunteer work and competed with existing solutions like the Mozilla Developer Network (despite Mozilla supporting the project).
I don't see the JS Foundation being even remotely related to this. The JS Foundation is pretty much just a small Apache Foundation for JS projects. And it's not new: it's mostly a rebranding of the jQuery Foundation which has existed for years.
It's also decidedly not the "JavaScript Foundation". They don't have the trademark for JavaScript (I think technically Oracle still holds the JavaScript trademark with Mozilla having an unrestricted license to use it). It isn't affiliated with TC39 or any standards body and it doesn't steer the development of the language.
IMO the name is unfortunate unless they extend the scope beyond "we support a couple of open source JS projects".
Uh. That's a documentation site - basically a wiki. It didn't exactly catch fire, but it wasn't trying to standardize anything and it didn't fail to do so.
From my perspective the main benefit of this is there is now a non profit that can take over administration of JS projects the community values but the original developers want to abandon.
Has such an argangment ever worked in practice? I have read here on HN about how the Apache brand is used as a dumping ground for zombie projects. Why would it be different for the Linux Foundation?
Perhaps the original developers don't want to abandon these projects, the companies they work for are just not prioritizing funding their development. By placing the Open Source project under non-profit foundation ownership, that foundation can fundraise for their projects as a whole and then hire (at least for some hours) the original developers under that funding. I'm putting words in the JS Foundation's mouth though. It's not what they are saying in that press release.
Shocking how the javascript community has done just fine before this group of well funded enterprises organized and nominated itself as leader of that community.
This is an attempted capture of a major open source community by commercial interests.
"founding members include Bocoup, IBM, Ripple, Samsung, Sauce Labs, Sense Tecnic Systems, SitePen, StackPath, University of Westminster and WebsiteSetup."
There's a name missing there I would have expected to see. Starts with M. Mo... mo ... something.
"aims to drive broad adoption and ongoing development of key JavaScript solutions and related technologies and to facilitate collaboration within the JavaScript development community to ensure those projects maintain the quality and diverse contribution bases that provide for long-term sustainability."
Does this mean this new foundation will be offering funding for projects?
As confusing as this appears (are they going to handle new ECMAScript specifications? I am so confused), I am glad that they're supporting Moment.js. It has become one of my default libs, like jQuery, when working on a new project.
The JS Foundation is just the rebranded jQuery Foundation. Despite its name the jQuery Foundation already had a much broader scope than just jQuery (e.g. also Dojo).
The JS Foundation is not related to TC39, the organization in charge of new ECMAScript editions. I guess they might sponsor a TC39 member eventually and engage in JS advocacy beyond merely supporting JS open source projects -- similar to what the PSF and its affiliates do for Python.
Probably not much. The Node Foundation is also a Linux Foundation project and they continue using permissive licenses.
Also the JS Foundation already announced that they're adopting the Apache 2.0 license as the default license but that existing projects will keep their MIT/etc licenses. Their open source licensing policy is hidden in the "IP Policy" PDF linked in the footer: https://js.foundation/pdf/ip-policy.pdf
Quote:
> The technical governing body of each Project is free to choose, [..] the Apache License, Version 2.0 [..]. If an alternative inbound or outbound license is required [..], the Board of Directors of the JS Foundation (the “Board”) may approve the use of an alternative license for inbound or outbound contributions on an exception basis.
The Linux Foundation already has a wide variety of projects besides Linux which are covered by a number of different licenses depending upon the project.
Most likely? None at all. But it might ensure the long-term survival of some popular libraries that could otherwise eventually die off (kinda like Apache).
The feedback is interesting, but I think it helps to understand more of the history to get that most of the negative feedback here is overreaction. Some thoughts:
* No, the foundation isn't trying to dominate or tell people what to do. It's trying to support open source projects through their lifecycle. Running a project can be a rather lonely and frustrating experience at times, but can also be very rewarding
* Open source foundations provide legal protection to individuals and corporations that contribute and use open source software, and help ensure that one company or person doesn't turn evil and try to pull the carpet out from under the community (which has happened many times in the history of OSS)
* Regarding standardization, the foundation has members on TC39, W3C TAG, etc. Helping with standards is time consuming (and something I personally don't want to spend any time on), but it does help to gather ideas and have a way to contribute in a smaller way to the process
* As a foundation, we don't require any project to merge or conform with another. We have 3 testing tools (Intern, Mocha, and QUnit) which all have different philosophical approaches. But there are certainly things we could collaborate on, inside or outside the foundation.
* The foundation is not a place for projects to go to die. For example, many think of Dojo 1.x as old (because it's been under active use and development since 2004), but if you look at the work being done on Dojo 2 ( http://github.com/dojo/meta ), you'll see that it's on its way to reinventing itself as a modern TypeScript based approach to building web apps.
* Over the years we've worked with many large companies, and it's important to remember that companies are made of individuals. These companies have behaved on the OSS front in a very helpful manner (and I'm a huge skeptic in general). IBM has contributed as much over the years to JS OSS as anyone out there. The amount of help they provided in a11y and i18n is second to none, and they've helped Dojo, jQuery, PhoneGap/Cordova and others in significant ways.
* The list of founding members is smaller than we would have liked, but many times, you need to put something out there before people will join (it's more difficult to convince someone to sponsor something not yet announced than something fully baked). And just because you haven't heard of a company doesn't mean they don't do interesting and important things. The goal was not to just get a bunch of large companies to push their logos, but to get a group of people that care about the open web involved.
Overall it seems like the community loves to hate on things out of FUD (nothing new), but really we're just a group of people that create OSS that solves problems we have as developers. Really we just want to help, and a foundation is just one way to encourage collaboration.
I don't have a ton of experience with the Linux Foundation, but publishing a list of "official" JavaScript libraries to seems like a step in the right direction. One of the largest complaints about the JS ecosystem today is the huge number of choices in libraries available. Maybe this provides a good starting point for a lot of people who feel lost. Or maybe it's just one more library that we all have to understand and make a decision about.
Very true. Hopefully this provides a good starting point to get the the discussion going, especially for things where there are multiple options. momentjs is a good example - I don't think there's a better library for dealing with time in JavaScript. But Mocha might be contentious - some people love the Jasmine/Mocha/Jest family, other people prefer the Tap/Tape/Ava lineage. Here's to hoping this makes the discussions easier to have.
Then I saw the "initial projects" list.
"Appium, contributed by Sauce Labs, is an open source Node.js server..."
"Interledger.js, contributed by Ripple, enables instant payments and micropayments in any currency..."
"JerryScript, contributed by Samsung, is a lightweight, fully-featured JavaScript engine for Internet of Things..."
"Node-RED, contributed by IBM, is a flow-based programming environment built on Node.js..."
This made it very clear that the founding members of the "JS Foundation" are not interested in developing and promoting the best open source tools, those tools which are most deserving of broad adaption. To them, this is a way to promote their own tools. They aren't doing this for the good of the of JS ecosystem, they are doing it to push their own brands on developers.