21 ms·

Ask HN: Why is everything in JavaScript changing so fast?

• mgalka 10y ago
  I've wondered the same thing. My guess is that it's because node is still pretty new, whereas most other popular languages have been around for a while and the "right" way to do things has already reached some consensus.
  • blohs 10y ago
    I wonder id its worth to learn all those cutting edge libraries now, because whatever code I write today maybe outdated next month and I'll have to learn yet another framework/library/syntax etc.
    • toast0 10y ago
      This is general advice, but use as few libraries as possible. If you learn the base language, the knowledge is portable to most frameworks, but learning a framework may not be. If you want your code to work in the future, you are ultimately responsible for your code and all of its dependencies. The less code, the better. (Although some libraries have earned a track record of dependability, projects and companies may be abandoned and you may need to pick up the slack)
• ronilan 10y ago
  It may not be the common view, but I think that what you are witnessing is, to a certain extent, "deliberate". Every framework has a "sponsor". Every strong "sponsor" either has a vested interest in the web, or, a vested interest in some other platform with which the web competes. The importance and power of the web are obvious. So, it is a dance. "Embrace, extend and extinguish". And, hop, here we go again.
  • inimino 10y ago
    What do you mean by "deliberate"? It sounds like you are hinting at some kind of bad faith or at least perverse incentives but I can't tell what exactly.
    • ronilan 10y ago
      There is no "bad faith". There are "diverging faiths". JavaScript frameworks as an analogy for life :)
      • inimino 10y ago
        It seems we agree. Each framework is deliberate, while the number of frameworks being higher than everyone agrees it should be is a side effect.
• anilgulecha 10y ago
  I think it's because of certain new paradigms that are opening up so many opportunities. With HTML5, CSS3 and ES6 being released, and seeing wide adoption, the web-application layer and APIs suddenly have access to a magnitude more functionality, and we're essentially in the early romantic period where we're pushing these new features to the max, and figuring out what sticks. Over the next year, we'll settle at the maxima of efficiency and usefulness with the web framework. Despite some negative voices, IMO these are very exciting times for the web :)
• nodesocket 10y ago
  One could make the argument that the JavaScript / Node.js community are uber early adopters and push technology more often and further, but I'm not certain that is what is really going on. However, moving fast does percolate down from the top. Look at Node.js and how often they release new versions.
• intrasight 10y ago
  I'd say the opposite - it's changing way to slow - at least in browsers, where IMHO is the only rational place to use JavaScript. The big change will be the arrival of webassembly.
  • alasdair_ 10y ago
    Mind sharing why you consider node.js and other server-side javascript tools irrational?
    • radicalbyte 10y ago
      For APIs the lack of typing hurts; only that is now no argument because it is fixed by TypeScript / Babel. Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints. Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).
      • Sanddancer 10y ago
        I would not call TypeScript/Babel making it a non-argument, because those two are separate languages that are compiled to Javascript. The language itself still has those limitations, you're just hiding it under the rug. Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge? With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation. Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
• dancek 10y ago
  I think it's because of historic baggage and politics. JS used to be a horrible ecosystem where different browsers behaved differently, the language itself had various pitfalls and most code was written in classical script kiddie style. This has been changing for the better for a long time in small steps, but frankly something has always sucked, warranting the next evolution. The second point is politics: JS is huge these days, and there's still a lot of room for improvement. Everyone wants to be the company behind the de facto standard library for web apps.
• twblalock 10y ago
  Coming from a Java background, it seems to me that a lot of what is going on in the JS world is similar to what enterprise software went through over the past 20 years: the "framework" craze. This is appropriate because websites and web apps are more complicated than ever before, and face the same challenges that traditional enterprise software faces: large codebases that stay around for a long time and need to be maintained and refactored, integration with various APIs, asynchronous communication, separation of concerns, separation of model and view, business logic, test coverage, development of different parts of the application by different parts of the engineering team, etc. At some point, the benefits a framework provides outweigh the time it takes to adopt and learn the framework. A framework provides an overall way of doing things that gives structure to the project and makes a lot of the challenges I mentioned easier to deal with. Frameworks significantly reduce the number of "how do I implement this feature?" questions that are bound to arise, by providing a standardized way of doing things. They make it easier for teams to collaborate, because the codebase is relatively consistent and engineers aren't constantly dealing with other team members' idiosyncratic code. (Yes, that means there is less room for individual creativity and expression, and it makes programmers interchangeable to some extent. Welcome to the world of business.) So, why are there so many more JavaScript frameworks than Java frameworks? I suspect it has to do with the low barrier to entry of programming in JavaScript as compared to Java. I also think that dissatisfaction with whatever frameworks are current is a major driver behind the creation of new frameworks. (I suspect that a lot of the dissatisfaction with the current frameworks is misdirected and is really due to the nature of JavaScript as a language, and TypeScript is an example of an explicit reaction to that). Another reason for the proliferation of frameworks is that the playing field keeps changing. Most recently, it has been smartphones and social media that have revolutionized the way people use the web. Before that, it was streaming video and "Web 2.0." Whatever the next big thing is, I'm sure it will inspire a new flurry of new web development frameworks.
• viraptor 10y ago
  My interpretation of this is that js was a pretty cool idea, but it was used as a hack on top of websites initially. (Think Netscape times) It was held back for a long time by lack of improvements, no real coding environment, no real modules apart from copy pasting. It was held in place by a huge rubber band while people actually tried to pull it their way. Relatively recently the standardisation, improvement of the language itself, real origin policy, common frameworks and finally npm released whatever was holding it back. It shot out from the rubber band and it's trying to catch up in months where other languages had years to find the way. You may notice that even though a lot is changing, not much is really new. Async existed before, so did dynamic languages, so did MVC, so did immediate mode UI, so did many other things. Js is now going through all of those ideas quickly because the path is known and clear. It will slow down though. There's only so many paradigms that we know. At some point people will run out of easy ideas and will have to start slow experimentation just like all the others.
• lacker 10y ago
  The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced: https://octoverse.github.com/ https://octoverse.github.com/ Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined. Most of the top repositories on GitHub are JavaScript too: https://github.com/search?q=stars:%3E1&s=stars&type=Repositories https://github.com/search?q=stars:%3E1&s=stars&type=Reposito... Demand for JS developers is growing too, as websites become more complex, Node.js becomes more popular on the backend, and frameworks like React Native (more popular than any other iOS or Android library on github) start to pick up mobile developers. JavaScript performance is also starting to be significantly better than the other scripting languages, e.g. https://www.quora.com/Is-JavaScript-v8-faster-than-Python https://www.quora.com/Is-JavaScript-v8-faster-than-Python . Not because of anything inherent about JavaScript, more that it's worth a lot of investment from big companies in JS performance. Basically, it's not just the number of frameworks. Everything about JavaScript is taking off right now, and leading to a network effect where all the other aspects get boosted too. Sort of funny to have this happen twenty years after its invention.
  • deleted 10y ago
    [deleted]
  • jacquesm 10y ago
    To a large extent this is true because the javascript community is busy with the re-invention of all of computer history, only without applying all of the lessons learned. Activity does not equate quality.
    • infinity0 10y ago
      Not only are they doing that, but they are insanely arrogant about rejecting criticism that they're doing this too.
      • cjfont 10y ago
        You don't drop an incendiary statement like that without at least citing an example of where that has been the case.
