JavaScript developers are incredible at problem solving, unfortunately
cube-drone.com
cube-drone.com
That last part is the part that is most frustrating to me, and it isn't unique to javascript.
Google, facebook, yahoo, etc. have all gotten along pretty much just fine up until this point using existing web technologies. We should ALWAYS be trying to improve those technologies, and we should ALWAYS being trying to improve the workflows involved in using those technologies, but what comes across as ridiculous is the apple-style "this literally solves everything, and everything before it totally sucks and is useless and you are stupid for using it" marketing behind them.
I like javascript. A lot. I use it every single day, and it does a lot of useful things for me.
But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.
Javascripters, I get it, you're really excited. I am too. But maybe tone it down just a few notches.
Here's a thing I wrote about this topic a few years ago: http://thingist.com/blog.html?id=21434
Maybe we need to start proselytizing and make all the incoming Javascripters repeat: "There is no god but Crockford, and JSLint is his prophet."
It supports IE (back to 6 believe it or not), is backwards compatible with itself, is relatively mature, very stable, performs fine, supports modern stuff like component orientated architectures and custom tags (if you want them), interops brilliant with lo-dash/jquery and grows with you, it's also way more of a library rather than a framework so there is very little koolaid, the devs answer on github and are active (if not a huge community).
I also rather like it's <button data-bind="click: someFunction">Do The Thing</button> binding syntax (not least because with phpstorm and pycharm you can create custom language injections on XML attributes meaning I can do jump to definition near perfectly).
The problem with javascript libraries and frameworks is that, since the language itself has so many warts and quirks, it's easy to make a lot of "progress" patching over them with your unique library. So you come out on the other side, having won all these tiny victories, making things more sane, and I imagine most authors will believe their library literally "saves the day", when in reality, it just makes the language suck less.
Introspectively, despite having many frustrations with my tools, and periodically coming up with ideas for tools that seem at the time like they might improve upon things, I know that my gut sense is not, "wow, I could just code this up, get a community going, and make tons of consulting cash!", but rather, "ugh that seems super hard and likely to result in many hours of unpaid labor, I'll just work around these issues and get back to work".
edit: I just re-read my previous statement and you're absolutely correct in your analysis of what I actually said vs what I meant. I've since changed the post to read "technology" instead of "tool." What I meant to imply was that technologies like React and AngularJS were lucrative, not the supporting tools like gulp, grunt or npm.
> "ugh that seems super hard and likely to result in many hours of unpaid labor, I'll just work around these issues and get back to work".
I agree with you on that score. Unfortunately, unpaid labor on the side is an expectation of startup web development these days. Companies do not want you learning new technologies on the clock. They expect you to do that on your own. They expect you to contribute to and/or run your own open source projects. Just last week, my boss told me straight up that I was expected to make something that the company owns and profits from on my own unpaid free time to further my understanding of one of their core technologies. The "or else" was implied, of course.
Personally that would be a sign to start sending out my resume. Don't tolerate that kind of approach.
As far as I can tell, this isn't a JavaScript problem -- it's a general problem, and it comes from the fact that creating specific & modest solutions to day-to-day problems often seems to be a worse way to advance your career than creating a tool or library that becomes part of How We Do Things Now™.
On the browser, all I need is a library that handles DOM manipulation easily and has good browser support. When I find one, I stick with it for a long time and only change when something really exceptional comes along. Exceptional doesn't mean "literally saves THE WORLD", it means either comes up with better ways of accomplishing what my current library does, or does the same thing but with a huge decrease in file size.
I'm not interested in the flood of people trying to become the next John Resig. I'm just interested in getting stuff done.
I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving.
Oh, but you want to leverage the latest and greatest that the ecosystem has to offer... well, that's your problem, not the ecosystem's and this is true no matter which ecosystem you're referring to. JS developers are just spoiled rotten because JS is so easy to refactor relative to every other part of the system. When the NoSQL hype train came barreling through the developer community a few years back, most of us didn't rush out to rebuild our applications on a NoSQL back-end because the database is too critical to mess around with.
If you want the latest and greatest you have to pay for it, but don't imply that there is something wrong with the ecosystem for giving you more options. Choosing the best tool is part of the job, and if you get hypnotized by every shiny new toy that debuts on the front page of HN, that's a professional flaw that only you can fix.
This is a really shortsighted viewpoint. Cue 1 year later where all your libraries have fallen behind and you want to integrate a new library which has dependancies on newer version of your outdated libraries.
As I already stated, that's your problem, not the ecosystem's. If everything has been working fine for a year, but now you want to introduce a new library into the code, it's up to you to rationalize the necessity of that addition with the technical burden of updating your dependencies. Nobody is forcing you to use this new library and the only reason you can even consider this library as a potential addition to your application is precisely because the fast moving ecosystem has managed to provide you with a must-have library that you didn't need a year prior.
That is simply the fundamental nature of dependencies and will be true no matter which ecosystem you're working with, hence the ubiquity of package managers like npm, rubygems, composer etc. Either way, just because something exists, doesn't mean you have to use it.
Humans are incredibly resourceful, if not also short-sighted.
Look at PHP, look at Javascript, look at Wordpress, look at email, look at the original jQuery etc...
But email is broken in many ways and adding basic requirements like encryption is still not possible on a large scale do to lock-in.
I'm tired of hearing this. Theoretically true, but infeasible in practice. Try to build an OS in JavaScript and see how long it takes you.
Except that's not really true. While other languages exist that CAN run on servers cheap shared hosting and the ease of dropping in PHP and having it "Just Work (tm)" is nothing to scoff at.
Solution: javascript
So far no solution.
"Where I am from, the point of digging is not freedom from digging."
Is it a statement that the point of digging is to reach further and learn more (positive)? Is it a statement more along the lines of "We dig because we must dig to survive." (negative)? Or possibly that digging is simply a way of life (negative)?
The corollary being the axiom:
"If your problem is that you're stuck in a hole, the
first part of fixing that is: do not make the hole
deeper by digging, since that makes the problem worse."
Consider the lyrics from the song Trust Your Mechanic by Dead Kennedys.
Trust your mechanic to mend your car.
Bring it in to his garage.
He tightens and loosens a few spare parts.
One thing's fixed, another falls apart.
Trust your mechanic to make you well.
You're seeing an awful lot of him now.
The quicker he makes your life fall apart,
The more money you put in his pockets."People who cannot dig themselves out of a hole have never tried digging sideways." - JS Developer
Another way of seeing it is when we fix bugs. Instead of fixing one thing and finishing it, we like to touch and try to fix all the things (mostly when we own the code).. Essentially digging your own grave.. sometimes.. :)
AFAIK It has no features which would benefit from being used at runtime and there's never been any intention to run it straight in the browser. (If I'm wrong please correct me)
So one could conclude the wait is for Apple with Swift. But would they want that? I think they would rather see people write iOS-specific apps in Swift.
Of course there may be another 'whomever'. Facebook with Hack, perhaps? Their advantage may be that they aren’t big in hardware or operating systems, but I still think they are too big and therefore deemed too dangerous by the likes of Apple, Google, and Microsoft.
I think the only way is for some small player to come out of nowhere and somehow take the world by storm, probably, as you say, by riding on top of WebAssembly.
(by the way, I don’t think WebAssembly will be the leveller that allows everybody to pick his own language to develop in for the web. I think we will see some high-level API in WebAssembly develop that fits one language better than others. Of course, we could again choose to make “C” that language and that way allow almost any language interface with any other language through a crude interface, but I would hope we can do better by now)
[1] https://github.com/WebAssembly/design/blob/master/FutureFeat...
1.) some were closed-source and proprietary
2.) some were needlessly verbose, or enforced a workflow that made it difficult to interact with designers
3.) some depended on HTTP for at least the initial handshake
What the world needs is an open-source GUI technology that is fun for designers to work with and which uses a protocol other than HTTP.
My own bet would be that when we finally get such a technology, it will come from the world of gaming, where they already do amazing GUIs, and where they often abandon both HTTP and TCP and use UDP instead.
It's not like Apple said "Flash is the worst" and everyone said "Hey, you know I never thought about it like that". In fact I'm sure battery was a major reason not allowing flash, IIRC that (plus general indifference) was what was the nail in coffin for even android phones flash.
Ever hear of scaleform[0]?
https://github.com/WebAssembly/design/issues/189
https://github.com/WebAssembly/design/blob/master/FutureFeat...
So the problem isn't just the lack of a viable JavaScript alternative. The problem is building on top of a weak, fractured foundation that was designed for an entirely different application than we now want.
Illustrations/points like cube-drone has made here are popular because it's partly an over-exaggeration, and partly true. People on either side of the fence (JS mastery, or not), can find some kind of common ground of, "Right?? Isn't it painful??"
It's painful if you let it be. With the right mentors, and the right motivation, you can make JavaScript do wonderful things.
As a whole I think JavaScript has made the web a more fun and interesting place, no matter how much you want to bitch about the language or the ecosystem. We stand on the shoulders of giants, and I, for one, appreciate it. Thanks Brendan Eich! :)
There's no such thing as "mastering Javascript", because a language includes it's ecosystem, and for JS this changes from day to day...
JS is a scripting language, so it easy 'script' your solution and postpone a problem. But it this way, you will never be able to improve, and your life with JS will remain frustrating and hard.
Well, he's almost merely wrong, if he were to take out the "prototypal" part.
Someday we'll figure out that this is the problem with most features.
Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
The idea of protypical object-systems is for a large part coming out of the Lisp community (and the Smalltalk community) and was used long before Self or Javascript.
Check the works of Henry Lieberman. The Self developers got the idea of 'delegation' from him. Object Lisp was a prototype-based object system used in LMI's Lisp Machine OS and in Macintosh Common Lisp (until it was replaced by the then developed standard CLOS). Various Lisp-based systems were developed in the 'knowledge representation' domain, which are supporting 'prototypes'. Apple for example developed a system called Sk8 in Macintosh Common Lisp, which made extensive use of prototypes for multimedia UI tool development.
With the advent of CLOS those were not used for typical OO programming in Lisp - not because people don't like it, but because another standard system was provided.
It's how it's ended up in JS that I'm not a fan of.
1) I agree that the author sounds like a lot of developers who have a "What am I going to do without the exact class semantics I'm used to?" moment when they get to JS, and rather than learn to answer that question, they either decide that it's an inherent black mark on the language or go on a long quest trying to get something more like the semantics of another language in JS (often frustrating because it's almost possible).
2) More importantly, though... implementation inheritance itself is something a lot of thoughtful developers look on with a skeptical eye. Hence Gosling's comment about "I'd leave out classes" if he were starting over with Java, or Golang's interfaces. I wouldn't go so far as to call it "pants-on-head stupid" (I'll reserve contempt on that level for JS linters that enforce a no-semicolon policy), because it can be a nice mechanism for re-use, but it has its problems (fragile base class) and really only ever fits ideally to the extent that the portion of your domain you're modeling is actually a class hierarchy.
I do still consider implementation inheritance to be useful. But it's certainly used poorly in a lot of circumstances (along with MOST of OO design, including most of Java), and it may encourage bad habits. And I agree that composition is often a better answer. Depends on what you're doing.
Aside: Do JS linters actually enforce a no-semicolon policy in real projects?! I started using jshint and jscs recently in part to enforce the use of semicolons (on the advice of "JavaScript: The Good Parts"). I see that jscs has a "disallowSemicolons" rule, but I didn't know stupidity went to such depths as to actually USE that rule...I thought it was there for completeness...
Yes, they do. See https://github.com/feross/standard/ as a preconfigured example.
> (on the advice of "JavaScript: The Good Parts")
To paraphrase The Dude: yeah, well, you know, that's just, like, Crockford's opinion, man; whether you want to use them or not, there's tooling to support you either way.
There will always be platforms that are the Wild West, build-your-own-adventure decentralized toolkits and others that have a narrow political agenda and are more stable. Neither is better, it's just a question of what kind of frustration hurts you less.
I have no idea where this is coming from, but it's simply untrue. See [1] for a ton of examples of it being perfectly human read/writable.
All I can come up with is that people are looking at code compiled to asm.js, which is of course going to have all semantic meaning stripped from it, no different than code compiled to javascript.
I have to admit, I was a JavaScript hater for a long time, up until recently when I actually spent time to learn the language. Now its quickly becoming one of my favorite server-side languages. Isomorphic JS was too hard to resist :)
I wonder how much the rise of Github's / npm have to do with it. In the last 5 years or so it has become so much easier to create and share projects. Not only so - it has become a requirement, people use Github as their CV, we are all _expected_ to have side projects and stuff.
Problem: Javascript won't run outside the browser. --> Fixed.
Problem: The DOM is too slow for video games. --> Fixed.
Problem: Javascript is single-thread by design. --> Why is this a bad thing?
Problem: Javascript is too slow for video games. --> [Citation needed]
Problem: Javascript has no packaging or a linker to tie these packages together. --> Linker's not needed, and there are many package managers that work pretty good. Also, since the beginning of javascript you could always <script src=""> whatever you need, pretty cool actually.
Problem: Callback Hell. --> This "problem" only bothers bad/lazy/naive coders.
Problem: asm.js is basically unwritable by humans. --> Nope, and also, you may not need to write asm.js at all.
Problem: Prototypal inheritance is just pants-on-head stupid. --> Clearly a joke to try to use this as an argument.
Problem: Web resources need to be minified and zipped for performance. --> Yeaaaaah right, because Javascript == Web.
Problem: Machine generated output is more difficult to debug. --> As compared to... another machine generated output from a compiled language? Yeah right...
Problem: Async is still a nightmare, huh? --> Same as callback hell.
Problem: Balloning project size and complexity. --> [Citation needed]
Problem: Javascript still doesn't do everything. --> Is this guy serious? Does he thinks this is a valid argument for anything?
Problem: Output runs very slowly on mobile devices. --> [Citation needed]
The guy's just a lazy coder. His favorite language would be one where he could just do: "include <what_my_boss_wants>; run();". Good luck waiting for that one.
"include <what_my_boss_wants>; run();"
why the hell would you not do that?