If someone understood it better than me please add your thoughts.
I also don't see faces here: https://js.foundation/members/ Who runs the show?
If someone understood it better than me please add your thoughts.
I also don't see faces here: https://js.foundation/members/ Who runs the show?
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.
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.
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.
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.
It's a daunting process that I keep pushing back as there is no immediate need.
<script>
// get started!
</script>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.
IMHO the sweet spot for picking up new JS tech is about a year or two after it first starts appearing on Hacker News.
Actually no, the technology churn is much higher in JavaScript-land than most anywhere else.
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.
"It's not there" i.e its a stinking pile of shit.
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.
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.
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...
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!
For the building to rise higher the foundations need some solidifying.
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.
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.
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.
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?
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 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.
https://js.foundation/governance/ seems to have placeholders
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.