• RFVenter 10y ago
  It's all hype and fads. People re-inventing the wheel to make money.
• m_mueller 10y ago
  To piggyback here: How long until we can just use whatever language we like, including Std.-Libs, package ecosystem, sandboxed FS (and thus DB support) and JIT it to JS in all commonly used Browsers?
  • cheiVia0 10y ago
    See WebAssembly
    • hood_syntax 10y ago
      Can't wait, I may actually switch to front end development when there are WA backend(s) for a language/languages I like.
  • aianus 10y ago
    Scala.js is an attempt at this
• dfabulich 10y ago
  JavaScript is a programming language that was frozen in amber for a decade, and is only now starting to thaw. Brendan Eich initially designed JavaScript in an infamously short time--he coded and designed the first prototype of JS in just 10 days. It quickly became the only programming language you can use in a web browser, with multiple vendors, including Microsoft, owning mostly compatible implementations. Due to trademark disputes they couldn't even call the language standard "JavaScript," so the language standard is called "ECMAScript." Microsoft didn't want/need JavaScript to change or grow at all. Once Internet Explorer 6 became the dominant browser on Windows, (which was and still is the dominant PC operating system,) they stopped releasing new major versions of IE for five years (2001-2006), and IE7 wasn't a very big upgrade, especially in terms of JS language features. Mozilla unilaterally released new language features that only worked on Firefox, so nobody could use those language features in practice on the web; in many cases, new language features wouldn't even parse in IE. In 2007, there was an attempt to build a major new JavaScript version (ECMAScript 4) with a ton of new features, (classes, a module system, optional static typing, algebraic data types) but it was scrapped due to disagreements between Mozilla and Microsoft. They wound up implementing a much more modest upgrade (ECMAScript 5) which shipped in IE9. In all this time, there was essentially no interest in running JavaScript in command-line tools or on the server side. That changed in a big way in 2009 with Node.js. It used V8, Google's JIT engine for JS, and it was surprisingly fast. This is when the language really started to unthaw. IE declined in dominance as Chrome rose, and the demands of server-side development started to be felt more strongly in the JS community. ECMAScript 6 started to add back in a number of cool features, and by this time, JS developers were desperate to use them. This lead to the development of "6to5," (now called "Babel") which allowed you to write code in ES6 and "transpile" it into older JavaScript versions, so developers could experiment with new language ideas without pushing them through the standardization process. Languange evolution kicked into high gear at that point. There are a bunch of interesting pluggable transpilers out there, including TypeScript, JSX, and Flow, and countless non-standard plugins for Babel. And that's just the language itself! The "standard library" for JavaScript for years was just "whatever IE6 could do" and that wasn't very much. IE6 was pretty buggy as well. jQuery became popular as a library to smoothe over differences between browsers, but mostly to work around bugs in IE. Client-side frameworks were tough to implement on IE6, not least because IE6 was just so darn slow. As newer, faster browsers came out, it became possible to trade off some performance to improve developer productivity. And everybody has their own ideas about what those trade-offs might be like! At the same time as IE6 started to decline in popularity, the mobile web on iPhone and Android rose in importance. Smartphones include a bunch of new sensors (GPS, orientation, camera) and new limitations (RAM, slow/unreliable network). This spurred on browser vendors to "compete with native apps," adding features to the browser platform, inviting developers to respond to these with new frameworks. As for the JS server-side, Node.js is still a relatively young platform as these things go, and so it's not surprising to see a lot of churn in server-side libraries/frameworks, especially given how much churn the language itself is undergoing. Node.js is also the first major platform to be born in github, which IMO encourages experimentation (and flame wars) via forking. Node.js's standard library is designed to be small, (they call it the "core" and resist Python's "batteries included" philosophy,) forcing folks to rely on libraries and frameworks to keep the lights on. Even most libraries themselves need to take dependencies on other libraries, because of this "small core" philosophy. I think it's going to be at least a few more years before things start to cool off a bit. Enjoy the ride, if you can!
• nickstefan12 10y ago
  In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why is this more prevalent in JavaScript? Front end inherently has more new comers. Long time hackers or cs grads feel less of a need to prove themselves making free software? I think it's natural that the web programmers would understand web self promotion better than other languages. Guess who's better at Twitter? The js people! Why? They were writing the web to begin with! I wish it would stop. Our qa engineer is writing web driver tests in JavaScript and I don't understand why! There's nothing about testing that NEEDS to be async! The python API would likely be no slower and much easier to write and debug. Sane defaults are an important part of tech, and default async is a terrible setting. Python sync is easier, and Go routine concurrency is easier. Always on async just seems like a terrible default. For speed I'd do Go, and for all else Python.
  • Shanea93 10y ago
    Just a minor off topic correction, since you made the mistake twice: "squeue" is actually "skew".
    • nickstefan12 10y ago
      Thanks! I forgot to require the spellcheck module ;).
  • deleted 10y ago
    [deleted]
  • jacquesm 10y ago
    > The python API would likely be no slower and much easier to write and debug. But probably not for your qa engineer who most likely already (and possibly only) knows javascript.
    • 10y ago
• combatentropy 10y ago
  Is it because it lacks a shepherd? Perl has Larry Wall. Python has Guido van Rossum. PHP had Rasmus Lerdorf and later Andi Gutmans and Zeev Suraski (Zend). Ruby has Yukihiro Matsumoto, and Rails has David Heinemeier Hansson. JavaScript came from Brendan Eich, but it was like a work for hire, wasn't it? Microsoft and Netscape just kind of ran with it. Then I guess it did have a shepherd, the W3, and all the browsers followed its standard, except the one that had 90% of the market. At long last, in the past few years, market share has passed to companies that are much more willing to follow open standards. But at the same time, the user base is huge, a churning mass of millions of programmers of every level of ability, and each one of them can now publish their framework on Github. Plus there are several large web companies that are competing with each other. Thankfully at least the language itself has a single standards track. Cross-browser agreement isn't perfect, but it's much better than it used to be. It's just that we don't have a standard library, like Perl's CPAN. Instead we have NPM. I wasn't paying enough attention when Perl and these other languages developed, so I don't know for sure why they're different, or even if they were that different at this stage. Even they have their different web frameworks to this day.
  • civilian 10y ago
    Maybe replace "shepherd" with "standard lib". Python has a pretty complete standard lib. Javascript is lacking it, and that vacuum encourages things like jquery. But then there are people who see jquery getting bloated, and they really just want a few features, so they write underscore and lodash. We've got no standard lib, so we have a continual ebb & flow of unstandard libs.
    • Tomrn 10y ago
      hundred percent agree with this. A standard lib bundled with all browsers would solve so much of the framework madness.
      • bpicolo 10y ago
        Especially since Javascript needs it MOST, since we have to transmit it on the wire...
