Hacker News Reader

Comment by mattdeboard | Hacker News Reader

He is ranting about the practice of creating "rich client side applications" when they are not necessary. His argument is predicated on the following, as far as I can tell:

1. JavaScript has numerous design flaws, mainly wrt giving developers many very large guns with which even experienced devs can easily shoot themselves in the foot.

2. Languages and frameworks targeting the server-side of the web are suited very well -- better than JavaScript, historically -- to creating dynamic HTML.

3. Complex UI interactions typical of single-page applications are inherently difficult to do well.

I am not sure why the first two commenters seem to dismiss his entire essay because he uses scoping issues as an example, but that's pretty unfair & close-minded.

View on HN

1. JS has a lot of quirks, but you can find quirks in anything that has been around for a long time. From just using a linter you can avoid a TON of problems (and realistically, how many people code in any language without any kind of linting?).

2. I don't know what to say about this. Maybe historically, yeah. But nowadays? You can build your API with any language or framework, and have nodejs running an isomorphic app. This means you can do server-side rendering and then delegate to the client once it loads. This provides the best possible experience. And you avoid code duplication, since you can run the almost the exact same code on the server and client. (You'll usually have to do some minor tweaks, which I'd consider reasonable.)

3. From what I've seen, complex UI interaction are difficult to do well regardless of your environment. (This is also why I've been really excited about react+flux, since it provides a much better experience when developing applications.)

Not all quirks are created equally, friend, and not all languages of a particular "generation" (e.g. python, javascript, java all released in the early- to mid-90s) are essentially equivalent. PG put it well:

> But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well.[1]

Anyway, we probably agree on this topic but are dickering over something tangential (whether JavaScript sucks). I'm a big React+Flux fan as well. I never enjoyed front-end development, and really I avoided it, until React came around.

[1] http://www.paulgraham.com/avg.html

+1 I think that React.js is actually a much better model, closer to how you would render full page renders on the server.

Perl gets bashed for all its quirks all the time, although there is a huge amount of tooling to write clean and readable Perl (Perl::Critic, Moose, etc). What really amazes me, is how everybody seems to be cool with using tons of tools to work around the many inherent language deficiencies in Javascript (with Coffeescript being the most insane "solution"), but it's a totally different story when it comes to Perl.

I'm not sure the server side is much better. Complex UI is complex wherever you try to implement it. You can say that is not actually possible to create really smooth UI with animations only using server side code. And server side code usually don't want to keep any state at all (to allow the use of multiple servers) which causes a lot of problems. A SPA can keep state and use it if it suits the problem better. Some of the new js libraries actually looks more developed than most server side ones. [edit: spelling and a clarification]

> Complex UI is complex wherever you try to implement it.

Yeah that's what I meant by #3. Independent of runtime, language or implementation-specific particulars. It's... gooey.

Reply on news.ycombinator.com