> Richard Stallman envisioned open source
No, he envisioned Free Software.
https://www.gnu.org/philosophy/open-source-misses-the-point....
The other kind of JavaScript fatigue
51–60 of 99 posts
Re: The other kind of JavaScript fatigue
#52One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintainer and take credit for it's success as a large and popular project, which by itself is a good thing. The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fi…
Most open source maintainers are developers who work full time - I am a maintainer of a major project, but there are times my activity is light, such as the past two months. In that time, I travelled to Salt Lake City, Reno, Portland, San Diego, Seattle, and now in route to Chicago - I ran a half and full marathon in that time, and about to run another half tomorrow morning. I am currently in crunch time at my curren…
In the Java world, most major open source projects are sponsored by companies. Someone(s) is getting paid to maintain and evolve that thing as part of their job. Companies might do this to drive traffic toward the commercial "enterprise" version, for which they charge money. More commonly though, it's just something that they use internally... and they open it up for marketing/prestige/recruitment purposes.
In most other language ecosystems, most open source projects tend to be driven by individuals as unpaid side projects. That's great in a certain sense, and a large part of the reason why Java is less "cool" among young people who are eager to plant their own flag on an open source thing. But sadly, it's just really difficult to keep a major side project alive and healthy over the long-term without sponsorship. So those ecosystems tend to be chaotic and flaky.
Re: The other kind of JavaScript fatigue
#53"Embrace change, and it will make you a better developer." I don't agree with this at all. I think a good coder has complete mastery of their code and tools which is only possible by putting significant time to use one thing instead of jumping one thing to the next ever so often. Imo the best way to become a better developer is not by using what others have created but trying to create libraries and frameworks yourse…
I think you're on to something with the process of becoming better at development. Building the hard/arcane/boring things and understanding them leads to a much larger mental tool set. The solution for problem A could apply to shiny new thing B in a novel way, but you'd never know because A was boring and you have never done it. That being said, there's practicing your craft and getting shit done. I'm going to be VER…
Yes, it is unfortunate most programmers just don't have the time. But when you do, it is a rewarding exercise.
Re: The other kind of JavaScript fatigue
#54Earlier quoted context omitted.
Most open source maintainers are developers who work full time - I am a maintainer of a major project, but there are times my activity is light, such as the past two months. In that time, I travelled to Salt Lake City, Reno, Portland, San Diego, Seattle, and now in route to Chicago - I ran a half and full marathon in that time, and about to run another half tomorrow morning. I am currently in crunch time at my curren…
In the Java world, most major open source projects are sponsored by companies. Someone(s) is getting paid to maintain and evolve that thing as part of their job . Companies might do this to drive traffic toward the commercial "enterprise" version, for which they charge money. More commonly though, it's just something that they use internally... and they open it up for marketing/prestige/recruitment purposes. In most…
Couldn't have said it better. In the webdev world this turns into a problem because I need to rely on these oss projects and while some of them might be high quality, there is a significant overhead involved in determining which ones are worth using and which ones I can rely on. For personal projects it's a not big deal but for work I want to be as efficient and reliable as possible and the chaotic/flaky ecosystem gets in the way.
edit: fixed to *not a big deal
Re: The other kind of JavaScript fatigue
#55Wait, Angular 1 is dead? That's news to me.
Indeed, "dead" is a strong word. Angular 2 is almost finalized so 1.X series will be unsupported in the future at some point. Starting a new long-lived project with Angular 1.X at this point would arguably be a bad choice.
Re: The other kind of JavaScript fatigue
#56Realized this sometime ago, when I was wondering why the Java ecosystem doesn't have this problem. It boils down to the barrier of entry. On JS it's so low as to be almost nonexistent, which is why you end up with junk like isPositiveInteger. Slap some shit together and ship it. You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an art…
I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…
Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimplemented different bits of it in a thousand and one ways, nearly all of them more or less subtly broken. (I don't understand the obsession with JS library size - it's completely irrelevant in 95% of cases, compared to the megabytes of other garbage most sites will pull in for trackers and images).
Re: The other kind of JavaScript fatigue
#57Wait, Angular 1 is dead? That's news to me.
It's soon to be no longer developed, because the Angular team saw a React talk and decided to build their own version that nobody seems to want very much.
Re: The other kind of JavaScript fatigue
#58"Embrace change, and it will make you a better developer." I don't agree with this at all. I think a good coder has complete mastery of their code and tools which is only possible by putting significant time to use one thing instead of jumping one thing to the next ever so often. Imo the best way to become a better developer is not by using what others have created but trying to create libraries and frameworks yourse…
And you are wasting huge amounts of time by rewriting stuff that's already out there tested by thousands of people. Also collaborating with others becomes much more challenging because you invendted everything. With experience I can minimize self written code and I can skip plugins and libraries, but I feel better if I can rely on something solid. It does not apply to all field of programming per se, but web develope…
Ofcourse someone has to go to the other far end of the spectrum :) Yes, I agree rewriting everything yourself is a huge waste of time. But if you see a framework or a library and you think you can do it better, I say go for it, on your spare time that is.
Re: The other kind of JavaScript fatigue
#59Realized this sometime ago, when I was wondering why the Java ecosystem doesn't have this problem. It boils down to the barrier of entry. On JS it's so low as to be almost nonexistent, which is why you end up with junk like isPositiveInteger. Slap some shit together and ship it. You can't do that easily in Java. You need to spend some time understanding the language, the ecosystem, how to bundle your code into an art…
I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…
Ehh... When there are many questions on SO asking how to read a file in Java and the answers all require about a dozen LOC and have hundreds of upvotes [0,1,2] I think I agree with the earlier comment that it's more a barrier to distribution and acquisition of modules. There are plenty of tiny npm modules that do less than a Java wrapper for easily reading files would.
[0] http://stackoverflow.com/questions/4716503/reading-a-plain-t... [1] http://stackoverflow.com/questions/326390/how-do-i-create-a-... [2] http://stackoverflow.com/questions/3402735/what-is-simplest-...
Re: The other kind of JavaScript fatigue
#60Earlier quoted context omitted.
I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…
Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimp…
And not just in javascript. HTML is largely the culprit too. A lot is done in javascript that HTML should really handle.
For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. It is such a common scenario there shouldn't be a need for a javascript framework to provide that.
Same thing with responsive design.
But these technologies are stuck in the 90s and barely evolve anymore.