Ask HN: Why is everything in JavaScript changing so fast?
Change and variety of options is a good thing, but in js the rate of change in methodologies, frameworks, libraries is so much high. 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.
Why is this happening especially in js?
302 comments
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/
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=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 . 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.
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=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 . 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.
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.
Activity does not equate quality.
It's easy to sit back and critisize JavaScript and the web with dismissive comments like this. I have heard variations on these same memes for many years.
But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.
It's always fair to criticize so that we ask ourselves the hard questions. So, it's also worth asking ourselves if we are staring too close to the wall when we try to paint other languages as backwards and therefore bad (or at least a bad choice). Just maybe, the language feature bullet list in your head (and corresponding subtleties of implementation) isn't the thing that matters most. Maybe the thing that really matters is something not as easy to codify as a language tool chain, like human consensus.
Also, it is false association to suggest that quantity != quality is somehow particular to JavaScript. Infinite monkeys will produce infinite crap no matter what brand typewriter you give them.
But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.
It's always fair to criticize so that we ask ourselves the hard questions. So, it's also worth asking ourselves if we are staring too close to the wall when we try to paint other languages as backwards and therefore bad (or at least a bad choice). Just maybe, the language feature bullet list in your head (and corresponding subtleties of implementation) isn't the thing that matters most. Maybe the thing that really matters is something not as easy to codify as a language tool chain, like human consensus.
Also, it is false association to suggest that quantity != quality is somehow particular to JavaScript. Infinite monkeys will produce infinite crap no matter what brand typewriter you give them.
> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.
Because JavaScript was, and basically still is, the only option for client-side web development - that is to say, it was, and basically is, the only option for distributing sandboxed, instantly-updating executable code to users at any scale. Any other language requires me to convince users to download an application that runs with full privileges on their account. (For a while we also had Flash and Java, but then we realized that Flash and Java basically also imply full privileges, in practice, because their sandboxes don't work well.)
Therefore, JS got popular; therefore, people used it. This has very little to do with the quality of the language or its libraries. Note that I am not criticizing the quality any more than I'm praising it, just saying that it's irrelevant as long as it's good enough.
Basically the same thing happened with UNIX and C at a much smaller scale several decades ago, except it wasn't about client-side app development, it was about getting things to run on servers at all. UNIX isn't a fantastic OS. C isn't a fantastic language. But, in the words of Richard Gabriel's "The Rise of Worse is Better", "UNIX and C are the ultimate computer viruses."
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
JavaScript and the dynamic web the new ultimate computer viruses. But they grew much, much more quickly, and haven't had the benefit of the last forty-ish years to get decently good. UNIX and C in the middle of the UNIX wars were at least as much of a disaster.
Because JavaScript was, and basically still is, the only option for client-side web development - that is to say, it was, and basically is, the only option for distributing sandboxed, instantly-updating executable code to users at any scale. Any other language requires me to convince users to download an application that runs with full privileges on their account. (For a while we also had Flash and Java, but then we realized that Flash and Java basically also imply full privileges, in practice, because their sandboxes don't work well.)
Therefore, JS got popular; therefore, people used it. This has very little to do with the quality of the language or its libraries. Note that I am not criticizing the quality any more than I'm praising it, just saying that it's irrelevant as long as it's good enough.
Basically the same thing happened with UNIX and C at a much smaller scale several decades ago, except it wasn't about client-side app development, it was about getting things to run on servers at all. UNIX isn't a fantastic OS. C isn't a fantastic language. But, in the words of Richard Gabriel's "The Rise of Worse is Better", "UNIX and C are the ultimate computer viruses."
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
JavaScript and the dynamic web the new ultimate computer viruses. But they grew much, much more quickly, and haven't had the benefit of the last forty-ish years to get decently good. UNIX and C in the middle of the UNIX wars were at least as much of a disaster.
There's a certain amount of irony in mentioning "Worse is Better" in this context.
People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed.
People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp.
I have come to prefer Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)
People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed.
People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp.
I have come to prefer Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)
Yeah, it's very true that JS is much more of a Lisp than a curly-brace language, despite its syntax. But I think the reference is still fitting because JS is an absolutely terrible Lisp. :)
And the story of JS interpreters, JITs, etc. in browsers (and not in browsers) matches the story of C compilers in the essay, just with changes in timing:
C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language. [...]
Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
And the story of JS interpreters, JITs, etc. in browsers (and not in browsers) matches the story of C compilers in the essay, just with changes in timing:
C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language. [...]
Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
Worse & Worserer: Windows and C++, which even more people run :-(
(with apologies to the Dumb and Dumber movies)
(with apologies to the Dumb and Dumber movies)
If Javascript were an acceptable Lisp, you could have written async/await as a small set of macros instead of waiting for a huge third party project that knows how to parse the grammar.
The reason JavaScript is the de facto standard language for front-end web development seems obvious: it's effectively the only language for that development. There have previously been other popular choices, but browser developers have killed support for those alternatives for their own reasons.
In my experience working with Perl and Python most external libraries work and are well documented. Whenever I have tried JavaScript its a vastly poorer experience. Admittedly I have far more experience with the first two languages, but that would likely find more problems with Perl or Python, no?
(I don't really do PHP, but I have a feeling that I would find the experience closer to JavaScript from talking to colleagues and reading about it).
(I don't really do PHP, but I have a feeling that I would find the experience closer to JavaScript from talking to colleagues and reading about it).
I've never had problems with docs in JS, both node and browser. The MDN is a limitless ressource of information for the base language, and for libraries, well you're going to get undocumented libraries in any language. It might be more "obvious" in JS because of the sheer amount of libraries, but I've found python libs that were very poorly documented too.
This is a problem we should be HAPPY to have. Having libraries doing EXACTLY what we want, that's just missing docs, is better than the alternative I've found in many other languages : no libraries, so we have to do everything ourselves.
This is a problem we should be HAPPY to have. Having libraries doing EXACTLY what we want, that's just missing docs, is better than the alternative I've found in many other languages : no libraries, so we have to do everything ourselves.
I think the other poster meant 3rd party libraries, rather than the runtime.
That said, the docs on (most of) the libraries I have used are generally pretty good.
* Prototype - excellent docs (but library since overshadowed by jQuery)
* jQuery - initially the docs were hard to follow, but they seem to have gotten better
* Angular - good enough docs, and plenty of books on the larger concepts of how things fit together
* moment.js - excellent docs
* validatejs - excellent docs
* Ramdajs - generally excellent docs, but I am less familiar with some of the FP concepts used in a few cases.
The quality on some of the jQuery and Angular plugins varies a bit, admittedly.
That said, the docs on (most of) the libraries I have used are generally pretty good.
* Prototype - excellent docs (but library since overshadowed by jQuery)
* jQuery - initially the docs were hard to follow, but they seem to have gotten better
* Angular - good enough docs, and plenty of books on the larger concepts of how things fit together
* moment.js - excellent docs
* validatejs - excellent docs
* Ramdajs - generally excellent docs, but I am less familiar with some of the FP concepts used in a few cases.
The quality on some of the jQuery and Angular plugins varies a bit, admittedly.
> explanation for why their platform / language / framework [...] did not become the de facto tool
You're implying this happened to JS because of some merit. But it didn't, it was just sheer coincidence and bad luck (for most of us at least, including users).
You're implying this happened to JS because of some merit. But it didn't, it was just sheer coincidence and bad luck (for most of us at least, including users).
No, I agree with you, actually. Luck plays a huge part. It should inform all of us with opinions in this area about how little our opinions really matter.
Also, I disagree that users are suffering as a result, but that is a different discussion altogether.
Also, I disagree that users are suffering as a result, but that is a different discussion altogether.
Explain what the coincidence was ? There are alternatives everywhere (ActiveX, flash, java, visual basic IIRC). And yet here we are, with JS.
I believe JS came here because it actually is the best language we have had in the web. It's so easy to throw shit arround, but let's be honest with ourselves, this isn't purely out of luck.
I believe JS came here because it actually is the best language we have had in the web. It's so easy to throw shit arround, but let's be honest with ourselves, this isn't purely out of luck.
JS won because it was the only thing that every browser supported from the very beginning, and the various differences in implementation (of which there were many) were eventually shimmable by jQuery and other AJAX frameworks. Everything else was either some alternative only supported by one of the vendors (VBScript, Dart), or a full-blown plugin that had a different model of interaction with the webpage (Java, Shockwave, Flash, Silverlight).
It's pretty much the textbook instance of a compromise between vendors of competing interests to further the common web. Despite this, it took a really, really long time -- almost ten years -- for JS to receive additional browser-implemented APIs that brought that platform's capability to what we know today and comparable to that of what we had with plugins -- and still, not every vendor supports every spec yet, making this "open web" no less subject to vendor pressures, despite being 'open' and 'neutral' [1].
[1] https://news.ycombinator.com/item?id=12259827#12259940
It's pretty much the textbook instance of a compromise between vendors of competing interests to further the common web. Despite this, it took a really, really long time -- almost ten years -- for JS to receive additional browser-implemented APIs that brought that platform's capability to what we know today and comparable to that of what we had with plugins -- and still, not every vendor supports every spec yet, making this "open web" no less subject to vendor pressures, despite being 'open' and 'neutral' [1].
[1] https://news.ycombinator.com/item?id=12259827#12259940
JS is the only language integrated into the browser and the DOM. Netscape rejected other languages (Python, Perl, TCL) because of syntax, so Brendan Eich disguised Scheme into Java syntax and hacked up a prototype in 10 days.
Today, Javascript is sooo interwoven with the DOM in browsers that it is near impossible to separate them. Google planned to do this for Dart, but gave up. If they had done this and other browser vendors had followed, adding a third and forth and more languages would have been (relatively) easy, because the abstraction were in place. Then we would have seen a healthy competition.
There is asm.js. Maybe we will get a "web bytecode" at some point, but that will easily take a decade and more. The pressure is increasing, because our CPUs don't get exponentially more powerful anymore. And delivering apps via the web is still going strong.
Today, Javascript is sooo interwoven with the DOM in browsers that it is near impossible to separate them. Google planned to do this for Dart, but gave up. If they had done this and other browser vendors had followed, adding a third and forth and more languages would have been (relatively) easy, because the abstraction were in place. Then we would have seen a healthy competition.
There is asm.js. Maybe we will get a "web bytecode" at some point, but that will easily take a decade and more. The pressure is increasing, because our CPUs don't get exponentially more powerful anymore. And delivering apps via the web is still going strong.
1. WebKit rejected adding barriers to support multiple garbage collectors and a super-GC to collect cycles, required by Dart or any 2nd VM. See https://lists.webkit.org/pipermail/webkit-dev/2011-December/... where Fil Pizlo of Apple cites 5% throughput regression.
Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is even less plausible.
2. See https://github.com/WebAssembly for progress on what asm.js showed was possible: a 2nd, initially co-expressive with asm.js, eventually more expressive, binary syntax for the Web. It's happening now, this year and probably shipping experimentally in 1Q2017.
Writing "easily take a decade" out of ignorance just says to me you didn't even bother to use google!
Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is even less plausible.
2. See https://github.com/WebAssembly for progress on what asm.js showed was possible: a 2nd, initially co-expressive with asm.js, eventually more expressive, binary syntax for the Web. It's happening now, this year and probably shipping experimentally in 1Q2017.
Writing "easily take a decade" out of ignorance just says to me you didn't even bother to use google!
There were noon-JS languages on the web, though; in particular, VBScript was a thing in the (at the time) most popular browser. I understand that at one point there was a third-party Perl implementation too.
Unfortunately there wasn't a good way for the other browsers to implement it. Or perhaps fortunately, depending on your point of view…
Unfortunately there wasn't a good way for the other browsers to implement it. Or perhaps fortunately, depending on your point of view…
> I believe JS came here because it actually is the best language we have had in the web.
It is the only language we have had in the web (modulo some minor experiments). The only reason it's popular in the browser is because it's the only choice at all. The only reason it is used on the server is because some folks are familiar with it from using (overusing IMHO, but that's a different rant) it in the browser and are not familiar with the advantages of using any other language.
I've written this before, but sometimes in my most morose moment I like to imagine what the world might have been like had Brendan Eich been permitted to implement a Scheme instead. And I don't even like Scheme!
It is the only language we have had in the web (modulo some minor experiments). The only reason it's popular in the browser is because it's the only choice at all. The only reason it is used on the server is because some folks are familiar with it from using (overusing IMHO, but that's a different rant) it in the browser and are not familiar with the advantages of using any other language.
I've written this before, but sometimes in my most morose moment I like to imagine what the world might have been like had Brendan Eich been permitted to implement a Scheme instead. And I don't even like Scheme!
JS won out the web because it came with HTML5, not the other way around.
JS won out the web long before anyone ever heard of HTML5.
[deleted]
JavaScript beats those out because a.) it integrates with the DOM b.) its the only one that works on every platform today (people seem to forget that before the iPhone, web apps were heavily Flash-based).
These features are powerful, but don't necessarily reflect the quality of the language design or development ecosystem.
> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users.
I believe that part of the reason is the ease of access to JS development. It allowed an inordinate amount of poorly trained devs to enter into the job market. Because you can quickly whip up fancy UIs and show them to unsuspecting non-techie types, you can quickly earn a reputation as a "computer whiz".
I think there were many de facto ways of doing things before this, none of which were perfect, but some of which followed better design principles.
If you look at software industries where security and stability is of utmost importance, you will not find these newer frameworks in use - nor the languages they use. I'm thinking life critical systems here.
I believe that part of the reason is the ease of access to JS development. It allowed an inordinate amount of poorly trained devs to enter into the job market. Because you can quickly whip up fancy UIs and show them to unsuspecting non-techie types, you can quickly earn a reputation as a "computer whiz".
I think there were many de facto ways of doing things before this, none of which were perfect, but some of which followed better design principles.
If you look at software industries where security and stability is of utmost importance, you will not find these newer frameworks in use - nor the languages they use. I'm thinking life critical systems here.
There are a few condescending attitudes at play in your comment.
Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and practice. So, being easy to use is a much more powerful feature for a language / framework / platform than most.
Also, we should all be aspiring to use tools that enable us to quickly spin up a prototype UI that looks convincingly useful. I'm not sure why that's a knock against JS.
Also consider this: the languages / frameworks / platforms before the web, and before JS, were harder to use and relatively very discouraging to new users (this also sometimes goes for the communities associated with those languages / frameworks / platforms).
We all started from a place of ignorance as software developers, and many of us never would have left that place if it weren't for someone looking at us and seeing a computer whiz in the making.
Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and practice. So, being easy to use is a much more powerful feature for a language / framework / platform than most.
Also, we should all be aspiring to use tools that enable us to quickly spin up a prototype UI that looks convincingly useful. I'm not sure why that's a knock against JS.
Also consider this: the languages / frameworks / platforms before the web, and before JS, were harder to use and relatively very discouraging to new users (this also sometimes goes for the communities associated with those languages / frameworks / platforms).
We all started from a place of ignorance as software developers, and many of us never would have left that place if it weren't for someone looking at us and seeing a computer whiz in the making.
> So, being easy to use is a much more powerful feature for a language / framework / platform than most.
I never said that JS was easy to use. I said it was easy to access. With JS, you don't really need an IDE, compiler, runtime etc. You need a browser, and a text editor and you can get started. It's unlike a lot of other languages in that way.
In some ways, I'd argue that languages like JavaScript are harder to use, or at least harder to use well. There is a reason that languages like Ada exist with very strong type systems. Granted, Ada is not a web development language, but I think my point still holds true since languages like TypeScript are making inroads in this arena.
I think spinning up "convincingly useful" UIs is part of the problem. First, in a lot of ways it's the wrong place to start for software design. It raises expectations and can create a contract in the minds of the client, customer, or user that this is what the software will do, and it will do it perfectly.
I'm not claiming that I (or any other programmer) started out knowing everything. But taking the time to learn, apprentice, and hone the craft of software development (the full cycle, not just writing code) is part of the game.
I think the attraction of a lot of the current web frameworks is the "whiz-bang" results you get, and it's my humble opinion that you should no more build software that way than you should a smartphone, bridge, or building. I think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.
I never said that JS was easy to use. I said it was easy to access. With JS, you don't really need an IDE, compiler, runtime etc. You need a browser, and a text editor and you can get started. It's unlike a lot of other languages in that way.
In some ways, I'd argue that languages like JavaScript are harder to use, or at least harder to use well. There is a reason that languages like Ada exist with very strong type systems. Granted, Ada is not a web development language, but I think my point still holds true since languages like TypeScript are making inroads in this arena.
I think spinning up "convincingly useful" UIs is part of the problem. First, in a lot of ways it's the wrong place to start for software design. It raises expectations and can create a contract in the minds of the client, customer, or user that this is what the software will do, and it will do it perfectly.
I'm not claiming that I (or any other programmer) started out knowing everything. But taking the time to learn, apprentice, and hone the craft of software development (the full cycle, not just writing code) is part of the game.
I think the attraction of a lot of the current web frameworks is the "whiz-bang" results you get, and it's my humble opinion that you should no more build software that way than you should a smartphone, bridge, or building. I think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.
> think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.
I agree with this sentiment, with a few (rather large) caveats:
∙ Best practices yesterday may be legacy practices tomorrow.
∙ The Next Big Thing™ is usually hidden lower in the stack (in the above example it was cheaper commodity hardware and free-as-in-beer operating systems), and while it may not force throwing away everything, it can still prompt throwing away a heck of a lot.
So, yeah, there is a lot of churn in the JS ecosystem right now. It's inevitable that there will be some sort of shakeout and some projects will emerge as de-facto standards around things like declaring dependencies, build tools, etc. The same thing happens in every successful software ecosystem exploiting a new niche.
I agree with this sentiment, with a few (rather large) caveats:
∙ Best practices yesterday may be legacy practices tomorrow.
∙ The Next Big Thing™ is usually hidden lower in the stack (in the above example it was cheaper commodity hardware and free-as-in-beer operating systems), and while it may not force throwing away everything, it can still prompt throwing away a heck of a lot.
So, yeah, there is a lot of churn in the JS ecosystem right now. It's inevitable that there will be some sort of shakeout and some projects will emerge as de-facto standards around things like declaring dependencies, build tools, etc. The same thing happens in every successful software ecosystem exploiting a new niche.
[deleted]
quantity !== quality
There is a (perhaps apocryphal) story about the art class which was separated into 2 groups - one group worked on a single project all semester and the other group worked on a new project every day. People in the group that worked on a project every day produced better work than people in the "single project" group. My google-fu is weak, so I cannot find the reference.
I'm not suggesting that the Javascript ecosystem is filled with awesome stuff, but sometimes quantity leads to quality.
I'm not suggesting that the Javascript ecosystem is filled with awesome stuff, but sometimes quantity leads to quality.
This is the running premise behind the book Art and Fear, which basically concludes that iteration with quality feedback is the best way to develop your abilities and produce your best work. That is, quantity is the best path to quality.
https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...
https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...
Hmm. The "fear" aspect sounds a lot like what Steve Yegge called software conservatism.
Thank you!
Maybe because art art school you always do the same thing: so doing it continually for one semester or restarting projects on shorter times, the final thing would be quite the same, except that if you work on more small projects, you will maybe learn faster.
And, your art is yours. No artist is able to do huge harm to a whole industry by releasing some crappy painting with terrible design choices. They're only harming themselves and/or their reputation.
There is a parallel though: bad art is weeded out over time, the good stuff remains. In software it is quite similar, the good stuff has staying power, the bad stuff will be forgotten soon enough. The average half-life of a typical javascript framework is quite telling in this respect.
There is a parallel though: bad art is weeded out over time, the good stuff remains. In software it is quite similar, the good stuff has staying power, the bad stuff will be forgotten soon enough. The average half-life of a typical javascript framework is quite telling in this respect.
Dude, comeon. The browser has evolved a lot as a platform, as has the hardware power of computers running them. Maybe we're re-writing computer history, but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.
* Do you really want to write CSS without a pre-processor?
* Do you really want to control a webpage's state without JS models in the browser?
* Do you really want to update html with individual jquery calls?
* Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
I'm glad that we have an open market to exchange people's ideas. Yes, a lot of it is crap, and even among the highly adopted packages there will be problems. But that's the beauty of the market-- people can vote with their feet.
This article sums up how I feel: http://mrmrs.io/writing/2015/07/27/too-many-tools/
> "Four–fifths of everybody's work must be bad. But the remnant is worth the trouble for its own sake." - Rudyard Kipling in 1890
* Do you really want to write CSS without a pre-processor?
* Do you really want to control a webpage's state without JS models in the browser?
* Do you really want to update html with individual jquery calls?
* Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
I'm glad that we have an open market to exchange people's ideas. Yes, a lot of it is crap, and even among the highly adopted packages there will be problems. But that's the beauty of the market-- people can vote with their feet.
This article sums up how I feel: http://mrmrs.io/writing/2015/07/27/too-many-tools/
> "Four–fifths of everybody's work must be bad. But the remnant is worth the trouble for its own sake." - Rudyard Kipling in 1890
>Dude, comeon. The browser has evolved a lot as a platform, as has the hardware power of computers running them.
Yes. It has evolved to counter-balance those advances in hardware power, in order to provide a sub-par 2000 native desktop application experience in a 2016 browser sandbox.
>Maybe we're re-writing computer history
Maybe?
>but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.
Err, why do we "have to"?
And what's with the "old timers" / hot young JS developers dichotomy?
Yes. It has evolved to counter-balance those advances in hardware power, in order to provide a sub-par 2000 native desktop application experience in a 2016 browser sandbox.
>Maybe we're re-writing computer history
Maybe?
>but if that's the case then it's because we have to migrate everything to javascript and the wiser old timers want nothing to do with it.
Err, why do we "have to"?
And what's with the "old timers" / hot young JS developers dichotomy?
We have to rewrite everything in JS because JS is the language that runs on browsers. :) If you were asking a higher-level why (why do we have to use the browser), look rer's sibling comment.
I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old timers" is correct maybe 80% of the time, since the complainers are probably people who have years of non-JS experience and are disappointed that the new bootcampers haven't gone through their coming-of-age programming rituals. But I have a friend who is a member of the C++ master-race, so trust me, I know that gripes about browsers & JS can come from many kinds of people.
I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old timers" is correct maybe 80% of the time, since the complainers are probably people who have years of non-JS experience and are disappointed that the new bootcampers haven't gone through their coming-of-age programming rituals. But I have a friend who is a member of the C++ master-race, so trust me, I know that gripes about browsers & JS can come from many kinds of people.
>We have to rewrite everything in JS because JS is the language that runs on browsers.
Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway.
Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal?
If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.
>* But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping.*
Well, you first stop someone from drowning and then you show them how to swim...
Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway.
Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal?
If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.
>* But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping.*
Well, you first stop someone from drowning and then you show them how to swim...
If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes
To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.
To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.
Uh...
Oh, you mean 'personal computing' in it's original sense, which encompasses mobile platforms as well, not just desktop computers.
Oh, you mean 'personal computing' in it's original sense, which encompasses mobile platforms as well, not just desktop computers.
Right. IMHO, a lot of the reason that alternative devices, from smartphones to games consoles, took off was they solved the biggest long-standing headache for Windows users: they just wanted to get and use software to do things, not to worry about installing and configuring and updating that software or potential difficulties with removing it or how it interacted with other software.
> we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.
Show me another way to write end-user applications that are cross platform, and then (if it existed prior to 1995, or even 2005) explain to me why your particular alternative didn't take over the world.
Heck, even standalone desktop and mobile apps are now being built with web technologies (react-native, Electron, etc.) rather than GUI frameworks like wxWidgets.
Show me another way to write end-user applications that are cross platform, and then (if it existed prior to 1995, or even 2005) explain to me why your particular alternative didn't take over the world.
Heck, even standalone desktop and mobile apps are now being built with web technologies (react-native, Electron, etc.) rather than GUI frameworks like wxWidgets.
> Do you really want to write CSS without a pre-processor?
Not him, but yes, I absolutely do. Pre-processors mainly have the effect of forcing you to have a build tool workflow, and the nice thing about web design is that you don't need stuff like that.
Not him, but yes, I absolutely do. Pre-processors mainly have the effect of forcing you to have a build tool workflow, and the nice thing about web design is that you don't need stuff like that.
I have found a nice compromise, in Angular apps at least, is to make a directive (tag library) that generates my "<style>" block.
It's reasonably "thin", but I can use variables to hold repeated style elements that get mixed in various selectors.
It's reasonably "thin", but I can use variables to hold repeated style elements that get mixed in various selectors.
They were rhetorical questions anyway :) But you're right, I get away without preprocessors when I'm doing very small projects. And a year ago my team had a 20-second SASS compilation step, that was painful. I guess I couldn't do without it because of things like: variables, nested rules, vendor prefixes, and mixins. I use a lot of mixins in scss and I feel like my code becomes more modular because of it.
> I use a lot of mixins in scss and I feel like my code becomes more modular because of it.
Well, it does, if you don't emulate the same effect with other means. But imho, needing modularity in CSS means (for most projects that are not gigantesque) that the CSS is too big anyway. It depends on what one does, specific web apps might need it. But normal web pages never.
Well, it does, if you don't emulate the same effect with other means. But imho, needing modularity in CSS means (for most projects that are not gigantesque) that the CSS is too big anyway. It depends on what one does, specific web apps might need it. But normal web pages never.
> we have to migrate everything to javascript
Why?
What I really want is the whole browser to go away.
Why?
What I really want is the whole browser to go away.
Okay. I guess you're welcome to do that? We browser coders will just continue to go to market faster. It's pretty cool that, if you put your work in, you can make a GUI on the browser that is accessible to all desktops and phones. That's 2 billion users.
The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?
The obvious question is: what would you replace it with? Do you want to replace it all with native apps? Or do you think that this whole internet thing is overrated?
What's wrong with native apps? They use less memory, battery, and processor than an interpreted stack. They can be more responsive than the hardwired 16ms latency built into the browser. If you need network it's not hard to open a socket. The browser itself is a native app opening sockets.
In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps is the developer.
In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps is the developer.
I'm not taking a side here, but I would like to advocate for a fair comparison, since you have skipped all of the trade-offs in the other direction.
For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true), ...
There's pros and cons to both sides. Just framing the situation as "my side has these benefits, therefore there is no reason to consider your side" is not an honest discussion.
For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true), ...
There's pros and cons to both sides. Just framing the situation as "my side has these benefits, therefore there is no reason to consider your side" is not an honest discussion.
> easier to discover,
How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
> easier to update,
because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
> easier to manage (since you only have one version in the wild you have to handle), Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.
> easier to launch (especially for first-time users), How is typing a or clicking a link easier than tapping/clicking an icon?
> easier to use from different platforms,
If your browser on your platform is supported. And you have the right version.
> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)
This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?
How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
> easier to update,
because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
> easier to manage (since you only have one version in the wild you have to handle), Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.
> easier to launch (especially for first-time users), How is typing a or clicking a link easier than tapping/clicking an icon?
> easier to use from different platforms,
If your browser on your platform is supported. And you have the right version.
> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)
This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?
> How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.
Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.
> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
Not sure I follow. Are you asserting that native apps are easier to update than web apps?
> If your browser on your platform is supported. And you have the right version.
The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
> This is a joke, right?
Is this a good way to have a productive conversation?
> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?
Do you think only web apps communicate with servers?
Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.
> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?
Not sure I follow. Are you asserting that native apps are easier to update than web apps?
> If your browser on your platform is supported. And you have the right version.
The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
> This is a joke, right?
Is this a good way to have a productive conversation?
> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?
Do you think only web apps communicate with servers?
> Not sure I follow. Are you asserting that native apps are easier to update than web apps?
I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update.
> The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
That can't possibly be true. Most platforms have more than one browser available, and with the exception of Microsoft, browsers don't have a "use x.y.z version rendering" like platform sdks.
Edit: unless you're taking the approach of: it works with this specific platform device running browser X, so it must work with all others running X. In which case, why not take the same approach to native apps?
> Do you think only web apps communicate with servers?
Where did I say that? Nowhere.
Web apps must contact servers and any remotely useful app will have all its storage server side.
In addition, web apps rely on servers to deliver the very thing the user sees and interacts with. UI spoofing has become such an issue browser vendors are reverting back to make it harder for web pages to present native looking dialogs etc.
Native apps can operate in a client server model, but a great deal of them don't need to because their use case is for local work, and even those that do, are merely transferring data over that channel. They aren't dependent on the same channel for the very interface the user sees.
Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update.
> The combinations are smaller than the combinations of operating systems and phones one would have to worry about.
That can't possibly be true. Most platforms have more than one browser available, and with the exception of Microsoft, browsers don't have a "use x.y.z version rendering" like platform sdks.
Edit: unless you're taking the approach of: it works with this specific platform device running browser X, so it must work with all others running X. In which case, why not take the same approach to native apps?
> Do you think only web apps communicate with servers?
Where did I say that? Nowhere.
Web apps must contact servers and any remotely useful app will have all its storage server side.
In addition, web apps rely on servers to deliver the very thing the user sees and interacts with. UI spoofing has become such an issue browser vendors are reverting back to make it harder for web pages to present native looking dialogs etc.
Native apps can operate in a client server model, but a great deal of them don't need to because their use case is for local work, and even those that do, are merely transferring data over that channel. They aren't dependent on the same channel for the very interface the user sees.
Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
> I'm saying the processes are more robust.
I disagree. I think updating a web app is vastly more robust. You update the source, and the only possible issue you have is caching and platform compatibility (the former is a real issue, the latter is mostly alleviated by decent testing).
Updating native apps (due to the next point) is much more problematic because the number of platforms is much higher.
> Most platforms have more than one browser available
Yeah but you can't multiply the number of browsers times the number of operating systems, because Firefox on Linux and Firefox on Windows and Firefox on Android and Firefox on MacOS are (for 99% of the apps) the same target.
> Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
Are you interested in a real discussion? Or just posturing?
I disagree. I think updating a web app is vastly more robust. You update the source, and the only possible issue you have is caching and platform compatibility (the former is a real issue, the latter is mostly alleviated by decent testing).
Updating native apps (due to the next point) is much more problematic because the number of platforms is much higher.
> Most platforms have more than one browser available
Yeah but you can't multiply the number of browsers times the number of operating systems, because Firefox on Linux and Firefox on Windows and Firefox on Android and Firefox on MacOS are (for 99% of the apps) the same target.
> Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.
Are you interested in a real discussion? Or just posturing?
Thanks for this. I was meaning to respond to my own comment but you made the points for me. It definitely goes both ways.
I agree, they are better and faster! But they're expensive, from an engineering-time point of view. I think that small teams with a new product would struggle to have solid native apps on ios, android, windows, osx and linux simultaneously.
I've also gotten a pretty bad taste in my mouth about some companies pushing a native app down my throat. TripAdvisor would only show me the first three reviews on a place if I was browsing via mobile, as a way to push me to download the app. And now that they're on my android they sent me a couple of spammy notifications before I disabled them. I wanted to treat TripAdvisor like a website, not like an app that has access to all phone.
I've also gotten a pretty bad taste in my mouth about some companies pushing a native app down my throat. TripAdvisor would only show me the first three reviews on a place if I was browsing via mobile, as a way to push me to download the app. And now that they're on my android they sent me a couple of spammy notifications before I disabled them. I wanted to treat TripAdvisor like a website, not like an app that has access to all phone.
I have gotten to hate most Android apps, constantly sending notifications - spam on the screen, phone on the desk going "ding, ding, ding" all afternoon :-(
On iOS, I've been adopting a policy of refusing the request for permission to send me notifications, unless I can think of a good reason I'd want to see them. I can always change my mind later and approve it if I need to, after all.
"What's wrong with native apps?" Can you even imagine having a native app for everything we do today in browsers? An app for each Credit Card I hold. A native app for each news site I read. A native app for every social media site. A native app for all the map searches, directions, etc. we all use. Security updates? Nightmare. Multi-OS support? forget about it. We'd all be back to a Windows monopoly. No thanks.
> An app for each Credit Card I hold
If a bank/credit union/etc doesn't have a native app in 2016, I doubt they have a web app that's usable on a phone either.
> A native app for each news site I read
Right, because RSS readers and aggregators aren't totally a thing.
> A native app for every social media site
Those literally exist today.
> A native app for all the map searches, directions, etc. we all use
You realise you don't need a new app for each search you want to do? I don't even understand this premise.
> Security updates? Nightmare
Right, because having half-baked web-apps with millions of user's personal data all stuck in a big fat juicy database in one spot, just waiting to be breached and spread like herpes in a brothel has worked out so fucking well.
Every major mobile platform and the two leading commercial desktop platforms have app store infrastructure which provide automatic updates of client-installed apps.
> Multi-OS support? forget about it.
Right, because no app ever has been developed cross platform, and every web app ever created works perfectly in every browser with zero effort from the developer.
> We'd all be back to a Windows monopoly.
Wat.
Edit: additionally, a number of the things you describe, i.e. news sites, aren't web-apps in the way most people think. They offer very limited if any interaction or functionality for the user except navigating to find/read other news content, and possibly leave feedback. Those sorts of things are what the web excels at, because they're essentially used for one-way content viewing.
If a bank/credit union/etc doesn't have a native app in 2016, I doubt they have a web app that's usable on a phone either.
> A native app for each news site I read
Right, because RSS readers and aggregators aren't totally a thing.
> A native app for every social media site
Those literally exist today.
> A native app for all the map searches, directions, etc. we all use
You realise you don't need a new app for each search you want to do? I don't even understand this premise.
> Security updates? Nightmare
Right, because having half-baked web-apps with millions of user's personal data all stuck in a big fat juicy database in one spot, just waiting to be breached and spread like herpes in a brothel has worked out so fucking well.
Every major mobile platform and the two leading commercial desktop platforms have app store infrastructure which provide automatic updates of client-installed apps.
> Multi-OS support? forget about it.
Right, because no app ever has been developed cross platform, and every web app ever created works perfectly in every browser with zero effort from the developer.
> We'd all be back to a Windows monopoly.
Wat.
Edit: additionally, a number of the things you describe, i.e. news sites, aren't web-apps in the way most people think. They offer very limited if any interaction or functionality for the user except navigating to find/read other news content, and possibly leave feedback. Those sorts of things are what the web excels at, because they're essentially used for one-way content viewing.
You just described about half of the smart phone home screens.
> The person that benefits the most from web apps is the developer.
Users also benefit. For instance, linux users can use the same web apps as windows users.
Users also benefit. For instance, linux users can use the same web apps as windows users.
>What's wrong with native apps?
Because you really don't need a native application to look up the time the local Thai place is open or if the local independent movie theater has a showing tonight. Installing two native apps to do that is burdensome on consumers and producers
Because you really don't need a native application to look up the time the local Thai place is open or if the local independent movie theater has a showing tonight. Installing two native apps to do that is burdensome on consumers and producers
Where is the 16ms hardwired latency in the browser coming from?
He probably agrees with this http://web.archive.org/web/20120509105723/http://teddziuba.c...
If developers were better about releasing quality, multi-platform software using their 1970s languages of choice, maybe we wouldn't have all moved to the browser.
> Do you really want to write CSS without a pre-processor?
Yes. The only things that are worth having one for are variables and that’s not enough to add the development overhead.
> Do you really want to control a webpage's state without JS models in the browser?
I prefer to avoid controlling a webpage’s state in the browser as much as possible.
> Do you really want to update html with individual jquery calls?
No, I want to update the DOM…
> Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
… without jQuery, yes, because it’s designed horribly.
These practices also happen to result in a website that is actually possible to develop and view on my computer with reasonable performance, because I’m one of those users nobody cares about who can’t afford the latest MacBook.
Yes. The only things that are worth having one for are variables and that’s not enough to add the development overhead.
> Do you really want to control a webpage's state without JS models in the browser?
I prefer to avoid controlling a webpage’s state in the browser as much as possible.
> Do you really want to update html with individual jquery calls?
No, I want to update the DOM…
> Do you really want to write websites _without_ using jquery? Keep in mind that jquery is only 10 years old.
… without jQuery, yes, because it’s designed horribly.
These practices also happen to result in a website that is actually possible to develop and view on my computer with reasonable performance, because I’m one of those users nobody cares about who can’t afford the latest MacBook.
I don't want to do any of these things. They are the result of bad decisions in years past.
Now more and more JS abstractions are heaped upon the pile and we call it the best thing since sliced bread. No.
Now more and more JS abstractions are heaped upon the pile and we call it the best thing since sliced bread. No.
Things re-invented in JS (and by most language communities as they evolve):
- Build systems
- Dependency management
- Some form of code modularity and references between modules
- Preprocessing/macros/templating
- Source to source
- DSL embedding
- Compartmentalization of state (globals bad)
- More advanced type systems
- OO-ish systems
- Forms of data flow
- Message passing
- Functional style (including limiting mutability)
- Forms of control flow
- Frameworks providing more magic
- Calls for less magic and more explicit control flow
- Exception handling good
- Explicit errors better
- Event loops
...On the one hand, I really miss simply being able to use "Make" for builds (Damn you to HELL, Microsoft!).
On the other hand, I loathe the spam code that checked exceptions causes (alas MS/Anders/C# gets this right, and Java got it wrong)
On the other hand, I loathe the spam code that checked exceptions causes (alas MS/Anders/C# gets this right, and Java got it wrong)
I remember you writing something similar 4 years ago: https://news.ycombinator.com/item?id=5415585
It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.
I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.
I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.
So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.
It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.
I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.
I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.
So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.
Give me a break. The entire internet and software landscape is changing and everyone is in a constant rush to stay current. You make it seem like it's some kind of concerted effort to insult the sensibilities of good, proper software engineers who know the right way to do things.
Everyone is just trying to do the best they can with the incredibly complex stack of technologies in play today.
Everyone is just trying to do the best they can with the incredibly complex stack of technologies in play today.
"The entire internet and software landscape is changing"
Really? Is it Web 4.0 now?
People are changing the stack because they don't know any better and trying to justify their salary. That's the bottom line. The rush to stay current is just bandwagon-hype.
Really? Is it Web 4.0 now?
People are changing the stack because they don't know any better and trying to justify their salary. That's the bottom line. The rush to stay current is just bandwagon-hype.
I love you.
Not only are they doing that, but they are insanely arrogant about rejecting criticism that they're doing this too.
You just summed up "the largest, most active open source community that has ever existed" with "they" and suggested that "they" are all thinking the same thing with one mind.
That seems like a bit of a reach.
That seems like a bit of a reach.
With some of the comments around here being a demonstration of this very phenomenon. But then, “what I cannot build, I do not understand”. The kids may be rewriting the universe in JS, but hopefully they will learn something from it, too. When we did it, in the bad old days, it was Basic and Assembler. Those environments were about as shitty and unstable as JS is today, but otoh that may foster an appreciation for proper tools once you get your hands on them. It worked like that for me. And, besides, arrogance is the privilege of youth. It would be very strange indeed if we didn't encounter it in this space.
You don't drop an incendiary statement like that without at least citing an example of where that has been the case.
I'll admit, you got a laugh and a smirk out of me, but this still seems like an unfair statement.
The JS community at large isn't reinventing the wheel, just iterating on a wheel as it moves, if that makes sense.
The JS community at large isn't reinventing the wheel, just iterating on a wheel as it moves, if that makes sense.
It's wheels within wheels. Eat a mushroom.
You have to be careful with the GitHub stats. I have a few Python/Ruby projects that GitHub categorizes as JavaScript because I have a few 3rd party JavaScript dependencies that ended up being larger than my actual project.
These libraries were checked into Git because it was more convenient at the time and I hadn't set up a good build system, as they were non-critical side projects.
I know I'm not the only one who has done this in the past. I'd be curious to see GitHub stats that tried to account for this.
These libraries were checked into Git because it was more convenient at the time and I hadn't set up a good build system, as they were non-critical side projects.
I know I'm not the only one who has done this in the past. I'd be curious to see GitHub stats that tried to account for this.
[deleted]
It is not because something is larger that it is better.
These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.
I have nothing against JS in particular, but there is a bit too much hype about it.
These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.
I have nothing against JS in particular, but there is a bit too much hype about it.
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.
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.
Having been a programmer for the past 18 years, I can say that JavaScript definitely suffers from "rock star" syndrome. There are great people in every programming community... and JavaScript is no exception. But never have I seen a community so plagued by the conference speaker, twitter famous types. (The types that refer to people not in their perceived realm of popularity as "filthy randos") It's incredibly toxic. I want to scream, "we're all geeks, just like you. You are not really a rock-star!!! No one outside of this niche community even cares what you think about anything at all!!!" Today's novice programmers have potential to be tomorrow's great inventors. That's why I can extend an amazing amount of empathy for sloppy code, bad architecture, etc. The poison that you speak of has the image of the SV archetypical, studio dwelling, hip 22 year old. None of this is the fault of the language though... or OSS. I think you're correct in mentioning "hype".
Some ppl simply are rock stars. They are better than everyone else at the whole open-source lifecycle. They know how to do the marketing, manage scope, ship features, manage issues, etc.
To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.
To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.
Well, the thing is that in JS community there are tons of rock starts who basically do simple stuff (which was done 100 times before them), but only after their presentations it goes crazy. People retweet them, use as a credible source, etc. Also, there are a lot of people who are very opinionated and just push it and by this become famous in JS land.
Yeah, that's true, that they invest a lot of personal time in this stuff, and they do a very good job in balancing, but the problem is that people trust them in important questions like performance even despite the fact many of them don't know CS basics properly (like data structures, etc).
I don't want to say all of them are this way, there are some well-educated people who definitely know a lot and deserve all of this. But as it was mentioned earlier, a lot of them are just 22 years old hip guys who released something what became mainstream/were involved in it and became ambassadors.
Yeah, that's true, that they invest a lot of personal time in this stuff, and they do a very good job in balancing, but the problem is that people trust them in important questions like performance even despite the fact many of them don't know CS basics properly (like data structures, etc).
I don't want to say all of them are this way, there are some well-educated people who definitely know a lot and deserve all of this. But as it was mentioned earlier, a lot of them are just 22 years old hip guys who released something what became mainstream/were involved in it and became ambassadors.
> people trust them in important questions like performance
I think this is part of the tradeoff that they excel at. There is a huge difference between perfecting and optimizing vs. shipping and growing an ecosystem.
I think this is part of the tradeoff that they excel at. There is a huge difference between perfecting and optimizing vs. shipping and growing an ecosystem.
> I think rock stars earn their status.
I think that's mostly bunk. For every rockstar there's 100 equally talented individuals who will never get recognition because they were not in the right place at the right time.
Rockstars are incredibly lucky.
I think that's mostly bunk. For every rockstar there's 100 equally talented individuals who will never get recognition because they were not in the right place at the right time.
Rockstars are incredibly lucky.
And if Steve Jobs didn't build Apple, someone else would have.
As an outsider to the community, I see it as a pathology that there are people you are supposed to recognize outside of the language creator. Not that a culture is a bad thing but in a healthy technical community recognition should come from decades of hard work - not from a nice landing page and a framework of the week.
IMO, social media and blogosphere driven complex work cannot be deep, just confused.
IMO, social media and blogosphere driven complex work cannot be deep, just confused.
I think its democratic which is the best system we have.
Any kid with a new idea can have his ideas listened to. This means we don't get stuck.
Any kid with a new idea can have his ideas listened to. This means we don't get stuck.
Democracy is not about deep work, thorough understanding or the best architecture. It's about negotiating compromise in a situation where there is no shared goal. It works great for ruling countries where it's sluggishness and confusion is a feature and not a bug.
I would claim that any technical undertaking without understood goals using a process whose main design feature is not efficiency but sluggishness is a pathological one.
A computer system is far more simpler than any countrys political system - it's tractable and optimal solutions can be found. Unless, of course, unless the design process is lost in confusion and bafflement.
I would claim a place where any kid is listened to is precisely the one where everyone will get stuck. If people spend more time reading blogs rather than on CS basics they cannot understand a great ideas because they are on the Kruger-Dunning level of skill development.
I would claim that any technical undertaking without understood goals using a process whose main design feature is not efficiency but sluggishness is a pathological one.
A computer system is far more simpler than any countrys political system - it's tractable and optimal solutions can be found. Unless, of course, unless the design process is lost in confusion and bafflement.
I would claim a place where any kid is listened to is precisely the one where everyone will get stuck. If people spend more time reading blogs rather than on CS basics they cannot understand a great ideas because they are on the Kruger-Dunning level of skill development.
Yeah, I don't know about that. In my mind, the true rockstars are the people solving hard problems, e.g., kernel contributors, safety critical code, driverless vehicles, etc. I couldn't care less that you can quickly tape together 100 libraries and 7 frameworks to get the latest rendition of pets.com off the ground.
Making people who are incapable of kernel work, drivers work, writing safe critical code, etc. capable of being safe, secure, and highly productive, if only by glueing hip new libraries, is a rockstar task.
> They know how to do the marketing
This is the only necessary component of stardom.
When something is actually good, it'll retain its popularity.
This is the only necessary component of stardom.
When something is actually good, it'll retain its popularity.
> 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.
I'm not a huge fan of the "Javascript programmers are novices" myth. It's quite damaging.
Javascript is a kitchen-sink language these days in the ES6+ world. You've got the functional programming features... monads, functors, applicative and even immutable data structures are just a library. You have classes, interfaces, protocols and of course event-driven programming, prototypes, etc, etc, etc. It's not a small spec these days.
The point is that there are smart people who use the language to great effect. Enough with the "unwashed masses," story please.
Personally I'll take an ML or Lisp based language anyway... but thankfully I can have my cake and eat it too by compiling to Javascript.
I'm not a huge fan of the "Javascript programmers are novices" myth. It's quite damaging.
Javascript is a kitchen-sink language these days in the ES6+ world. You've got the functional programming features... monads, functors, applicative and even immutable data structures are just a library. You have classes, interfaces, protocols and of course event-driven programming, prototypes, etc, etc, etc. It's not a small spec these days.
The point is that there are smart people who use the language to great effect. Enough with the "unwashed masses," story please.
Personally I'll take an ML or Lisp based language anyway... but thankfully I can have my cake and eat it too by compiling to Javascript.
Nothing here disproves the claim you try to disprove. "There are smart people" - that's a given, but how does that disprove that the barrier is low, and the vast majority of less-to-none experienced developers choose JS these days?
I was tackling the blanket assertion that Javascript developers are novice programmers. It's understood that there are programmers of all skill levels who use Javascript. However statements like the aforementioned are dangerous when people just assume it must be true.
There are novice programmers and many of them choose Javascript is more accurate. The aforementioned assertion is used as a pejorative by programmers from other languages who think, perhaps rightfully so, that Javascript is inferior to their language of choice. That doesn't make Javascript programmers as a whole inferior despite what such a blanket statement implies.
There are novice programmers and many of them choose Javascript is more accurate. The aforementioned assertion is used as a pejorative by programmers from other languages who think, perhaps rightfully so, that Javascript is inferior to their language of choice. That doesn't make Javascript programmers as a whole inferior despite what such a blanket statement implies.
I think in general since the number of programmers grows, the majority must be novices, and the language growing most rapidly has relatively the largest amount of novices. I know it sounds like snobistry and not a statistical blanket statement, though.
"There are novice programmers and many of them choose Javascript is more accurate." - this is how I read the GP's comment.
My first "serious" programming language was JavaScript, and I didn't know a lot of basic stuff for a long time – because it is considered normal in JS community! Nowadays we have node.js, so you have to know at least a bit about your terminal, how to run server, kill processes and other everyday stuff, but back in the days it was unnecessary.
And this is not a single story; I've also interviewed some people and for some reason my experience is that JS has very low entry barrier.
Yes, with tail recursion we'll have almost full FP (only pattern matching is missing), but it doesn't mean that every novice will go and study them right after landing – in fact, the opposite, because there are much more tutorials about OOP JS.
And this is not a single story; I've also interviewed some people and for some reason my experience is that JS has very low entry barrier.
Yes, with tail recursion we'll have almost full FP (only pattern matching is missing), but it doesn't mean that every novice will go and study them right after landing – in fact, the opposite, because there are much more tutorials about OOP JS.
I'm uncomfortable with how willing I am (and others are) to just make/accept claims about how terrible the JS community is without evidence. In this thread there are tons of people saying JS devs don't understand CS fundamentals, write low quality code, and take their bearings from hype; that the "vast majority" of inexperienced people choose JS; etc. And I haven't seen any statistics on this or even a single example of such things.
I'm a Python guy who's working in Java at the moment. I don't particularly care for JS or frontend work, and I make no bones about it. But if someone were saying all this about the Python or Java communities, I'd be asking for evidence. And, frankly, I'd be pissed. So I think we should hold ourselves to similar standards -- don't just shit on a community because that's how you feel. Provide cases. And possibly even advice on how to improve!
I'm a Python guy who's working in Java at the moment. I don't particularly care for JS or frontend work, and I make no bones about it. But if someone were saying all this about the Python or Java communities, I'd be asking for evidence. And, frankly, I'd be pissed. So I think we should hold ourselves to similar standards -- don't just shit on a community because that's how you feel. Provide cases. And possibly even advice on how to improve!
Soon we'll have trouble hiring Angular 1 devs to maintain legacy code, like COBOL.
Except COBOL started in 1959, not 2009.
Except COBOL started in 1959, not 2009.
Angular 1.0, June 2012
https://github.com/angular/angular.js/releases?after=v1.0.4
...
And I actually prefer ng-1 to the transpiling mess that is ng-2, as well as preferring to use functional composition rather than pseudo-static classes for the controller logic.
https://github.com/roboprog/ang-prog-enh
https://github.com/angular/angular.js/releases?after=v1.0.4
...
And I actually prefer ng-1 to the transpiling mess that is ng-2, as well as preferring to use functional composition rather than pseudo-static classes for the controller logic.
https://github.com/roboprog/ang-prog-enh
50 years later and we still haven't learned.
It seems to me that many big companies are asking for Java + Angular skills these days; and that many new projects are build using that stack. This has the effect that it is still very worthwhile to learn Angular 1. I don't think it is going anywhere soon, plenty of companies are invested in it.
My hope is that with WebAssembly, it will stop mattering.
JS development will probably go on like if nothing changed, but people that don't like it will be able to opt-out.
JS development will probably go on like if nothing changed, but people that don't like it will be able to opt-out.
WebAssembly is a neater target format, but we can already compile to JavaScript today.
And several projects already are compiling to it. But it is not neat, what makes those projects less reliable and featurefull. Often enough for people to say "fuck it!" and go back to JS.
If WebAssembly takes too long, I can see JS compilers getting very good, but it's looming availability is discouraging that.
If WebAssembly takes too long, I can see JS compilers getting very good, but it's looming availability is discouraging that.
> Often enough for people to say "fuck it!" and go back to JS.
Because having an extra compile step or language to learn is inconvenient no matter what you target.
> If WebAssembly takes too long, I can see JS compilers getting very good, but it's looming availability is discouraging that.
I haven’t seen any of this.
Because having an extra compile step or language to learn is inconvenient no matter what you target.
> If WebAssembly takes too long, I can see JS compilers getting very good, but it's looming availability is discouraging that.
I haven’t seen any of this.
As someone who's working in that environment every day I cannot agree more.
often you have to dive into source code, and it is considered as normal, which is quite sick from my point of view.
For an environment that's as dynamic and open as Javascript, my POV is that one should be able to dive into library source code -- but that changes resulting from this should be an unusual circumstance, having to do with edge cases. If the normal situation is that you are always doing this, and it is always is flat-out basic debugging, then this is messed up.
The ability to dive into and debug everyone's source code should be considered a blessing. It's a great way to learn coding style and programming! It's one thing that was great about working in Smalltalk. However, the need to do so just to fix library bugs should be viewed as a symptom!
For an environment that's as dynamic and open as Javascript, my POV is that one should be able to dive into library source code -- but that changes resulting from this should be an unusual circumstance, having to do with edge cases. If the normal situation is that you are always doing this, and it is always is flat-out basic debugging, then this is messed up.
The ability to dive into and debug everyone's source code should be considered a blessing. It's a great way to learn coding style and programming! It's one thing that was great about working in Smalltalk. However, the need to do so just to fix library bugs should be viewed as a symptom!
Do you have more details on JS in microcontrollers? I'm curious about real-time systems, etc.
I found the Tessel (https://tessel.io/), but its hardly a microcontroller - its a MIPS SoC.
It looks like the Espurino is more of a traditional microcontroller. But the unit cost is high - $40!
Is anyone using JS on a microcontroller in a high volume product?
I found the Tessel (https://tessel.io/), but its hardly a microcontroller - its a MIPS SoC.
It looks like the Espurino is more of a traditional microcontroller. But the unit cost is high - $40!
Is anyone using JS on a microcontroller in a high volume product?
I saw pretty interesting stuff with Johnny-five.
http://johnny-five.io/
http://johnny-five.io/
Not sure it's low enough for volume project , but the closest today is espruino js on esp8266 ($2 wifi MCU) , or its brother , the esp32.
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.
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.
On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw.
And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.
And we have async/await too now, which means async code can also look almost the same as sync code. So I would still choose JS over both Python and Go (at least for that particular use case). mypy still has long ways to go before its anywhere near TS or Flow.
Ive never put the words together, but you've basically highlighted what I want:
Python (and its type system) + Go routines
Where can I find that!?
Python (and its type system) + Go routines
Where can I find that!?
TypeScript?
Python has async/await now too (and it's considerably nicer than JS's version).
mypy is immature compared to TypeScript and Flow.
In theory, python is better (mypy, pypy, async/await). In practice most libs don't use asyncio (in node everything does and can be auto-promisified), can't run on pypy (in node everything runs with the fast JIT optimizing things) and the typechecker is not mature enough to express most things (unlike TS/Flow).
In theory, python is better (mypy, pypy, async/await). In practice most libs don't use asyncio (in node everything does and can be auto-promisified), can't run on pypy (in node everything runs with the fast JIT optimizing things) and the typechecker is not mature enough to express most things (unlike TS/Flow).
Your QA engineer could use a framework like CodeceptJS (http://codecept.io/) and get back the "sync behavior", mostly.
If the app you're testing is messy, some of the test code will have to be injected into the browser by webdriver (so obligatory Javascript, and oblygatory async for getting the results back...) and some (hopefully most!) will run outside, in the test-runner, so JS ends to be the only sane option if you don't want to write "Python with strings of JS sprinkled around".
Also, webdriver itself is a mess with a horrible API forcefully riding another bigger mess (the browser adapters and browser itself), riding a top another mess (your app, however non-messy you imagine it to be, it's still a soup of crap running though the bowels of the browser)... so no "clean" solution here even if you're using Python.
Probably the way out of "webdriver testing hell" is to use a frontend framework with good testing support and write good front-end unit-tests: but they will obviously be Javascript :)
If the app you're testing is messy, some of the test code will have to be injected into the browser by webdriver (so obligatory Javascript, and oblygatory async for getting the results back...) and some (hopefully most!) will run outside, in the test-runner, so JS ends to be the only sane option if you don't want to write "Python with strings of JS sprinkled around".
Also, webdriver itself is a mess with a horrible API forcefully riding another bigger mess (the browser adapters and browser itself), riding a top another mess (your app, however non-messy you imagine it to be, it's still a soup of crap running though the bowels of the browser)... so no "clean" solution here even if you're using Python.
Probably the way out of "webdriver testing hell" is to use a frontend framework with good testing support and write good front-end unit-tests: but they will obviously be Javascript :)
I made a shell WebDriver tool that makes it really easy to script the browser from the comfort of your command line.
It's not fully polished yet, especially error reporting is a bit ugly, but it works and supports most of the WebDriver API.
https://github.com/mbrock/wd
I'm using it more for automation than testing but it could definitely be used for QA.
It's not fully polished yet, especially error reporting is a bit ugly, but it works and supports most of the WebDriver API.
https://github.com/mbrock/wd
I'm using it more for automation than testing but it could definitely be used for QA.
That explains why lots of libraries get written, but not why they get used.
the lack of a good standard library might have something to do with it.
I'll admit im not sure.
I'll admit im not sure.
The shaming of mature libraries doesn't help either. Try showing off something with jQuery these days.
Yeah. I've just taken to ignoring those responses.
As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit.
Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself.
(Still hate jquery's inconsistent ajax callback signatures. sigh.)
As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit.
Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself.
(Still hate jquery's inconsistent ajax callback signatures. sigh.)
I have been using Ramdajs, rather than lodash, but they both do about the same thing. One difference is that Ramda puts the functions before the data in its library calls, so that you can curry/apply the app logic function (e.g. - perhaps for a map or filter), save the resulting function and use it elsewhere.
Lodash looks nice, though, in that its partial function application mechanisms seem a bit more flexible than curry (only) - e.g. - I want to make a function with 0-arity, and bind it to an event handler, which Ramda won't do.
Lodash looks nice, though, in that its partial function application mechanisms seem a bit more flexible than curry (only) - e.g. - I want to make a function with 0-arity, and bind it to an event handler, which Ramda won't do.
lodash has that ability from a sub-module "lodash/fp":
https://github.com/lodash/lodash/wiki/FP-Guide
https://github.com/lodash/lodash/wiki/FP-Guide
Thanks. I wonder if somebody has a good comparison of the Lodash vs Ramda written up. Probably, but I haven't done the google and evaluation yet :-(
I honestly can't say I've seen any true jQuery shaming exclusive of the cherry-picked click-bait blogs. The only "shaming" I hear is typically post-interview justifications as to why someone wasn't hired, as if it might not simply be the possibility that someone else was more qualified.
Do you have evidence that jQuery is shamed because it is mature? I've always seen jQuery not chosen (shamed doesn't seem like the right word) because it doesn't provide the level of abstraction that folks are looking for, and because it mainly papers over cross-browser differences which get smaller every year.
> default async is a terrible setting
Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.
Haskell's version of "everything is async" works wonderfully. It's JavaScript that is bad, not the concept.
False. There is async/await, or generators. Its ES5 that is bad, not JavaScript.
Just a minor off topic correction, since you made the mistake twice: "squeue" is actually "skew".
Thanks! I forgot to require the spellcheck module ;).
> 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.
But probably not for your qa engineer who most likely already (and possibly only) knows javascript.
Who needs more than one language?
One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT?
SINGLE STACK!! /s
One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT?
SINGLE STACK!! /s
They (kind of) have a point though. I agree you should aim to be polyglot, but a particular project may not afford the learning curve if the dev doesn't already know the best stack.
For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time.
EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.
For example, I'm working (part time) on a relatively simple backend server for a nonprofit with a tiny budget and short deadlines. I know I can do it cheap and fast in Python, and it will work "ok". Go would be better, and I'd like to learn it, but I'm uncertain I could pull it off in time.
EDIT: Then again, it looks like I could realistically learn enough Go for this project in a weekend. Only problem is there could be data analysis, I know good libs in Python, don't know how hard that would be in Go.
Well, it's certainly not something that needs to be avoided at all costs but in the long term it can be less efficient and more costly.
It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.
It depends really, there is no single true language (except LISP) to solve all problems in the entire stack.
[deleted]
All hail LISP.
My main problem with LISP is that I stopped liking Python after learning it.
My main problem with LISP is that I stopped liking Python after learning it.
QA? Do it in Perl please!
[deleted]
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.
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.
Or if they use Debian. Evergreen isn't evergreen if it's on Linux.
Meh. Desktop users should all use a rolling release distro anyway. I'll never understand the point of versioned distros for desktop...
People like stability.
I never had any problems running archlinux for 3 years now. Im sure there are other rolling release distro that are more stable.
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.
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.
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.
hundred percent agree with this. A standard lib bundled with all browsers would solve so much of the framework madness.
Not saying it's well architected, but the standard (and experimental) suite of types and events in JavaScript on modern browsers is comprehensive!
https://developer.mozilla.org/en-US/docs/Web/API
https://developer.mozilla.org/en-US/docs/Web/API
Especially since Javascript needs it MOST, since we have to transmit it on the wire...
It's not necessary to have a single person in charge, but it helps to have a single entity that can push changes through. Mozilla added a lot of features that never went anywhere because IE lacked them. The W3C never standardized JavaScript, but eventually ECMA did. The stagnation was caused by competitive factors between browsers and standardization didn't change that.
Chronology: when I was at Netscape and still (apart from part-time help) the only person working on JS and the DOM and the rest of the browser embedding, we took JS to ECMA (now Ecma) in 1996. It was never brought to the W3C.
The IE stagnation came later, after IE4 which was innovative (because Microsoft wanted to embrace/extend/extinguish Netscape and the Web).
Almost everything we added to JS at Mozilla made its way into standards. Examples range from __proto__ to generators in ES6.
The IE stagnation came later, after IE4 which was innovative (because Microsoft wanted to embrace/extend/extinguish Netscape and the Web).
Almost everything we added to JS at Mozilla made its way into standards. Examples range from __proto__ to generators in ES6.
Thanks for the clarification!
[deleted]
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.
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.
Every time I see this argument I have the same response -- we tried this. We came really close to having Java be the standard and it failed for a ton of reasons (security was incredibly difficult, absurd slowness, UI/UX problems, user adoption issues, etc). What makes you confident we could get it right the second time?
Yes, you have an excellent point, and I worry about that. It also worries me that what I am proposing is pretty much what Flash did, I think, and we all hate that. I think we can do better because we know what we need now, and we have some good and bad examples to guide us. The problem with the JVM is that it is too heavyweight. But we know that lightweight is possible because everyone loves Lua.
Security is doable because BrowserVM does not need to do everything. It isn't generable purpose like the JVM, it is an embedded VM like Lua. Lua has great security, as far as I am aware. I expect that having a secure VM is no more difficult than having a secure ECMAScript implementation.
I think we want low-level execution primitives (i.e. assembly), which pretty much forces a VM, because it gives people flexibility to use whatever language they want. However, even the minimum of keeping JavaScript and having the page be a large canvas with (fast) drawing primitives would sufficient. Writing windowing systems and UI toolkits is a solved problem. I think the browser should, at minimum, provide primitives for drawing widgets, so that webapps can take advantage of OS-native widgets. A well-designed toolkit, though, would be handy. And here we have a number of examples. Qt is very well-designed and a pleasure to use. Cocoa is a little clunky, but effective. Even Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a mess. In particular, a constraints-style system seems to be clunky. It was clunky in Motif, clunky in Android, and even Apple's version doesn't seem all that great. Constraints seems to suffer from the same problem of HTML: describing the system is clunkier than just telling the system what to do. Hence, Qt and Swing's layouts are a lot easier to reason about.
Security is doable because BrowserVM does not need to do everything. It isn't generable purpose like the JVM, it is an embedded VM like Lua. Lua has great security, as far as I am aware. I expect that having a secure VM is no more difficult than having a secure ECMAScript implementation.
I think we want low-level execution primitives (i.e. assembly), which pretty much forces a VM, because it gives people flexibility to use whatever language they want. However, even the minimum of keeping JavaScript and having the page be a large canvas with (fast) drawing primitives would sufficient. Writing windowing systems and UI toolkits is a solved problem. I think the browser should, at minimum, provide primitives for drawing widgets, so that webapps can take advantage of OS-native widgets. A well-designed toolkit, though, would be handy. And here we have a number of examples. Qt is very well-designed and a pleasure to use. Cocoa is a little clunky, but effective. Even Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a mess. In particular, a constraints-style system seems to be clunky. It was clunky in Motif, clunky in Android, and even Apple's version doesn't seem all that great. Constraints seems to suffer from the same problem of HTML: describing the system is clunkier than just telling the system what to do. Hence, Qt and Swing's layouts are a lot easier to reason about.
Finally, someone gets it. Thank you!
> First, the language was not designed to do what people are trying to use it for
Against this point: Few languages are used for what they were designed for. Java was designed as a control language for "smart" TVs. PHP was designed for making personal homepages a little bit reactive. JS was designed for making client side pages dynamic.
And now all three are being used as server software.
Against this point: Few languages are used for what they were designed for. Java was designed as a control language for "smart" TVs. PHP was designed for making personal homepages a little bit reactive. JS was designed for making client side pages dynamic.
And now all three are being used as server software.
> 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?
To be fair, a lot of languages compile to Javascript. Do we really need a second standard?
It's coming regardless: https://en.wikipedia.org/wiki/WebAssembly
> provide well-thought out input and drawing primitives
This sounds like a cool idea! What primitives would you suggest?
This sounds like a cool idea! What primitives would you suggest?
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.
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.
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?!?"
Plenty of people (including me) took one or two looks at RoR and dismissed it, too. I don't think it was the slam-dunk you're making it out to be. React seems to be doing pretty well these days, but it is too soon to say if it is going to dominate the field.
On the contrary; Rails was a massive innovation because it proved that opinionated, reasonable defaults ("convention over configuration") is how most people actually want to write software. For a CRUD app, Rails was a shining beacon of light, because it allowed you to crank one out in mere hours, instead of days of fiddling with repetitive glue code that you would've had to write instead in literally any other web framework of your choice. It meant average coders could be productive instead of overwhelmed, and competent coders could move on to different projects faster.
The GP post has a point. Almost every MV* JS framework starts from scratch because they all believe their slight variation of the paradigm is better than everyone else's, but the greater scheme of things they are more similar than different. When one comes out with a framework that in earnest changes how JS development is done -- and achieves some staying power -- things will be different from the myriad of near-equivalent-but-totally-incompatible choices.
The GP post has a point. Almost every MV* JS framework starts from scratch because they all believe their slight variation of the paradigm is better than everyone else's, but the greater scheme of things they are more similar than different. When one comes out with a framework that in earnest changes how JS development is done -- and achieves some staying power -- things will be different from the myriad of near-equivalent-but-totally-incompatible choices.
> how most people actually want to write software.
[citation needed]
Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light.
JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you just aren't familiar with what's out there.
[citation needed]
Honestly, Rails wasn't the first or last RAD platform and I don't think a randomly-selected subset of programmers who have used it would describe it as a shining beacon of light.
JS frameworks are actually pretty diverse, and if you think the ecosystem is a bunch of MV* variants just waiting for something innovative to come along, with respect, you just aren't familiar with what's out there.
Can you tell something about your favourite alternative to RoR way?
> [citation needed]
Okay. The year is 2005. PHP5 was fresh out of the oven and most people were still on PHP4. From PHP's point of view, there's rumors of something happening in the Ruby community that will be big, and should be talked about [1].
Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on the announcement you can gauge the contemporary reaction; comments detail the fact that Rails was breath of fresh air from the configuration-heavy Java frameworks of the day -- represented by Struts [3], but others weren't much different in this regard, as these books from 2002 and 2004 about alternatives to Struts show [4][5]. Several ASP developers, detail their positive experiences in switching their web development to Rails [6][7][8]. The PHP world is forever changed -- by 2006, frameworks inspired by Rails abound [9]. "Ruby on Rails" becomes a popular phrase, some frameworks borrow the naming scheme along with the ideas: "Groovy on Grails" [10] tries to bring Rails' ideas to the Java world, "PHP on Trax" (formerly "PHP on Rails" [9]), "ColdFusion on Wheels" [11].
I'd say Rails made quite the splash.
[1] https://blog.phpdeveloper.org/2005/12/31/25/ [2] https://developers.slashdot.org/story/05/12/14/0034219/ruby-... [3] http://weblog.rubyonrails.org/2005/2/22/comparing-struts-to-... [4] https://www.safaribooksonline.com/library/view/programming-j... [5] https://www.safaribooksonline.com/library/view/programming-j... [6] http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-ana... [7] http://weblog.rubyonrails.org/2005/12/20/neters-tell-scoble-... [8] http://weblog.rubyonrails.org/2005/7/5/not-knowing-where-it-... [9] https://h3rald.com/articles/rails-inspired-php-frameworks/ [10] http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-mo... [11] http://cfwheels.org/blog/how-oo-almost-destroyed-business/
Okay. The year is 2005. PHP5 was fresh out of the oven and most people were still on PHP4. From PHP's point of view, there's rumors of something happening in the Ruby community that will be big, and should be talked about [1].
Then Rails 1.0 drops at the end of the year. From this Slashdot thread [2] on the announcement you can gauge the contemporary reaction; comments detail the fact that Rails was breath of fresh air from the configuration-heavy Java frameworks of the day -- represented by Struts [3], but others weren't much different in this regard, as these books from 2002 and 2004 about alternatives to Struts show [4][5]. Several ASP developers, detail their positive experiences in switching their web development to Rails [6][7][8]. The PHP world is forever changed -- by 2006, frameworks inspired by Rails abound [9]. "Ruby on Rails" becomes a popular phrase, some frameworks borrow the naming scheme along with the ideas: "Groovy on Grails" [10] tries to bring Rails' ideas to the Java world, "PHP on Trax" (formerly "PHP on Rails" [9]), "ColdFusion on Wheels" [11].
I'd say Rails made quite the splash.
[1] https://blog.phpdeveloper.org/2005/12/31/25/ [2] https://developers.slashdot.org/story/05/12/14/0034219/ruby-... [3] http://weblog.rubyonrails.org/2005/2/22/comparing-struts-to-... [4] https://www.safaribooksonline.com/library/view/programming-j... [5] https://www.safaribooksonline.com/library/view/programming-j... [6] http://weblog.rubyonrails.org/2005/6/28/asp-net-vs-rails-ana... [7] http://weblog.rubyonrails.org/2005/12/20/neters-tell-scoble-... [8] http://weblog.rubyonrails.org/2005/7/5/not-knowing-where-it-... [9] https://h3rald.com/articles/rails-inspired-php-frameworks/ [10] http://grails.1312388.n4.nabble.com/Groovy-on-Rails-is-no-mo... [11] http://cfwheels.org/blog/how-oo-almost-destroyed-business/
> Groovy on Grails
The source you quote says "Groovy on Rails", which was the official name until it was contracted to "Grails" due to the insistence of the Rails crowd that "on Rails" not be used in any other product names. The "Groovy on Grails" phrase you wrote was a later unofficial but intended mispronunciation of the earlier name put out by the Grails crowd to make it sound like "Ruby on Rails" as a snipe at the Rails crowd. To those of us who thought Groovy would make a good language outside of its use in Grails, the mispronunciation made it sound like someone in the Grails crowd thought Groovy's only use was for scripting Grails.
The source you quote says "Groovy on Rails", which was the official name until it was contracted to "Grails" due to the insistence of the Rails crowd that "on Rails" not be used in any other product names. The "Groovy on Grails" phrase you wrote was a later unofficial but intended mispronunciation of the earlier name put out by the Grails crowd to make it sound like "Ruby on Rails" as a snipe at the Rails crowd. To those of us who thought Groovy would make a good language outside of its use in Grails, the mispronunciation made it sound like someone in the Grails crowd thought Groovy's only use was for scripting Grails.
I think we disagree on two points. First, I don't think the influence of RoR was as sweeping as you do. This is probably just a difference in perspective or preference.
Second, regardless of that, I think the JS ecosystem is well-enough explored that the chances that some single new idea or platform is going to dramatically change everything doesn't seem very likely to me. For reasons I've mentioned in my top-level comment on this page, I think diversity of the JS ecosystem is going to be with us for a while.
Second, regardless of that, I think the JS ecosystem is well-enough explored that the chances that some single new idea or platform is going to dramatically change everything doesn't seem very likely to me. For reasons I've mentioned in my top-level comment on this page, I think diversity of the JS ecosystem is going to be with us for a while.
> 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/
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/
I think a lot of that has to do with the language changes that came about with ES2015. Before, we were basically stuck with ES5 and ES3, which aren't that great to work with and limited what you could do (easily, at least).
The stuff coming down the pipe (mainly modules, but a lot of ES2017) is really going to get the language to the level where it's going to be natively capable of even supporting a framework on the level of Rails.
The stuff coming down the pipe (mainly modules, but a lot of ES2017) is really going to get the language to the level where it's going to be natively capable of even supporting a framework on the level of Rails.
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.
The trouble is that it's very difficult for a single tool to meet the use cases of everyone who uses JS.
How about Sails? It's pretty damn good for Javascript as a Rails alternative, even uses some of the same context.
...the whole Sails thing is currently a hot mess. At least one core contributor has bailed and moved on to Trails.js. Accusations of incompetence, malfeasance, character assassination, etc., abound.
As far as I know (GitHub is down, cannot confirm) Sails is still running Express 3 (the maintainers are supposedly upgrading to 5), has a variety of other major issues with respect to its ORM, Waterline, and is a bit lacking on the "contemporary best practices" front. Long story short, it's broadly (perhaps unfairly, perhaps not) considered dead or dying.
There aren't any viable Rails alternatives for Node. (Flask, Sinatra, on the other hand? — sure. You'll have no trouble finding a good micro-framework.)
ThinkJS, Adonis and Strapi are the only entries I've seen in the Rails/Laravel/Django space, but they all have problems too -- to wit, ThinkJS recommended hashing passwords with MD5 (!!!) on their front page until quite recently, Adonis is aggressively NIH, and Strapi uses Waterline, which is (by many accounts) bad at just about everything.
There's also Nodal, which I've heard good things about, but it's limited to APIs with Postgres.
https://news.ycombinator.com/item?id=10821986
http://thinkjs.org http://adonisjs.com http://strapi.io http://nodaljs.com
As far as I know (GitHub is down, cannot confirm) Sails is still running Express 3 (the maintainers are supposedly upgrading to 5), has a variety of other major issues with respect to its ORM, Waterline, and is a bit lacking on the "contemporary best practices" front. Long story short, it's broadly (perhaps unfairly, perhaps not) considered dead or dying.
There aren't any viable Rails alternatives for Node. (Flask, Sinatra, on the other hand? — sure. You'll have no trouble finding a good micro-framework.)
ThinkJS, Adonis and Strapi are the only entries I've seen in the Rails/Laravel/Django space, but they all have problems too -- to wit, ThinkJS recommended hashing passwords with MD5 (!!!) on their front page until quite recently, Adonis is aggressively NIH, and Strapi uses Waterline, which is (by many accounts) bad at just about everything.
There's also Nodal, which I've heard good things about, but it's limited to APIs with Postgres.
https://news.ycombinator.com/item?id=10821986
http://thinkjs.org http://adonisjs.com http://strapi.io http://nodaljs.com
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
This is natural the world isn't ending
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
This is natural the world isn't ending
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.
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.
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.
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.
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!
"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!
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.
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.
I wonder how much of that shift is also just perception within a certain bubble/echo chamber, though. There's certainly a trend in online forums and startups to ask applicants for their GH profile, but I suspect this is one of those things that some employers are doing because they think everyone else is. Are those employers really then reviewing all of those profiles to see which include projects where an applicant really made a meaningful contribution and which are just token updates or yet another ad hoc, informally-specified, bug-ridden, slow implementation of half of someone else's popular and established work?
The only thing I know for sure about that sort of policy is that it would immediately rule out most of the best developers I've ever worked with. Most of those people are busy building working projects for their businesses/clients/employers during work hours, and then having a life at other times. Some do contribute back to OSS projects or help answering questions on online forums as well, but not as a resume-building exercise, and it's rarely where you'll find the best indications of what they are capable of building.
I wonder how much of that shift is also just perception within a certain bubble/echo chamber, though. There's certainly a trend in online forums and startups to ask applicants for their GH profile, but I suspect this is one of those things that some employers are doing because they think everyone else is. Are those employers really then reviewing all of those profiles to see which include projects where an applicant really made a meaningful contribution and which are just token updates or yet another ad hoc, informally-specified, bug-ridden, slow implementation of half of someone else's popular and established work?
The only thing I know for sure about that sort of policy is that it would immediately rule out most of the best developers I've ever worked with. Most of those people are busy building working projects for their businesses/clients/employers during work hours, and then having a life at other times. Some do contribute back to OSS projects or help answering questions on online forums as well, but not as a resume-building exercise, and it's rarely where you'll find the best indications of what they are capable of building.
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.
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.
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.
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.
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.
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.
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.
> 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
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
Actually, ES2015=ES6, ES2016=ES7, which was released earlier this year. Most people mess that up due to the combination of unfortunate naming and the fact that ES7 wasn't nearly as big of a jump as ES6 was.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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_abo...
[2] https://i.imgur.com/5rJH3co.png
[3] https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19...
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_abo...
[2] https://i.imgur.com/5rJH3co.png
[3] https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19...
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).
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).
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.
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.
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
[2] https://facebook.github.io/react/docs/tutorial.html
[1] https://github.com/facebookincubator/create-react-app
[2] https://facebook.github.io/react/docs/tutorial.html
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.
A lot of smart engineering teams seem to be picking up Node recently. Airbnb and Netflix are two interesting examples.
https://github.com/airbnb/hypernova
http://thenewstack.io/netflix-uses-node-js-power-user-interf...
https://github.com/airbnb/hypernova
http://thenewstack.io/netflix-uses-node-js-power-user-interf...
Mind sharing why you consider node.js and other server-side javascript tools irrational?
Unless your project is small (like under 10-20k lines), why use node when you can use a typed language? Javascript is a mess and if I'm server side and using something dynamic, I might as well use something nicer like ruby or python.
> if I'm server side and using something dynamic, I might as well
> use something nicer like ruby or python.
The code is pretty much identical between Ruby, Python, and Javascript once you have a yield/await abstraction in the latter.
Types are low level. JavaScript is very high on the stack, and has no concept of types, it only has "value objects" (variable values: string and number, plus static values: true, false, null, undefined) and "normal objects" (Array, Object, Date, Function, etc). There's a debate though on what type should be used for numeric values in JavaScript.
In JavaScript you rarely see getters and setters, as you do not need any abstraction over the type system, although it is possible to do bitwise operations, so if you want to you could make your own types, although you will not have full control of their binary representation, witch you would need a "real" programming language with a proper type system, but I've only seen that in optimization witch rarely runs faster then native JS. You get a lot of productivity by not having to worry about types in JS, and you rarely se buffer overflows witch is common in lower level languages such as C and C++. JavaScript is an an abstraction where you do not have to worry about the under-layer like imperative memory management. If you have to decide between small int vs big int vs floats, it's a leaky abstraction. JavaScript is one level above that.
You seem to assume that
A) Types are low level
B) C++ and C are the only competition to JavaScript
C) Not having to worry about types makes you faster or in any way better
A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case)
B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary.
Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel!
C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/
Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types.
IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid.
I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
A) Types are low level
B) C++ and C are the only competition to JavaScript
C) Not having to worry about types makes you faster or in any way better
A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case)
B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary.
Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel!
C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/
Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types.
IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid.
I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...)
Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does generating stupid cluttered code)
We have bigger problems (not that JS really addresses them, either).
Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly.
Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained.
Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)
Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does generating stupid cluttered code)
We have bigger problems (not that JS really addresses them, either).
Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly.
Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained.
Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)
Type inference is horrible. Mostly because as soon as your project gets large, type inference eats inordinate amounts of time during compiling and indexing and developer experience degrades. Combine that with operator overloading and generics and it gets even worse. Right now I'm suffering through it with swift with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x faster.
If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language.
Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!
If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language.
Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!
Operator overloading is doubly evil :-)
FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)
FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)
I mostly agree, types are nice but they should not clutter code like in C++ or C.
If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go.
For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out.
Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out.
Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented.
Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.
If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go.
For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out.
Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out.
Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented.
Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.
SQL is also a leaky abstraction, it would be much more simple if the database could just take any value and store it optimally. But at least you do not have to write:
My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
SELECT *string* foo, *string* bar FROM banana A INNER JOIN beer B ON *int* B.id = *int* A.id
My problem with Go and other languages is that you have to be verbose like str = string = "string"; Where the compiler could probably figure out it's a string because of the quotes. And use a default numeric type when dealing with numbers. A compiled language also has the advantage that the compiler can thoroughly analyze the program, optimize and chose the optimal types if they are not explicitly set. My biggest issue though is the inferior module system compared to NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
I'm aware that an imperative low level language that can talk directly to the hardware will beat NodeJS and JavaScript in performance. But for the most part I'm willing to sacrifice that for increased productivity and simplicity. What do you think about languages that compile to JavaScript ? And do you think adding types to JavaScript would make it more simple ?
>it would be much more simple if the database could just take any value and store it optimally
Which completely misses the point, this is called a file system btw, but a SQL Databases is designed from the ground up to have a validation schema.
You simply cannot put data in a SQL database that is not conform to the schema on which the table is defined. You can't simply put a string into an int column but this also means that any data you may read from this column will always be an int no matter what.
It means that if your transaction completes, including large scale database upgrades, at no point where types violated and you can be sure that all data is valid (or deleted because you forgot the WHERE clause)
>In ES6 you can now go very low level and deal with raw bit buffers.
I doubt you can write to registers and manipulate memory allocation, that is actually low level.
Manipulating bits is something every turing machine emulator can do.
>My problem with Go and other languages is that you have to be verbose like str = string = "string";
Which shows me that you haven't bothered to actually look into any statically typed language because I know of no common language that uses this syntax.
Go actually infers the type if possible, you simply write `str := "string"` or `var str = "string"` and go will use the correct type.
You can do this even with complex objects no problem. You only need to define the type if it's non-obvious, like you want to use an interface but the assignment uses the raw type, but this is something now compiler can do (it would be guess work)
Furthermore, there is no sacrifice in productivity, actually the opposite.
You don't have to wonder if the parameters you receive will have the correct type. If your function signature is `func (int) int` you can only ever receive an integer and you can only ever return an integer.
>NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
Go actually has a very neat module system. It's rather simple; all uppercase fields and funcs are exported, everything else is private.
The architecture of the standard library in Go and the language itself discourage globals and encourage default global states which can be exchanged for user defined states seamlessly.
Check out logrus or any of the popular logging frameworks in go. You can either use the default logger which is globally exposed or you use a custom one and pass the variable.
>I'm willing to sacrifice that for increased productivity and simplicity.
If simplicity and productivity is your goal you should use one of the LISP variants like ClojureScript. Nothing beats a language which you can program to be more efficient for you.
And you probably should check out some Go code too, it's easy to understand even without knowledge of the language as long as you know some basic CS101 stuff.
Which completely misses the point, this is called a file system btw, but a SQL Databases is designed from the ground up to have a validation schema.
You simply cannot put data in a SQL database that is not conform to the schema on which the table is defined. You can't simply put a string into an int column but this also means that any data you may read from this column will always be an int no matter what.
It means that if your transaction completes, including large scale database upgrades, at no point where types violated and you can be sure that all data is valid (or deleted because you forgot the WHERE clause)
>In ES6 you can now go very low level and deal with raw bit buffers.
I doubt you can write to registers and manipulate memory allocation, that is actually low level.
Manipulating bits is something every turing machine emulator can do.
>My problem with Go and other languages is that you have to be verbose like str = string = "string";
Which shows me that you haven't bothered to actually look into any statically typed language because I know of no common language that uses this syntax.
Go actually infers the type if possible, you simply write `str := "string"` or `var str = "string"` and go will use the correct type.
You can do this even with complex objects no problem. You only need to define the type if it's non-obvious, like you want to use an interface but the assignment uses the raw type, but this is something now compiler can do (it would be guess work)
Furthermore, there is no sacrifice in productivity, actually the opposite.
You don't have to wonder if the parameters you receive will have the correct type. If your function signature is `func (int) int` you can only ever receive an integer and you can only ever return an integer.
>NodeJS (commonJS) module system that makes it possible to not write complexed code, because it's lexically scoped and do not have hidden globals.
Go actually has a very neat module system. It's rather simple; all uppercase fields and funcs are exported, everything else is private.
The architecture of the standard library in Go and the language itself discourage globals and encourage default global states which can be exchanged for user defined states seamlessly.
Check out logrus or any of the popular logging frameworks in go. You can either use the default logger which is globally exposed or you use a custom one and pass the variable.
>I'm willing to sacrifice that for increased productivity and simplicity.
If simplicity and productivity is your goal you should use one of the LISP variants like ClojureScript. Nothing beats a language which you can program to be more efficient for you.
And you probably should check out some Go code too, it's easy to understand even without knowledge of the language as long as you know some basic CS101 stuff.
> without having to think about threads or synchronization. Just pipe data through the channel!
I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.
True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked.
Which means well-designed services will remain available even if only with degraded performance.
Which means well-designed services will remain available even if only with degraded performance.
I didn't know go can do deadlock detection. Thanks for this, I learned something new today.
it's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything.
If all go routines are deadlocked, the runtime will terminate the service.
It's a kind of graceful and somewhat safe degradation.
If all go routines are deadlocked, the runtime will terminate the service.
It's a kind of graceful and somewhat safe degradation.
[deleted]
Why use an OOP language when you can use an FP one?
I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity.
Async I/O is clumsy on the server side, though.
I must have missed the memo that proved that Java / C# / C++ / Simula 67 are the one true path to productivity.
Async I/O is clumsy on the server side, though.
FP can still have types, like haskell. Typing is independent of OOP vs FP
Sorry. Generally, when I hear people complain about the lack of "types" in a dynamic language, I'm pretty sure what they mean is [static] "classes", so that "intellisense" (auto-complete, for non-MS/VS-bubble-land) works.
Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately.
Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster)
YMMV.
Then next, a hair-brained XML configuration scheme (with reflection) will be used to work around the inevitable deficiencies, which an IDE plug-in may or may not parse accurately.
Tragedy ensues. (Or hilarity, if I get to stand back while somebody else has to support the monster)
YMMV.
Because you have the option of using first-class, enterprise-ready languages like C# and Java
Because when asked if (9999999999999999 == 10000000000000000), they return true.
This is why types are nice.
In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float.
In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type.
Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.
In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float.
In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type.
Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.
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).
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).
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.
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.
Programming languages in general hide the limitations of machine code under the rug.
Regarding performance, why don't we write our web applications in C++, Rust or Go?
There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS).
If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.
Regarding performance, why don't we write our web applications in C++, Rust or Go?
There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS).
If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.
Because there are and always have been better options.
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.
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.
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.
Lots of people with little experience contribute, which is great, but "the ecosystem" is largely built by people with plenty of experience and training.
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 :)
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 :)
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/
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/
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.
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.
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.
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.
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.
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!
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!
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.
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.
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.
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.
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.
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.
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.
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.
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)
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)
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?
Scala.js is an attempt at this
See WebAssembly
Can't wait, I may actually switch to front end development when there are WA backend(s) for a language/languages I like.
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.
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.
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.
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.
I touch on it a little bit here:
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)
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)
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.
However, moving fast does percolate down from the top. Look at Node.js and how often they release new versions.
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.
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.
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.
> 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.
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.
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.
http://hotframeworks.com/
Skip the chart, look at the long tail of listings.
Skip the chart, look at the long tail of listings.
It doesn't have React. Is this an oversight or does it not count as framework in their definition?
Is there any existing tool to interrogate a codebase for adequacy for a set of tasks? Ie. PageRank/'citations' for frameworks?
Should there be?
Should there be?
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.
...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.
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 ?
It's always on. Anyone from anywhere can interact with what you create instantly. What else is like that ?
Why didn't the Dart VM make it into Chrome?
Because nowdays js has so many use cases
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]
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]
because it blows.
we need a full IDE, Language, Library combo for better development.
we need a full IDE, Language, Library combo for better development.
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
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
we just need it to be as easy as xcode
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.
- 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.
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.
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.
"post-" usually means after, so I initially thought you were saying the internet is over. Maybe you could say "internet native" or something. I don't think it's true, by the way (the CPAN folks would have a word with you, just to mention one that comes to mind).
In response to your point, eventually, most of us who build software just want to use tools we know to get things done. There's a tremendous benefit to having few and highly trusted dependencies. Imagine civil engineering if every week there was a new flavor of concrete with different construction methods and structural properties.
Not too many people with a decade or more of development experience think that "downloading other people's random packages" is a fantastic or a confidence-inspiring idea. Ideally, those line-of-business CRUD apps that the modern world runs on should be write-and-forget, not rewritten continuously. This is why "churn" is a bad word to some. And yes, writing CRUD apps is pretty much solved, that is, it hasn't gotten that much more efficient in the last ten years if you look at the best tools.
In response to your point, eventually, most of us who build software just want to use tools we know to get things done. There's a tremendous benefit to having few and highly trusted dependencies. Imagine civil engineering if every week there was a new flavor of concrete with different construction methods and structural properties.
Not too many people with a decade or more of development experience think that "downloading other people's random packages" is a fantastic or a confidence-inspiring idea. Ideally, those line-of-business CRUD apps that the modern world runs on should be write-and-forget, not rewritten continuously. This is why "churn" is a bad word to some. And yes, writing CRUD apps is pretty much solved, that is, it hasn't gotten that much more efficient in the last ten years if you look at the best tools.
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.
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.
Because, finally all big players are in the game and Javaize the stuff.
It's all hype and fads. People re-inventing the wheel to make money.