JavaScript developers are incredible at problem solving, unfortunately(cube-drone.com)
cube-drone.com
JavaScript developers are incredible at problem solving, unfortunately
http://cube-drone.com/comics/c/relentless-persistence
99 comments
I just use Knockout.js unless there is a really compelling reason not to, I just chose one and learnt it decently well.
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).
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).
Yeah, Knockout has also served us well: has been flexible as our architecture has shifted, and has progressed steadily without forcing us to pay a "framework churn" tax. It's become a mature, stable, pragmatic option, IMO.
I use Javascript every day. The cognitive load you're talking about doesn't exist with me.
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.
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.
> People come into the language, and there are what seems like an infinite number of "the only right" ways to do something, all of vary degrees of complexity/usefulness, and all claiming that they are god's gift to computer science.
Maybe we need to start proselytizing and make all the incoming Javascripters repeat: "There is no god but Crockford, and JSLint is his prophet."
Maybe we need to start proselytizing and make all the incoming Javascripters repeat: "There is no god but Crockford, and JSLint is his prophet."
> But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.
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.
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.
I don't think the "javascripters" (whoever they are) are behind all the fragmentation. What we're seeing is caused by a low barrier to entry combined with a larger number of people who want to profit from a lucrative business pattern. That pattern is to create a technology that addresses a grievance (real or imagined), create a community around that technology to help promote it, then sell consulting fees once companies adopt it. This has worked brilliantly in the past (Enterprise Java in the 90s, Scrum, Ruby on Rails) and continues to make the companies behind it a lot of money in consulting fees.
I don't think this is a good enough business model to explain so many tools popping up. Firstly, it's hard and expensive to make a tool good enough to become popular. But more importantly (and increasingly), it's extremely hard and very risky to build a community to a critical mass where it can sustain itself, precisely because there are so many tools competing for attention. I think tools pop up despite this difficulty and risk, because people have real itches they're scratching.
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".
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".
I think there's a misunderstanding; I'm not saying people profit from the tools. They profit from consulting for companies who have adopted the technology, which is a very, very lucrative field. Just look at the Rails consulting shops.
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.
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.
> 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.
Personally that would be a sign to start sending out my resume. Don't tolerate that kind of approach.
> But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.
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™.
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™.
Exactly. You articulate my thoughts regarding JavaScript excellently
> the ecosystem around Javascript is so densely layered and frequently changing that maintenance of any project over any significant period of time is going to be a nightmare
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.
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.
>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.
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.
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.
> 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.
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.
I learned a while ago that it doesn't matter how broken something is if everyone is using 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...
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...
Email is one of the least broken communication protocols we have. Which says something.
Email it's the only free, distributed protocol we have at a large scale. I love that.
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.
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.
Universities try to convey this. My final year was more about project management, technology was one variable and nothing else (one of few values of UML is that it tries to be agnostic, even though hyper c++/OOP centric). And thanks to Sir Turing and his friends, you know you can always solve the problem with whatever language/system you have.
> And thanks to Sir Turing and his friends, you know you can always solve the problem with whatever language/system you have.
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.
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.
I didn't mean to stretch it, you get the message, do not write an OS in SQL nor a DB in bash, but don't tie yourself to a technology too much either.
Well, part of the problem in this case is that JS or something that compiles to JS is the only option for running in the browser, unlike PHP or Wordpress, which have many alternatives.
> unlike PHP or Wordpress, which have many alternatives.
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.
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.
qwerty keyboard is my favorite example. Designed to solve the key sticking problem when typing too fast but now we're all stuck with a layout designed to be inefficient.
https://www.addedbytes.com/blog/dvorak-vs-qwerty/
https://www.addedbytes.com/blog/dvorak-vs-qwerty/
For all the hype I hear about dvorak and other alternate keyboard layouts, I've never met anyone who could type significantly faster on it than I could on qwerty. This isn't objective in any way but from experience I can't say its any 'better'. As for ergonomics and other peripheral effects, I can't comment as I haven't looked into them.
Well objectively it's less finger travel and more home row use, so it has its merits. The issue is that qwerty is such a de facto standard that you'll run into many layout issues using dvorak.
I agree. I have a bit faster typing speed right now with dvorak. not sure if it is really super-better, but I definitely benefited from http://www.typingstudy.com
By preventing the key sticking problem, it was more efficient than earlier designs - it wasn't designed to be inefficient.
FYI, the "key sticking" origin of qwerty is probably a myth: http://www.smithsonianmag.com/arts-culture/fact-of-fiction-t...
When I write c# code, it's just that, code. When I write Rust code it's just code. When I write JavaScript...I'm making beautiful peices of art. Almost like an old school watchmaker...a million ways to do the same end result.
I'm not sure how to interpret the last part...
"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)?
"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)?
It's a joke, that's the punchline.
The corollary being the axiom:
Consider the lyrics from the song Trust Your Mechanic by Dead Kennedys.
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.I take it to mean that if you keep digging, the hole will just be deeper. I.e. you cant dig yourself out of a hole.
What are you doing when you "dig into a problem"? :) I have a feeling the intent was supposed to be pessimistic/negative (as you stated). I decided to have some fun with the words. It leaves a few possibilities as to the meaning and speaks well of what the developers are typically doing in their "problem solving": digging deeper (for knowledge) rather than trying to get out of a hole.
"People who cannot dig themselves out of a hole have never tried digging sideways." - JS Developer
"People who cannot dig themselves out of a hole have never tried digging sideways." - JS Developer
The interpretation is left open to the reader. It could be a negative and cynical nod to the idea that we're doomed, and digging our way straight to hell, or possibly a coy wink at an absurd paradox of conflicting goals among participants.
I took it as a positive meaning.. The point of digging (suffering as a dev from all these new shiny things) is to reach a purity/elegance when writing code not only to just create/finish the project.
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.. :)
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.. :)
One wonders how we get out of this mess. You'd have thought that Microsoft/Google/Apple/whomever would have at least tried to include a better alternative language in their browser by now. What stops them besides inertia?
I want browsers to support a bytecode language designed from the ground up specifically for this purpose instead of just being a quick hack that by a fluke of history happened to get wide adoption. It would be more like .NET and the JVM in the sense that it would be designed for a specific purpose (a language suitable as a target language for compilers from a wide variety of high level languages). But we should not confuse that last sentence to mean that it should be similar to .NET or the JVM. I think two main design goals should be efficiency and good support for high level languages. This means proper support for tail call optimization so that functional languages like Haskell, Clojure, etc can generate efficient code. It might also mean some special considerations for garbage collection that I'm not knowledgable enough to comment on...amongst other things. WebAssembly sounds like the right idea but if they miss important things like TCO, then it's still not acceptable.
Regarding TCO on WebAssembly: "Yes, proper tail calls will be supported, but likely not in MVP."
https://github.com/WebAssembly/design/issues/189
https://github.com/WebAssembly/design/blob/master/FutureFeat...
https://github.com/WebAssembly/design/issues/189
https://github.com/WebAssembly/design/blob/master/FutureFeat...
X, Flash, Swing, JavaFX, SilverLight, AWT and more were all attempts to offer a GUI over TCP. The important question is why they all failed. This is a complex issue and many good essays have been written that address parts of the question. Still, I think most of it can be boiled down to 3 things:
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.
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.
> 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.
Ever hear of scaleform[0]?
[0]: http://gameware.autodesk.com/scaleform
Ever hear of scaleform[0]?
[0]: http://gameware.autodesk.com/scaleform
Scaleform is a barely-maintained Flash implementation.
Then I wouldn't put much hope in the world of gaming coming up with a GUI solution, then. From what I understand, Scaleform is considered best in breed for cross-platform GUIs in the gaming world.
It's fun you say that, Valve just ditched Scaleform (industry-standard, based on Flash) for their own GUI stuff called 'Panorama' in DOTA2, which is XML, CSS and JS.
One was killed by Apple.
If you are talking about flash let's be clear. Flash was killed by mobile (and being generally shitty).
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.
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.
Did X fail?
Yes. It's not in my browser.
That's an excellent response, but it leads to the question, why are we using HTML if X was successful? HTML over HTTP is now routinely used to deliver a GUI for TCP, even though HTML was originally designed to deliver structured documents, and HTML comes with a great deal of baggage that muddies its ability to function as a GUI. It's become common to use a mountain of Javascript to try to overcome that baggage. Clearly, a fresh start is warranted.
They've tried Typescript and Dart. No massive uptake to date. WebAssembly may be a way forward.
That takes out Microsoft and Google from that list. Also, ‘whomever’ already had its opportunity with Java.
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)
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)
Typescript transpiles to Javascript - its purpose is to allow static type-checking of regular Javascript code by dev tools, prior to transpilation.
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)
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)
If WebAssembly doesn't get proper support for tail call optimization, then IMO it's not the way forward. Right now it's listed as a future feature[1] so color me skeptical.
[1] https://github.com/WebAssembly/design/blob/master/FutureFeat...
[1] https://github.com/WebAssembly/design/blob/master/FutureFeat...
At the end of the day, you'll still be tied to the DOM, tied to poorly specified and poorly implemented HTML specifications (e.g, ContentEditable), tied to browser incompatibilities, and tied to CSS.
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.
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.
I'd like a distributed app VM that's completely separated from the browser. Every time I think about this, I'm brought back around to this thought: why not java? Minecraft was a good proof of concept and it shows you can make a complex distributed application using java. So why are we tethering ourselves needlessly to the browser?
I think you missed Dart. In any case, everyone agrees at this point that compiling arbitrary languages to Javascript or a Javascript-derived compile target is the way forward. Write ClojureScript.
Funny thing: JavaScript was actually supposed to be Scheme, not once but twice, and both times it was scrubbed because Netscape was in fierce competition with Microsoft.
One must wonder whether Netscape greenlighting the addition of a Scheme dialect simply would have caused Microsoft or another party to implement some flavor of ALGOL or BASIC in return and leave the hypothetical SchemeScript going the way of the dodo, much like Netscape's JavaScript Style Sheets that almost no one remembers today.
JavaScript is both easy to get into, but difficult to master. There are places on your path to JavaScript mastery where you're literally like, "Did I make the right choices in my life?". Push a little harder, and like anything, the added effort to understand the choices put in front of others, and why something works the way it does, will be rewarding.
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! :)
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! :)
>JavaScript is both easy to get into, but difficult to master.
There's no such thing as "mastering Javascript", because a language includes it's ecosystem, and for JS this changes from day to day...
There's no such thing as "mastering Javascript", because a language includes it's ecosystem, and for JS this changes from day to day...
The thing I like about clojurescript is the fact that it has a linker and library system which makes sense.
Just a little advice for newcomers ( like me ) that are scared but at the same time fascinated when it comes to use javascript. If you choose a framework to work with, stick to it for the entire project, and if you find an error that makes you struggle, don't immediately invent your own solution to patch it:
for all the things that are said in this article, it always easy being attract to the fact that in every framework/code base you can put a simple piece of code that make things simpler for your and let you go ahead when you are stuck. But in my experience, most of the times, it only about being lazy and scared from and understood error. Behaving like this it let you behind, and don't make you improve your skills. And always break the entire logic of the tools you're using.
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.
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.
"Prototypal inheritance is pants-on-head stupid."
Well, he's almost merely wrong, if he were to take out the "prototypal" part.
Well, he's almost merely wrong, if he were to take out the "prototypal" part.
Prototypal inheritance works well, if you understand it. It's only "wrong" if you're of the Java/C++ OOP religion.
My comment is arguably overelliptical, so I'm going to 'splain:
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.
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 come from games, which actually map to OO design better than most domains, from what I can tell. And while I was briefly of the OO religion, I've since recovered and appreciate all paradigms for what they can best accomplish. I'm "Post-OO". :)
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...
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...
> Aside: Do JS linters actually enforce a no-semicolon policy in real projects?
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.
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.
I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance. Overall, the more I understand JS, the more I'm convinces most issues raised are personal preferences.
> I find most people who have gripes with JS prototypes are the ones who are used to classical inheritance.
Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
Counterpoint: Scheme/Lisp/FP fans also don't tend to like it. Myself included.
Not really.
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.
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.
Oh, I think the idea is plenty neat.
It's how it's ended up in JS that I'm not a fan of.
It's how it's ended up in JS that I'm not a fan of.
> if you understand it
Someday we'll figure out that this is the problem with most features.
Someday we'll figure out that this is the problem with most features.
[deleted]
[deleted]
This is a double edged sword. Yes, web technologies are sprawling, but they are also constantly improving, which is not always true of the more tightly controlled platforms. You can build on iOS for example, where there are generally only a few ways to do things. But then you're waiting on Apple to release new stuff.
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.
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.
"Problem: asm.js is basically unwritable by humans."
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.
[1] http://asmjs.org/spec/latest/
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.
[1] http://asmjs.org/spec/latest/
I wonder if people just say that now without actually looking. The last time I saw any asm.js code it looked like very boring old c++ code, nothing crazy. Probably more readable to a newcomer than closures or self calling anonymous function wrappers.
While there's a lot of truth to this comic, I don't necessarily see it as a bad thing. I think it speaks to the flexibility of JavaScript. Sure, all of the tools and libraries can be hard to keep up with, but I'd rather have lots of community support than none.
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 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 actually think the "blame" is not so much Javascript's - after all it has existed since 1996 and it wasn't like that at all for many years.
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.
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.
I wish I could upvote it more...
Well, you could create another account... (I'm a javascript developer)
[deleted]
I'm lost as to why Grunt is a problem. I tried to put all of my build scripts in the package.json but moving to Grunt has been incredibly useful.
Because "code over configuration". Personally I'm not a fan of Grunt's API which requires huge json files where keys mean special things. It feels very ad hoc and ugly. Gulp's API is like 5 functions.
Problem: Javascript has almost no standard library. --> Why is this a problem? What does he mean by standard library? Like, "strings", regexes and hashes? Not needed.
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.
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.
Indeed, if you could do:
"include <what_my_boss_wants>; run();"
why the hell would you not do that?
"include <what_my_boss_wants>; run();"
why the hell would you not do that?
I... somehow disagree with everything you are saying, sorry.
Maybe it's because of that attitude of forcing JavaScript upon everything, instead of simply using the appropriate tools. That's what I expect from people like this comment writer, and that's what causes that digging in the comic.
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