• dpweb 10y ago
  The perceived benefit of creating a new framework is large (I'll solve programming the internet!) and the cost is quite small (easy to write js with little knowledge), there's a huge number of devs, and no one really owns the space. Compare it to say, creating a new operating system. Sure the world could benefit from a better OS, so why not make one? The perceived benefit is small (why do this when Linux exists) and the cost is large (it's hard and you need a lot of knowledge). Also a lot of half baked ideas. The number of js writers is huge but on average very inexperienced compared to other languages.
• hoodoof 10y ago
  Cause JavaScript is used in browsers so it is the language of the web, and because it has turned out to be incredibly flexible and adaptable, and because it's pretty simple once yo get past the async thing, and because alot of effort has gone into making it fast.
  • justinlardinois 10y ago
    I think out of all the comments so far this passes closest to the real reason. It's simple: if you're developing for the web, you almost certainly have to use Javascript. That reality corrals so many more people into Javascript than any other language.
    • inimino 10y ago
      That is certainly part of the reason, but other platforms enforce language choices and don't have the same level of churn. Two popular mobile platforms come to mind.
      • justinlardinois 10y ago
        You don't have to use Java on Android and you don't have to use Objective C or Swift on iOS. You're heavily corralled towards them, but there are still other options.
• wiseleo 10y ago
  JavaScript is being redefined. The language is flexible enough because of prototypal inheritance that every method can be redefined at runtime. ES6 added many missing features. That's unusual. These frameworks extend the language. Angular's developers reasoned that anyone smart enough to figure out Angular 1 will be able to migrate their code to Angular 2. It's looking more like C++ and less like CSS. :) Take a look at Meteor's code sometime. It does things I never expected possible with JavaScript.
• fibo 10y ago
  Cause we are living in a transition period. Remember the CVS war, cvs vs subversion, then hg vs git. Now git seems to be the winner and there is no big change since few years. In these days there are a lot of progress going on, let's wait things get stable but it Will take a very long time considering: es6, es7, vr, webgl2, serviceworker, webaudio, http2, webassembly and a lot of other stuff in some way related to js.
• inimino 10y ago
  First, Web technologies (not just JS but HTML, CSS, DOM, etc) are implemented by multiple browsers, who compete and have other agendas, as well as backend and non-Web platforms. This underlying technologies are just messy in a way that only a world-wide, massively distributed, twenty-year-old platform can be. There's nothing quite like this anywhere else in tech, as most platforms are dominated by a single vendor. Imagine what Windows development would be like if, in addition to the need for backwards compatibility, there were three or four competing vendors of Windows, each with different feature sets and bugs. Second, tools and libraries can overcome many of these problems, but these fixes come with costs, including library maintenance, cognitive overhead, security risks, complex build and deployment processes, and retraining and hiring issues. Because JavaScript is used across many industries and teams of all sizes, what is perfect for one may be completely inappropriate for another. Many projects, like GWT, meet the needs of the environments in which they were designed, while being so much a product of those environments that they become anti-productive elsewhere. So we have a very diverse set of tools on top of a very messy and relatively old set of underlying technologies. Finally, many new programmers come into this incredibly diverse, sometimes frustrating, environment every year. It is an environment that encourages open-source contribution. It's no surprise that many new tools and libraries are released every year, and some of them gain adoption.
• SFJulie 10y ago
  It is because JS does not change much that there are all this libraries around that changes a lot to try to give an underfed horse more power. In comparison, java, PHP have undergone some more than welcome mutations in terms of syntax clarity. Evolution in JS is made by adding features in frameworks, not in the core definition of the language. You could see JS as the assembly language of the browser and all the frameworks as some C/fortran/C# that translates into JS. The problem is the web would look definitively balkanized/ghettoed between old and new computers if you made a non backward compatible change of JS ... JS is the most ducked taped language of the landscape of computers. And it is leaking memory, performance, abstraction from everywhere.
• aikah 10y ago
  > For example angular 2 is not compatible with angular 1 That's not the problem, angular 1 and angular 2 are 2 completely different frameworks that share the name and the team only. The team wanted to piggyback on the fame of the first version, but they share absolutely nothing conceptually. and contrary to what the Angular team says there is no "upgrade path", you need to learn the stuff from scratch once again. The problem is, and the Angular team will find out very soon, "second systems" unless they provide huge advantages over the first version, are always a failure.
  • prophesi 10y ago
    It was quite the rough path when I converted an app from v1 to v2. First I had to get the app to work with Typescript (not necessary, but it seemed there'd be better docs/tutorials in Typescript with v2). Then gradually rewrite each piece of code using ng-upgrade as I relearned everything. But I still must say that v2 definitely provides the advantages to warrant the hassle.
• dandare 10y ago
  The answer is bit paradoxical: It is because JavaScript itself can change only very slowly. What you see changing is everything around JS but JS itself, while powering the whole web, is still to an extent the same scripting language that Brendan Eich prototyped in 10 days back in 1995. Why is that? Simply because the JS runtime environment - the browser - is not controlled by a single entity that could plan and enforce radical change. Instead all the big players have to progress together, which is usually not in the interest of all of them at the same time (It used to be Microsof who was not interested in progressing the web standards, now it seems to be Apple. Not because they are bad people but because it makes sense in their situation.) Plus you have to maintain backward compatibility with older browsers, one can still not simply use ES6 in production website because it would not work in significant portion of the (older) browsers. That is why everything around JS changes so fast in an attempt to find the best workaround, polyfil, transpiler, module etc.
  • roblabla 10y ago
    The language itself evolved as well though. Chrome/FF/Edge (the Big Three) all support a large subset of ES6. I use it in prod because I have the luxury to not have to care about those people stuck in the past. And the portion of older browser isn't that big anyway, thx to autoupdates. Only people using IE and safari are problems nowadays.
    • lexicality 10y ago
      Or if they use Debian. Evergreen isn't evergreen if it's on Linux.
      • roblabla 10y ago
        Meh. Desktop users should all use a rolling release distro anyway. I'll never understand the point of versioned distros for desktop...
        • lexicality 10y ago
          People like stability.
• prewett 10y ago
  I think all the churn is a sign of several problems. First, the language was not designed to do what people are trying to use it for. Second, I question whether the framework makers are familiar with "native" UI APIs (e.g. Java, Qt, NextStep), which solved a lot of these problems years ago. Notice the lack of churn in native UI APIs (exception of Microsoft). Third, it seems like the frameworks try to build on top of HTML, which I think is a mistake, because HTML was not designed for layout flexibility and pixel-perfectness (unlike native widget APIs). Furthermore, HTML was poorly designed for anything but simple word-processor documents: why is there no <block> element that is inline-block?! That's the first thing I end up assigning to everything. But the whole declare-your-document approach is inherently too simplistic for much beyond a word-processor document. Note that PostScript, and PDF which is an enhancement, has been pretty stable and standard for years, which indicates it is a good solution to the problem. Ultimately, you need to be able to program your documents and put pixels exactly where you want them. But even just sending over a blank HTML page and then having JavaScript add everything programmatically is probably better-suited, despite having to ultimately get squeezed into the HTML approach. In my opinion, we need to realize that webapps are not documents, and document-oriented HTML is the wrong tool. I don't think things will get better until we start looking at webapps as essentially drawing on the screen, like native UI APIs. I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer, as long as it can compile onto the instruction set. Static-type people can use a statically-typed language, and dynamic types can use dynamically-typed languages. Make an instruction set that maps well onto native CPU instructions, and provide well-thought out input and drawing primitives. We essentially need a PostScript for apps.
  • IndianAstronaut 10y ago
    > I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer To be fair, a lot of languages compile to Javascript. Do we really need a second standard?
    • icebraining 10y ago
• Illniyar 10y ago
  I have a pet theory about that. I think it based on two factors: 1. the size of the community, JavaScript popularity is huge, it's probably the biggest programming community in the world, even the not so popular frameworks have a bigger community then the biggest frameworks in other popular languages (as a not at all accurate measurement, see vue.js and Python's django github stars/followers). If you look at js frameworks/methodologies/libraries compared to the sum of the other languages' frameworks then the pace of change in Javascript compared to how many people use it is not as bad. I had a similar experience with Java when it was the king of the web frameworks - JSP, JSX, JSF, Spring MVC, Struts, Stripe, Wicket and a dozen others. Java was big enough to contain all of these frameworks, and it was big enough for people to support new ideas rather then iterate on existing ones. I'm not familiar with C/C++ enough, but I think it has a similar amount of change to Java (which is somewhat less the JS) 2. the other big factor is how decentralized it is - JS is extremely decentralized, there are tons of big organizations contributing to it's advancement, to frameworks even building their own compilers (all the browsers). Java is very similar in this regard, even in their governing model (a collection of companies that decide on standards together, though Java has drifted from that model with Oracle's lead lately). C# is the opposite, it's one of the biggest languages but doesn't have a lot of change in it - everything is dictated by the central authority (Microsoft) and competing frameworks that don't get popular enough. There are other factors of course, but I think most of those can be seen in other languages with less change, and are less relevant overall.
• kewp 10y ago
  It's the Internet - remember that remarkable decentralized network for informational retrieval developed by ARPA in the 70s ? It's going to change the world ! It's always on. Anyone from anywhere can interact with what you create instantly. What else is like that ?
• k__ 10y ago
  Because, finally all big players are in the game and Javaize the stuff.
• fiedzia 10y ago
  Imagine that you have a furniture factory. There is one room where one guy who works for you produces tables. In next room there is another who produces sofas. And then another one who makes chairs. The demand is great, so routinely you hire more people to produce more things. As you walk, you realise that each of them uses selection of screws and chisels and screws and wheels, and types of wood and door handles and all of them are somehow different. Not because they have to be, but because they were acquired independently by each worker. You come with an idea that if you standardise on some set of commonly used wheels and handles and chisels. This means you will need less of them, it will be easier for each worker to acquire, reuse and combine them, less time spend relearning different tools and a lot more other benefits. Once you did that, you may realise that the things built on top of that - like drawers, doors, covers - can benefit from the same standardisation. And so you do and keep improving your factory. Notice however that such idea would never come from single worker. So JS is stuck at being early-stage factory. Main thing that it lacks is a boss that looks at it and improves it. Any proposed change has to gather momentum, convince some committee and even than it takes years to push it. It takes so much effort that most of the time anyone who tries just gives up. Where in other languages its enough to send complain email and propose a solution to one mailing list to get someone involved and get proposed change deployed in the next release a month later, you can't do it with js. For the same reason there is nobody to make a sweeping change and wipe this disaster from earth. Too much politics involved. So everyone hack his way around it, and hacks are not very maintainable, so you'll need to redo them on next project, but very differently. Making any two projects incompatible and hard to build one on top of another. Java had its Sun, Python had BDFL Guido, JS has no such thing.
  • robinson_k 10y ago
    > Java had its Sun, Python had BDFL Guido, JS has no such thing. For JavaScript the TC39 is responsible for its improvement and standardisation. Thats were ES6 was developed. ES2016 aka ES6 took a fair amount of time, but the TC39 switched to "rolling releases". ES2017 aka ES 7 is already in the works and is going to be released 2017. https://github.com/tc39 https://github.com/tc39
    • 10y ago
• whostolemyhat 10y ago
  I think it's due to the new version of Javascript being released recently after years of stagnation. ES4 was abandoned and ES5 was mainly standardising existing practices, while ES6 has added a lot more - new syntax, new types, iterators, generators, modules and so on. A lot of the churn going on is due to people trying to work out the best way to use these new features, along with whether or not to keep backwards-compatibility with existing frameworks and libraries.
• grigio 10y ago
  Because nowdays js has so many use cases
• jerf 10y ago
  Javascript and the browser environment it is still pretty much glued to (Node notwithstanding) has several major architectural flaws and some unique challenges that are particularly acute for Javascript, and a lot of energy has been expended trying to figure out how to use the not-very-strong tools in a way that can support high-quality applications without too much developer effort. Also, some of these things are getting addressed over time, so I'm kinda going to talk about the state of JS over the past decade rather than the state it is in right now. Some of these things are being mitigated (very few things are really being "fixed"), but it's still early. These issues have historically included, but are not limited to: 1. Poor modularity brought on by being not just a "scripting language" like, say, Python, but a language actually designed to write small event handlers that fit into a single HTML tag attribute. "x = 56" defaults to putting x in the global namespace. The language did not provide modules or very much in the way of separation by default. You've pretty much always been able to namespace things, but you had to really work at it; the language did not help. (I'll also toss in the dynamic typing here, just because I don't want to give it a full slot here, but it does inhibit making big projects easily.) 2. Very poor control-flow management ability due to the choppiness of event-based programming. There has historically not been a way to maintain a call stack across events, which strips away all the tools of structured programming, a set of tools so fundamental to how we operate that we often don't see them as a fish doesn't see water. Promises and generators allow us to try to mitigate this, but at the cost of spending design budget; promises for instance introduce a second entirely new set of control flow mechanisms that mirror the base language's looping and flow control constructs, particularly annoying because you must control both error and normal flow on both of these levels. 3. The browser's interface to JS is the "Document Object Model", which due to historical reasons is a Java-designed API bolted on to the side of JS. A native JS model could have been much more powerful and easier-to-use, requiring us to burn less design budget on simply interfacing to the browser in a reasonable manner. A lot of the design churn is attempts to answer the question "How can we make manipulating the DOM more JS-native?" There are also several performance issues introduced by the fact that the DOM model, combined with the rendering model, is extremely rich; things like manipulating a node on a page vs. detaching the node, manipulating it, and reattaching it have historically had end-user-significant differences in performance, as every DOM change triggers an incredibly complicated set of updates to a widget toolkit that was designed for flexibility rather than performance. 4. Browers themselves further introduce many complications. Then you have all the security issues that arise from being fundamentally client-server with dubiously-trustable servers. You have all the details like what cookies flow between what domains and where and when, that you need a different domain for your static content both for security and performance reasons (prior to HTTP2 particularly), and any number of crazy APIs that also vary across browsers, requiring the developer to use shims for things as simple as XMLHTTPRequests because you just never quite know what you actually have. 5. I could have list "client-server" in #4 there, but it's also worthy of its own callout. Many frameworks have different solutions for client-server interactions, ranging from ignoring the problem and letting you solve it up through Meteor-like attempts to completely blur the lines between the two, and everything in-between. Client-server interaction has been further inhibited by the fact that historically, there have not been any reliable and high-performing mechanisms for streaming things between the client and server, creating a design limit around needing to be request-based, further creating a wide variety of ways of hacking around this problem, each with their own quirks. 6. As an open standard, nobody is really empowered to fix these problems in a coordinated way. As a result we're sitting on top of 20ish years of standards, some well-done, some poorly-thought out, some hackily fixed after security issues, many poorly-understood by developers, and all in the browser. 7. Finally, one must not ignore the fact that web pages continue to become intrinsically more and more diverse. The best framework for a document-centric app is one thing, the best framework for a CRUD app another, and neither of those will help you much with an intrinsically real-time streaming app like a chat client. And there's probably a couple more dimensions I could come up with if I thought more. What you see is that there's a lot of possibilities for mitigating all these issues ("solving" is often not on the table, these are mostly fundamental issues arising from layers below the JS), and the framework churn is in many ways nothing more than people combining all of the various combinations of possible answers to these problems, looking for synergies, solving different problems (per #7), and basically frantically rifling through 60+ years of computer science theory looking for the perfect solution to problems in an environment with so many fundamental strutural issues that no perfect solution is possible. Which is also why you see such vigorous advocacy sometimes; someone thinks this is it, this solves all my problems once and for all because it worked for a couple of weeks, and only once the community has chewed on it for a while does it become clear that there's a lot of people with different needs for whom that doesn't work so much, and it also didn't actually solve all the problems once and for all after all. BTW, none of this is criticism of the JS community, merely explanation. Given the hand we've been dealt in the web browser, lots of people trying lots of things is the best we can hope for. The fatigue is just an unfortunate, but unavoidable, side effect. The best solution for the fatigue is to concentrate more on the fundamentals being explored than the details of a particular framework. For instance, "reactive" programming is its own paradigm, with its own lore and learning; learning how to program that will also let you write better spreadsheets and be better at creating database triggers, for instance. Concentrate on the fundamentals. The fundamentals are not churning that fast.
• douche 10y ago
  It's because JS is, at it's core, a shit language. All of this flailing around and creating a new framework every week is like the poor sods trying to struggle through the mud at Passchendaele. The more you fight it, the deeper it gets. Better languages have sensible defaults, and a decent standard library built in. If we could run Python or Java natively in the browser, nobody would bother with all of this illogical complexity that has arisen to try to make writing Javascript moderately tolerable.
• d0ugie 10y ago
  Why didn't the Dart VM make it into Chrome?
• bloomca 10y ago
  The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die soon (or will get enough money to completely rewrite it), so 'maintanence' in idiomatic way doesn't work here – life cycle is extremely small, and it reflects in the way libraries are written in JavaScript. Also, the barrier is low, and therefore we have a lot of complex websites built by novices, running in development mode in the actual production. Community also is very "poisoned" with the idea that you _have_ to work in your evenings (contributing to OSS, writing your own or just playing with hot technologies), and therefore new stuff is baked extremely quickly. It is usually very low quality, and you have to cope a lot in order to make it work, and often you have to dive into source code, and it is considered as normal, which is quite sick from my point of view. Also, it is truly "hype" community, which is super excited about what is hot now – and it means that today kings will be overthrown very soon (right now stuff like Cycle.js and Vue.js is gaining traction). Nobody wants to maintain their libraries – and very often you can see projects with a lot of stars completely abandoned. Recently, Babel.js was defined as _defacto_ standard, and it basically started transpiling era, which is not going to end in the foreseeable future. It shakes the stability, and makes extremely easy to add new features (like stage-0), and people just used to unrealiable tools. So, all of this works as a snowball, which only speeds up. People create more and more complex web applications, and also js is going into other fields (like microcontrollers, Node.js grows in popularity, React Native is super hot now). When it will stop? Nobody knows. Maybe WebAssembly after implementing will stop it (people will spread over competing technologies), maybe no.
  • cygned 10y ago
    As someone who's working in that environment every day I cannot agree more.
  • ourmandave 10y ago
    Soon we'll have trouble hiring Angular 1 devs to maintain legacy code, like COBOL. Except COBOL started in 1959, not 2009.
• btbuildem 10y ago
  Because the ecosystem is mostly built by people with no formal education and little experience -- they're literally re-inventing everything from the history of computer science.
  • inimino 10y ago
    Many people will learn JavaScript this year as their first language. Those are not the people writing the successful libraries like React. Lots of people with little experience contribute, which is great, but "the ecosystem" is largely built by people with plenty of experience and training.
  • wiredearp 10y ago
    Or perhaps because the ecosystem is built by people with much formal education and industry experience applying traditional computer science paradigms to a stack with bizarre and unconventional tooling, not realizing it was made by other experienced backend developers attempting to fix the same imagined problem in a domain they don't understand. The outcome would be the same, so it's hard to say for sure.
• gravypod 10y ago
  I think many people are missing what's happening here. This isn't the first time we have seen lots of churn. Every time some group discovers something "new" they latch on to it and try to shape it in their image of what is the best. This is natural and important. Even looking back about 20 years, how many companies where making CPUs? How many different architectures where there? How many companies where making PC clones? Remember RISC is going to change everything - Hackers We get fanatical about random things every few years because the technology is generally good, then we all thing "that's stupid I like it better like this" and after a few years of unmaintainable messes we settle on the middle ground that most people are ok with (x86). This is natural the world isn't ending
  • kxtells 10y ago
    Small Comment. The ARM architecture is RISC. And mostly every phone/tablet/wearable(even stuff like your TV) has one of those.
    • gravypod 10y ago
      It's not a "true" RISC architecture anymore. There are "complex" instructions that would be frowned upon by the original RISC community.
• rhizome31 10y ago
  Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development. I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other communities started to follow and improve. When it came out, most developers who were already working with the web could see that it would be very useful, it solved real-world problems they had, it just made sense. This is much less clear with JavaScript frameworks. They usually have a tough learning curve and the benefits are not always coming as expected. So people keep trying to find a model that works well.
  • tomjen3 10y ago
    I would say react is the way to write large data driven applications, but JavaScript, without a tool like Google closure, is not suitable for 100k lines of source code app that is being actively developed. Personally I am playing around with typescript and webstorm and that seems to me to be good enough.
    • inimino 10y ago
      The trouble is that it's very difficult for a single tool to meet the use cases of everyone who uses JS.
  • pmarreck 10y ago
    > We're still waiting for the Ruby on Rails of frontend development. Well, there are the people who have moved on to React and are raving about it, and then there are the really hip people who have moved on to Elm from React and are raving about that: http://elm-lang.org/ http://elm-lang.org/
  • Roboprog 10y ago
    I remember the, well, "rage" I had at Sun when I stumbled across RoR. I had completed my Java web certification the year before. The Java stuff seemed clumsy and repetitive. One year later, saw Rails. "Why couldn't you geniuses have done something like that, instead of this mess you gave us?!?"
• daxfohl 10y ago
  Because you can write a new JS/HTML framework in a few days. Compare this to e.g. Qt or GTK or WinForms or WPF. Each of those would require man years of effort to reproduce from scratch. Also these JS frameworks tend to be opinionated with how databinding works etc, such that there's always something that you have to work around when you're using the framework in real-world projects. People get annoyed enough that hey it's easier just to create another framework.
• tolmasky 10y ago
  My theory, which I think goes fairly against what others will say here, is that JavaScript/Node is the first truly post-internet environments to reach critical mass. By post-internet I mean they consider sharing and open source as foundational to the environment (as opposed to tacked on later, or merely supported). The "JavaScript standard library" (or lack thereof) is a clear example of this: NPM is the LARGEST collection of packages of any language, and you can almost always find someone who has already written what you need most the time. It never ceases to surprise me. During the Pokemon Go craze I was curious to play with the protocol: there was already a package to do it. I wanted to ping my find my iPhone, there's already a package to do that. Its incredible. And yet the actual built in standard library is notoriously lacking. Although not by design, certainly the end result is that that has become "OK" thanks to NPM. Compare this to something like AppKit (and UIKit), which were very much in the pre-internet/sharing mentality: there is one framework everyone has and becomes experts in and is fairy stable, because its kind of the only thing you can rely on being around. Sharing code is very difficult, to the point where just copying and pasting files is still a valid contender. The explosion of options and the increase in churn is a natural consequence of this. There are simply more people working on more problems, all encouraged by an environment where sharing code is a fundamental property. If step 1 of setting up node is downloading other people's random packages then it should be no surprise that step 4 of sharing your own packages will seem natural. We should expect this to only get faster -- the more people program, the more crazy ideas will be tried, the more switching there will be. I really don't understand what the alternative is: arbitrarily choosing frameworks to be around for a 5 years (a decade?). We are simply taking the last measure of stability, which was largely governed by how long it used to take information to disseminate to the entire community, how long it used to take one controlling body to get their large waterfall releases out the door, and using that as an arbitrary comparison point to how long it takes hundred of individuals to release their individual takes on software. Asking to "stop the churn" is a strange request: there's no single entity pushing stuff out "too fast", this is the aggregate affect of all programmers in the node community publishing their ideas. Who are we asking to slow down exactly? I can understand saying the single case of Angular 1/2, but the "JavaScript fatigue" people actually feel is due to the interaction of all the JavaScript projects that each gain and lose popularity. Unless you believe we're really close to figuring this whole "software development" thing out (whatever that means), I wholeheartedly believe that programming 20 years from now will look more like this -- faster pace of developments.
• agentultra 10y ago
  Because there's a lot of investment in the language and its ecosystem. There's more money pouring into V8, *Monkey, and other JS compilers than goes into most any other that I can think of. With popularity comes rapid evolution.
• cygned 10y ago
  My (very) personal opinion: I think, the culture is a important factor here. There are very great developers in the ecosystem, who write great tools and libraries which become popular, are well maintained and documented. But the majority of the developers are just average developers. As everyone, they attend conferences and bootcamps, and when I then talk to them, the usual thing they learned there were two things: (1) make a blog and write about what you are doing and (2) make some OSS projects or participate in existing projects. It is very great to have people who create projects and bring in new ideas, it helps create a mature technology. But the truth is, most of the average developers have never been in larger projects, have never been digging into complicated/large open source libraries and have never had to manage larger applications. One of the most important things you learn in such projects is to be calm and think about documentation, architecture and dependencies carefully. And this leads to the current situation; - we have a lot of libraries doing the same things, just because developers do this "just create an oss project on GitHub/npmjs" thing without searching for existing solutions - some hip developers have so many projects that I always ask myself how they are planning to support all these - when a problem arises, e.g. a bug in a library, many developers these days seem to tend to write their on lib fixing that problem (if it is a small library) or building an internal workaround instead of contributing back to the original project - on the other hand, there are a lot of project maintainers who ignore issues and pull requests just because they have a very strong opinion about what their library is doing. Oh boy, sometimes it took me days to write a PR which (from my point of view) improved something or added a new feature, carefully followed existing guidelines (code formatting, docs, etc) just to get the answer "nah, that's not my scope. Fork the project or write your own" - it seems to be easier to convince people with less business experience. They often jump on the next hot train coming along that sounds good. I don't want to exclude me here completely; as I read about React, it started working with it directly - because it seems to solve all the problems I had with Angular and Backbone - I have the feeling that a lot of developers today (still) have this "read the f*g code" mentality. Even mature libraries developed for years have so bad documentation (even though they have their own .io domain just for it) that I have to read their source to see what parameters I can pass into a function. I think, browsers/engines/tech companies/... are also part of the problem. For years, JavaScript has been "developed" (language spec) slowly and browser have been adopting features slowly. But then, suddenly, everything exploded. And now we have very awesome features in the language that allow for things that have not been possible before. And in fact, these features deprecate some libraries or frameworks. And instead of abandoning a project by deciding that only bugs will be fixed in the future and no new features will be added, the developers either try to move to the new technology with their product; or are forked by people who were part of the project but didn't like its developers/strategy/whatever and want to use the new opportunity with the new language feature to change things; or get company by another project that does basically the same but started from scratch and uses all new language features; or all together. As a side note, I work with JavaScript every day and that is only my opinion on the topic. Please don't feel offended. [edit: typos and formatting]
• jlebrech 10y ago
  because it blows. we need a full IDE, Language, Library combo for better development.
  • Roboprog 10y ago
    There are IDEs that support JS. Use JS to do FP (functional), rather than OOP, and it totally rocks. Refactoring stuff works pretty well with nested functions - function names have to be "real" (if avoiding eval()), as opposed to properties that can be provided as associative array string indices (not that there's anything wrong with that, if that's what you need). I'm not a script kiddie, either - I have been programming since the early 80s when I was earning my CS degree. I'm not scared of dynamic scripting languages
    • jlebrech 10y ago
      we just need it to be as easy as xcode
• mambodog 10y ago
  A lot of comments here seem to suggest it's just because of people creating projects to get attention. I think this reason is massively overstated, and appeals to the unfortunate HN meme of disparaging other people's work to signal that the commenter is smarter than the herd. However, I would suggest that we are now building applications at a level of complexity which has not previously existed on the web before (unless you include non-standard tech like Flash/Flex or Java Applets, which both had their shortcomings). If you accept that some of the things which are being built actually unlock new possiblities in terms of user interface fidelity, and therefore has at least some purpose, then I would point out that the level of churn can be explained by the following: 1. JS has become very widely used very quickly, which means that there have been lots of hastily built things, which have been replaced by better things (and for every 'better thing' there are many alternatives which fell by the wayside), and a larger pool of people to build them. 2. It's easier than ever to build new tools (or any kind of app, for that matter), because the npm ecosystem makes it trivial to combine existing smaller pieces of code into new combinations.
  • HelloNurse 10y ago
    If you believe in things like the "npm ecosystem" you have already lost the war on immaturity. What's being disparaged is bending web technology to unsuitable purposes instead of adopting something better, not individual projects that, ignoring the often insufferable hype and smugness, are often technically clever, as good as a bad premise and a bad purpose allow.
    • macawfish 10y ago
      The war on immaturity? What is this, chitty chitty bang bang? You sound like the child catcher. "Bending web technology to unsuitable purposes"... This could mean anything, it only depends on what specific orthodoxy you're implying. Good vs. Bad. Immature vs. Mature. The world is actually a colorful place if you open your mind and heart just a little bit!
  • dlandis 10y ago
    I'm not sure which comments you are referring to, but there is a lot of truth to the idea that developers (especially frontend developers) are, in some cases desperately, trying to build their reputation by contributing to or starting GitHub projects. Notice I said "build their reputation" not "get attention". The fact is it is almost impossible to get a job as a non-junior frontend dev nowadays without a GitHub profile showing a long history of contributions. That leads to a lot of desperate and low-quality projects...and that's just reality not a disparagement. It goes hand in hand with the industry shift (especially for frontend tech) with considering one's GH as an essential aspect of one's resume.
• HelloNurse 10y ago
  There is a high rate of change in fads, not in reality. What is actually worth learning and following has a normal change rate. Fads are governed by a vast community of hipsters who clearly prefer to spend time and effort on earning 15 minutes of celebrity with some library or tool than on more productive tasks like improving their own web site, working for customers or learning principled computer science and software engineering. Meanwhile, web standards like HTML, CSS and ECMAScript and web browsers evolve at a reasonable pace and in a saner way: doing more things and doing the same things in a nicer way. The traditional design attitude of figuring out how web standards and imposed technology allow to do what is needed and only then selecting tools and libraries that look useful is the main way to ignore fads.
• sebringj 10y ago
  NPM + Github + Node.js + JavaScript is easier + JavaScript was already front-end ubiquitous came together in a perfect storm to allow JavaScript packages to be created and spread like butter on toast. JavaScript is the easiest to develop with, has the most adoption, runs client/server and has the easiest package manager to both publish and use. Why is this even a question? This is not an argument for JavaScript but merely stating why it is changing so fast.
• spion 10y ago
  I touch on it a little bit here: https://spion.github.io/posts/javascript-is-not-cancer.html https://spion.github.io/posts/javascript-is-not-cancer.html TLDR: I believe its mostly due to the lack of basic language facilities in pre-ES6 JS. With ES6 covering the basics this will probably slow down (At the very least people will stop writing their own module and object systems)
• niroze 10y ago
  millennials ;) ...and it is where a lot of excitement is now. Excitement drives development (of tools themselves and general usage). Much of the time, it is for the best. People tend to get lost in tooling, which I can understand.
