Comment by aedron | Hacker News Reader

Comment by aedron | Hacker News Reader

Parent Full thread

> why the ecosystem looks like this

It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently.

The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alone there was Struts, WebWork, Wicket, Tapestry, JSF, Spring MVC, and countless others, each one sucking more than the other. They are all pretty much dead now because people realized the insanity of trying to build a GUI using a page request based approach.

This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).

The attempts to compile down to JS is the best we can currently do, which is why the best and most complex JavaScript applications that have ever been made have been done this way, but obviously a native solution will be the better solution.

The best bet would be an intermediate layer, a kind of JVM for the web, on which a thousand languages could run. That is bound to be a long way out though, so we have at least a few more years of pointless JavaScript framework churn.

> [Javascript] simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).

Electron? Atom? Slack? React Native? Espruino?

Also, there are plenty of non-web Node.js applications, e.g. https://github.com/sindresorhus/awesome-nodejs#command-line-...

Wrapping a browser instead of using one directly doesn't make your application run in a non-browser runtime environment.

And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.

React Native doesn't wrap a browser view, it uses native gui controls.

> use it as minimal as necessary

Interesting point of view, considering that people are building javascript desktop applications, server applications, embedded applications, web (browser) applications, and what not.

I think PHP is a better analogy than early-2000s Java/.NET. Those latter technologies were largely enterprise driver, but the PHP ecosystem used to be more like today's JavaScript ecosystem. PHP a Blub[1] language, like JavaScript, which attracts inexperienced developers because it seems easy and has widespread support from hosting platforms. Inexperienced developers tend to reinvent the wheel (badly). One major difference is that PHP has a standard library that does almost everything, whereas JavaScript needs insane numbers of libraries for a typical production system (in my case, 5 explicit dependencies create a tree of ~300 packages).

> This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications.

I agree, and Facebook (Flow), Google (Dart, TypeScript, and probably others), and Microsoft (TypeScript), agree with us.

> The best bet would be an intermediate layer

See: WebAssembly[2], the successor to asm.js (sometimes called "the bytecode for the web").

1. http://paulgraham.com/avg.html

2. https://en.wikipedia.org/wiki/WebAssembly

I think you've nailed it. Web programming in javaland was verbose but relatively straightforward until about 2004, maybe a little earlier, when frameworks exploded. I'm not sure the frameworks themselves were worse than what preceded then - Struts2 was, in my opinion, an improvement over the original Struts. But I do recall hating web programming for a few years, wanting to leave and do something else (in a way, I did, I got a job writing java code to interact with CPLEX, and other developers handled the webapp stuff, so I was able to just mainly write straightforward Java, which I still don't think is such a bad language, it was the framework bloat that I disliked). The reason was doing very simple things had become mind numbingly difficult, and you had to wade through massive amounts of configuration and framework documentation (or code, since documentation often didn't exist for your specific issue) to do relatively simple things. The Java web programming cookbook became relatively obsolete, because everything was now handle by a framework that promised to make things simpler, but (often due to churn) massively increased the overhead.

Interestingly, it was, as you've pointed out, never resolved. Instead, it all became obsolete. I personally left javaland and started writing with Rails (even the non-web stuff I generally started using Python rather than java).

I suspect that we're heading down that road again. I think the modern javascript frameworks are the product of very intelligent and talented people, but my gues is that something interesting and "unanticipated" will sweep this all aside.

To risk a prediction, I think that other languages transpiled to isomorphic javascript will provide a new approach that will allow excellent languages like ruby and python to be used to write an entire web app again.

Until then? I wish I'd had the conviction to avoid MVC frameworks in the early 2000s. It's easy to feel like you're doing things the "old way", but I wasted a lot of time chasing java frameworks only to abandon the entire enterprise a year or two later… of course, it wasn't entirely my decision, it's hard to go against the grain, since you're rarely the only developer on a team.

> The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).

I believe Qt's QML also uses JavaScript.

Reply on news.ycombinator.com