Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rich client side web apps gone too far (2014)

chase-seibert.github.io

Post reply on HN
Print view View original

11–20 of 58 posts

Re: Rich client side web apps gone too far (2014)

#11

Post by bikamonki »

JS is good enough for most cases. Besides, author is missing a BIG point here: we, 99% of web devs, have never stepped beyond setting up a virtual host in Apache. What I mean is that we have no clue how to properly deal with server performance and security. Hacked lately? Most of the code out there is made by small shops and consultants who cannot afford a server ninja nor have the time to (also) master that skill; and shouldn't do it anyway: remember specialization equals progress? So, even with cloudware solving most of the performance related issues, security is still on the hands of the devs. Take my example: buy a DO droplet, get a LAMP image, install framework, follow security best practices, get hacked, rinse and repeat.

So, fat-rich-messy clients will be the norm and BAAS providers will get richer selling services that take away the headache of running a server. Too bad JS is the only option to program them clients.

Re: Rich client side web apps gone too far (2014)

#12

Post by dgreensp »

I agree that there are some pretty bad rich apps out there that you run into once in a while, especially ones that were contracted out to the lowest bidder.

The pet theory is wrong, by the way, it was not mobile that led to the rise of rich clients. When I worked on AppJet and EtherPad in 2007-2008, the rich client wave was ahead of the mobile wave. Round-trip latency is significant when interacting with a UI, even if it is just 100-200ms. It was obvious that if you could deliver a desktop-quality app that worked on every platform and didn't need to be installed, that that was the future.

I think it's worth focusing on the actual harm of certain ways of writing rich apps (e.g. breaking navigation).

Re: Rich client side web apps gone too far (2014)

#13

Post by mattdeboard »

dgreensp wrote: post #10
mattdeboard wrote: post #6

Earlier quoted context omitted.

I mean, his assertions are right. JavaScript is objectively not a well designed language. That said, he still asserts that JavaScript acquired a reputation worse than it deserved not because of its design decisions but because of the platform it was targeting (the browser). Your comment reads like a reflexive defense of JavaScript since "javascript sucks" wasn't even the point of the essay.

I think you're going to run into trouble with the word "objectively" there. All languages have warts, and some are much worse than others. I actually think JavaScript's warts are fairly minor compared to C's or Python's, for example, and PHP is in a different league. In fact, there are almost no other programming languages with JavaScript's basic features: Unicode support out of the box, proper lexical scoping with f…

Garbage collection is a function of the particular runtime, no? Which probably isn't anything to do with the language... right? I'm asking sincerely, these aren't loaded questions.

Re: Rich client side web apps gone too far (2014)

#14

Post by mslate »

bikamonki wrote: post #11

JS is good enough for most cases. Besides, author is missing a BIG point here: we, 99% of web devs, have never stepped beyond setting up a virtual host in Apache. What I mean is that we have no clue how to properly deal with server performance and security. Hacked lately? Most of the code out there is made by small shops and consultants who cannot afford a server ninja nor have the time to (also) master that skill; a…

What is "BASS"?

Re: Rich client side web apps gone too far (2014)

#15

Post by carsongross »

His criticisms of Javascript are, of course, correct. It's a huge mark of shame for the technical community that we've allowed this language to "win". Bafflingly, people who even suggest that the hacks-upon-hacks we've had to use for even basic software engineering techniques like namespacing are just that, hacks, routinely get shouted down. The whole thing will make an interesting sociological study at some point.

From the article:

"Javascript used to be a tool that you used as sparingly as possible, sprinkling just the barest hint of dynamic behavior where it was absolutely necessary. Now it's common to start a new project and assume that 50% or more of the code will be Javascript."

I know I've been asked to cool it on the pimping, but this is exactly what intercooler.js is designed for: you don't need to write much javascript for the dynamic behavior you want 99% of the time.

Re: Rich client side web apps gone too far (2014)

#17

Post by bikamonki »

mslate wrote: post #14
bikamonki wrote: post #11

JS is good enough for most cases. Besides, author is missing a BIG point here: we, 99% of web devs, have never stepped beyond setting up a virtual host in Apache. What I mean is that we have no clue how to properly deal with server performance and security. Hacked lately? Most of the code out there is made by small shops and consultants who cannot afford a server ninja nor have the time to (also) master that skill; a…

What is "BASS"?

BAAS -> Backend as a service. For example: parse.com or firebase.com * It was mispelled, fixed it already

Re: Rich client side web apps gone too far (2014)

#18

Post by cromwellian »

"I wrote a single page web based email client in 2003, years before the launch of Gmail"

Gmail was launched in April 2004, not "years before". A nit, I know. I can summarize this article as "Javascript sucks".

That was true for a long time, but the world has moved on since 2003. ES5 strict mode fixed some of the issues. ES6 fixes a lot more. Since then many frameworks and tools have been developed as coping mechanisms. Closure Compiler, CoffeeScript, GWT, TypeScript, Flow, etc.

I'd actually say that client side Javascript hasn't gone far enough. There is much to do to improve the Web platform itself, and relying excessively on server rendered markup that gracefully degrades is not going to convince people to stop writing native code, if anything, it'll make it far worse, as network radio latency makes relying on server round trips for UI transitions bad on even the best mobile networks, and extremely bad in developing world wireless environments.

Re: Rich client side web apps gone too far (2014)

#19

Post by lucian1900 »

QuantumRoar wrote: post #8
bsaul wrote: post #5

He forget that since you're going to have a native app targetting your website, you're going to need a rest api anyway. So why not have you web client consume the same endpoint and just code the rendering ? I find stack designed this way actually much saner.

Why wouldn't it be possible to let your API talk to the back-end of your website? Ideally, you want to have the best format for every platform you are targeting. The phone can have its app but the web should have a website that works like a website, not like a clone of a smartphone app. You could also turn your argument around. Say you have a website and now you want to make a smartphone app. You wouldn't want to wri…

> Why wouldn't it be possible to let your API talk to the back-end of your website?

It is. However, since the API is already designed to be used securely by a client, it'll be a lot less work to make the browser be the client of the API.

Re: Rich client side web apps gone too far (2014)

#20

Post by jbergens »

mattdeboard wrote: post #4
woah wrote: post #2

Huh... I'm not sure what he is having an issue with, exactly. His mention of "this" may indicate an adherence to JS OOP antipatterns... other than that, it's hard to see what the problem that he is having is.

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

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]
Post reply on HN