• techbio 10y ago
  Is there any existing tool to interrogate a codebase for adequacy for a set of tasks? Ie. PageRank/'citations' for frameworks? Should there be?
• pmarreck 10y ago
  First of all, Angular sucks (/opinion), so that's a bad example. I think it's due to the fact that Javascript is so terrible at any scale, yet is so pervasive, that working with/around it becomes this deer-in-headlights thing you can't ignore... since most HAVE to work with it in some form, doing any Web stuff. I recommend Elm, as a way around Javascript's problems while still allowing you to run in browsers: http://elm-lang.org/ http://elm-lang.org/
• techbio 10y ago
  JavaScript was originally a way to create interactive webpages, but because it broke or replicated MVC, became the backend too. The variety of backend requirements, and the flexibility of UX, led people to solve many individual workflow bottlenecks or generalize to any/many. Then so, like the English language, exploded to the simple-->jargon range of overloaded usage and niche comprehension, very quickly fragmenting, but universally powerful. Developing a framework as a startup for a particular use case may take more time than prototyping on an existing framework--this is why the prototype should be discarded, and a critique of how open source/reusable code has always been a source of technical debt apart from the rare, shining outliers.
• techbio 10y ago
  http://hotframeworks.com/ http://hotframeworks.com/ Skip the chart, look at the long tail of listings.
  • vinayan3 10y ago
    It doesn't have React. Is this an oversight or does it not count as framework in their definition?
