Live data from Hacker News

JavaScript developers are incredible at problem solving, unfortunately

cube-drone.com

91–100 of 100 posts

Re: JavaScript developers are incredible at problem solving, unfortunately

#91

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?

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 difficul…

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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#92

> 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 n…

>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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#93

Earlier quoted context omitted.

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 difficu…

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" inst…

> 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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#94
post #92

> 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 n…

> 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 wan…

> 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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#95
post #86

Earlier quoted context omitted.

> 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.

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 devel…

Oh, I think the idea is plenty neat.

It's how it's ended up in JS that I'm not a fan of.

Re: JavaScript developers are incredible at problem solving, unfortunately

#96

Earlier quoted context omitted.

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…

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...

Re: JavaScript developers are incredible at problem solving, unfortunately

#97

Earlier quoted context omitted.

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…

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),…

> 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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#98
post #9

This is absolutely a NIGHTMARE for new developers. 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. 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 gotte…

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…

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.

Re: JavaScript developers are incredible at problem solving, unfortunately

#99
post #70

Earlier quoted context omitted.

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

Re: JavaScript developers are incredible at problem solving, unfortunately

#100

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 c…

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...

Post reply on HN