• tomphoolery 10y ago
  The change in JS isn't "out with the old, in with the new"...it's just "in with the new". There are more choices than ever before, because you can build about 100x the kinds of apps that you could have before with JavaScript. Prior to 2009, JavaScript was pretty much only good for web applications. Now, you can build servers, embedded devices, native applications for every platform imaginable, you name it. Pretty much anything that can be built, can be built with JavaScript.
• ggregoire 10y ago
  > For example angular 2 is not compatible with angular 1, so before you even learn a framework its API is different and when you finally learn it, probably is considered outdated Angular 1 has been released in 2010 and Angular 2 in 2016. Obviously, if you started to learn Angular 1 last year it can be frustrating (specially with Angular, it's not the easiest framework to learn out there [1] [2] ). But I would say the majority of Angular developers has used it for 3 or 4 years now and most of them probably enjoy to have the chance to learn a new modern framework that fixes the design issues of the first version. To generalize: The front-end world is surely overwhelming for the new comers (but is it not the same in all the other fields of programming?). However, after some years into it, you realize that you have mostly sticked to the same tools for years. [3] [1] https://www.bennadel.com/resources/uploads/2013/feelings_about_angularjs_over_time.png https://www.bennadel.com/resources/uploads/2013/feelings_abo... [2] https://i.imgur.com/5rJH3co.png https://i.imgur.com/5rJH3co.png [3] https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19851a33 https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19...
• neilsharma 10y ago
  Slight tangent, but if someone were getting started in JS today and wanted to build medium-complexity, async-heavy, web apps with decent-sized backend, what stack should he invest his time on? React, angular, node, elm, express, etc? Let's assume he wants the skills/tools to still be relevant in 1-2 years time in a sizable percentage of the job market (noticed that many startups don't like people with web experience that isn't in React/Angular/Node).
  • ggregoire 10y ago
    You can't go wrong picking React. To get started, install the official create-react-app [1], follow Facebook's tutorial [2] and that's it. [1] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [2] https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html
  • Zyst 10y ago
    Opinion based, yada yada: React if they want to join startups or similar cutting edge companies. Node if they want to do server work. Angular 1.x if they want to go into consulting. While the JavaScript ecosystem does move insanely fast a lot of consulting companies need to have people with similar skill levels in a framework/etc. Which means you can't just switch frameworks every year (You can, however, create smaller teams with new technologies, so if a few of the guys learned React you can just make a React team with them as a base. A big misconception I've seen is that a lot of JavaScript stuff disappears after a couple of years, while in reality a lot of Consulting companies are still recruiting people for jQuery positions (In my country, might be different in the US). Sure, the new startups who are using all the newest coolness maybe won't touch jQuery and similar technologies with a 10 foot pole. That doesn't mean those technologies disappear. It depends on your goals as a person. Personally I enjoy chasing the newest thing, learning is fun. Maybe when I become more jaded at re-learning stuff every year I'll move from that kind of ecosystem. All in all, the advice I wish I could've told myself years ago is to invest a bit less time learning frameworks in depth and a bit more time learning JavaScript. JavaScript has a lot of pitfalls, but if you learn to navigate around those you are left with a very fun and powerful language. And most importantly, that knowledge is still gonna be relevant 3 years from now even if you are switching frameworks.
• NotAJSExpert 10y ago
  I think one of the things that's led to the mess with javascript is that it's kind of crazy to have settled on using a language to write such large applications that: - Has no standard library. - Is used to automate host platforms that have either no standard framework or very little (e.g. Node on v8 doesn't have nothing but it's quite small). - Has no module/namespace system. The effect of this is that immediately, anyone building anything in non-trivial has to make a decision about how to fill in things that would be covered in a standard library. I'm not even talking about fancy stuff, just the stuff supplied by underscore, lodash, etc. The choices are basically: 1) Write all the code yourself. This is an extremely low ROI option 2) Adopt a series of libraries and hope you can get them to work together 3) Adopt a framework, that by its nature, will be designed to use some sort of new pattern and this pattern will be expressed on top of whatever libraries the framework uses, so just draft behind that. There aren't really many other mainstream systems where a language is used to specialize applications on a platform where this situation obtains. Windows, OS X, iOS, Android, even Java, come with enormous, enormous amounts of library code. Generally, this library code also pushes one fairly firmly towards certain design patterns. Imagine if we all decided to use...hmmm...Scheme, I guess, to develop Windows applications, and you took away everything but the lowest-level Windows APIs. I'm using Scheme because the Scheme standard outlines a remarkably small language that has nothing approaching a standard library. We'd probably be in a similar situation. How do you do this? How much does adopting this or that library force you to do this or that? It's just not very common to have a situation where to do anything non-trivial, you need to either: - adopt an enormous amount of third party code (because the situation works at every level, each third-party solution will also not be built on a standard library ecosystem) - write an enormous amount of boilerplate code. And further, the issue is exacerbated by the fact that js doesn't really have a standard module system, so even the approaches taken to fill these gaps are frequently non-compatible, or just choosing which system to use to manage modules often means replacing huge chunks of your application. There are other reasons why JS the language is moving, all of the sudden: JS has had a lot of rough edges and all of the sudden a confluence of interest, capability, and technology has made it possible to sand down some of those edges. But I think even if the ES process slows down, and we all agree that language-wise the features in the language are pretty good or something happens that freezes, we'll keep seeing lots of churn because of the interaction between every project being built on towers of third party code with far-reaching effects. When Java, for instance, was released, the standard library it shipped with included: - a set of standard container classes: hashes, vectors, arrays, etc. - a rich set of real types (e.g. numbers that weren't insane, Objects for compatibility with the object system, primitive types in the language for performance) - a whole tree of calendar/date manipulation code - a standard way of connecting to SQL databases and all the code for that - a standard GUI-drawing and event-handling system - a big, rich set of APIs for handling IO of various kinds with different performance/complexity tradeoffs. - a concurrency api, threadpools, etc. That's just a sample. And all of the bits worked together, and sort of implied patterns in how things should be built and used. You could certainly replace anything, should you choose to, in your project (e.g. the calendar stuff really sucked), but the point is, there was a default, and there was a standard pattern for where and how to bring in new library code, and that new library code would in turn be built on as little third-party code as possible. Look at an average iOS project's Podfile or Carthage file, Android project's Gradle file, and then look at a Node or browser js project's package.json. Then actually look in Pods and node_modules. The average amount of third party libs in a JS project is many orders of magnitude higher than in the others. There are like, what, five or so competing implementations of Promises in javascript land? And they aren't mutually compatible always, so this means if you want to use non-ES6 babel-compiled Promises in your code, you have to: - choose a library - hope that other libraries and frameworks you use use the same style - add shims or something where they don't, or else switch out the library and framework. This is just like...no one writing an Android app is like "which Runnables library are you using?". No one writing an iOS app is like "soo...the new GCD spec looks interesting, which GCD lib are you using for your project? Oh yeah how spec-complete is it? Does it work with AFNetworking?" "Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc. Lodash’s modular methods are great for: Iterating arrays, objects, & strings" Iterating arrays, objects, & strings is something that most other languages have decent std lib support for, and so even your third-party libs will use the host language's affordances. In Javascript you have to ask these questions all the time.
• scotty79 10y ago
  It's due to openness of npm ecosystem. Any other language you'd have 50 different angulars at the same time but almost noone would know about any of them because they'd be confined to the companies that spawned them. Frameworks as a popular thing started because people (rails?) started sharing their code and no other can share code as easily as JS and npm. Angular 2 should be called Begular because it doesn't have anything to do with Angular but inspiration. You can stay on Angular but don't be surprised that people will prefer to develop something else since Angular folk painted themselves into a corner so hard that to make framework that sucks less they need to go back to drawing board.
• bbbbbbbbbbb 10y ago
  There are two different questions there. Angular 1 was written by people who knew nothing but OO programming. JavaScript isn't OO. So they spent a lot of time square pegging a round hole because they were ignorant of what they were doing (probably a group of young coders). People are now starting to get on the functional train (which JavaScript is more like than OO), and angular is trying to now fix the fact they were short sighted and too opinionated about the wrong things. JavaScript, in general, has always been in a rapid state of change. Or, more broadly, the UI of the web. From flash and silverlight to mootools and jquery and CSS animations and canvas... there isn't a good way to do web UIs yet. There is a lot of trial and error happening which makes for some rough waters.