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

21–30 of 58 posts

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

#21

Post by jbergens »

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…

Although you raise a good point I do think much more than 1% of all web devs knows a lot about server side things. And for me using Firebase or similar is giving up too much control. I want to be able to build server side logic for apps.

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

#22

Post by bsaul »

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…

"you wouldn't want an app that renders html served by a server". I wouldn't because it would be (almost) impossible to render it differently in order to adapt it to the device ( since we're talking about native apps).

Logically, a rest API is a layer that is one level "before" html/css, since it only deals with data, and not rendering ( html needs data, not the other way around). Since web and native use different rendering technologies, the logical conclusion is to keep the common part of the stack at the data level, and not one level above it.

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

#23

Post by zo1 »

carsongross wrote: post #16

I really wish that the browsers adopted a byte-code standard.(NB: JS with source maps is Yet Another Hack, doesn't count.) If we just had a bytecode and VM standard, along the lines of Java, we could all stop talking and go to hell in our own way.

I would vote for Python, if we were to pick one right now for such a thing.

I believe Guido (creator of Python) wrote a browser way back then, in Python. So naturally it had the capability of scripting the client-side via python.

In case someone is curious:

http://en.wikipedia.org/wiki/Grail_%28web_browser%29

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

#24

Post by mattdeboard »

jbergens wrote: post #20
mattdeboard wrote: post #4

Earlier quoted context omitted.

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…

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

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

#25

Post by chewxy »

I have complained about similar things way too much on twitter as well.

A VAST majority of websites on the web serve CONTENT. Why is JavaScript needed to serve content is really beyond me. You don't need to make your blog look and feel more webapp-y. It's a blog post. I want to read content. I don't use other features on your blog. Please just serve me the content and don't try to SPA that shit. Heck, I'd be willing to bet 99% of websites out there don't need to store session information to begin with - a static website would have served as well.

And most interactions on any website are not worthy of making it webapp-y anyway. Most websites with interactions will do well with minimal interactions anyway. Not every website needs to be real time. The existence of a listening loop in a lot of websites has caused my MacBook to crash more than I can care to count.

OK, sure, webapps like Asana and Gmail have good reasons to use and push the use of JavaScript forwards, but I really don't see why websites like AirBNB would require JavaScript. It's a bloody classifieds website. Out of the top 10 most visited websites I use, I can see only 3-4 of them really needing a fancy JS frontend. The others can get by with much much better UX if the JS in the frontend were kept to bare minimum.

Does JavaScript enhance the experience to the non-power users? I am not sure. Is not seeing the white flash when a page loads really that necessary to improving UX? I've definitely heard way too many complaints about JavaScript assisted scrolling amongst the non-tech acquaintences I have. I also have definitely heard complaints about bloated webapps that cause the entire computer to slow down.

The sad thing is with our modern browser technologies, we can be doing so much more, but webdevs tend to chase the fashionable, leading to generally poorer experience.

What's worse is our addiction to fashionable JavaScript things have caused us to design hacks on top of hacks on top of hacks. When will this madness end?

edit: fun stuff - according to htop, my Firefox, which has one tab open reading a blogspot page, is using about 12% of my memory. Amazing.

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

#26

Post by zo1 »

My biggest gripe with single-page apps is the lack of any sort of standard URL structure. With normal websites, even dynamic ones, you could pretty much put bookmarks almost everywhere. And the only times where you couldn't was probably in spots where the developers didn't want you to for some odd reason (say an intermediate page within a signup wizard).

But single-page apps completely break that. It then becomes some sort of hit/miss issue of whether or not that specific implementation of a single-page app's dynamic URL will behave nicely. Will it post, will it alter something, will it complain and just send me back to the main page? I don't know, and the URL doesn't necessarily tell me that.

Ironically, this is how I came across this post. I was trying to find valid/genuine criticism of single-page apps.

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

#27

Post by nacs »

zo1 wrote: post #26

My biggest gripe with single-page apps is the lack of any sort of standard URL structure. With normal websites, even dynamic ones, you could pretty much put bookmarks almost everywhere. And the only times where you couldn't was probably in spots where the developers didn't want you to for some odd reason (say an intermediate page within a signup wizard). But single-page apps completely break that. It then becomes som…

That's more a gripe with badly-designed SPAs than all SPAs however.

Many SPAs use the history API[1] to make a URL for everything -- Backbone, Angular[2] and such support this for example. React.js apps typically use some kind of router component that supports this (or they can use Backbone's Router).

[1]: http://diveintohtml5.info/history.html

[2]: https://docs.angularjs.org/guide/$location

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

#28

Post by igl »

I use webapps every day. I don't really have a problem with the majority of them and i do not run into most issues he described often. When he talked about mobile i got to think: Hey most of the native apps on my mobile suck! Awful UIs, crashes, "bookmarkable state?" forget about it! Calendar widget not loading any entries? Restart the device!

Javascript is not the killer platform. I got it. Can we stop complaining?

Also: 10+ years of experience - does not understand `this` ha.

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

#29

Post by javiercr »

chewxy wrote: post #25

I have complained about similar things way too much on twitter as well. A VAST majority of websites on the web serve CONTENT. Why is JavaScript needed to serve content is really beyond me. You don't need to make your blog look and feel more webapp-y. It's a blog post. I want to read content. I don't use other features on your blog. Please just serve me the content and don't try to SPA that shit. Heck, I'd be willing…

Airbnb has tons of things that would be impossible (or annoying to use) without JS: search by map, sliders, availability calendars, price calculation, credit card tokenization, etc.

Here is a recent talk where they explain how they solved some tricky UX problem by using a "modern" JS framework such as React.js

http://www.infoq.com/presentations/airbnb-resolution-center

In this other talk they also explain how (and why) they evolved from vanilla Rails (i.e. more static HTML) + jQuery, to Backbone, and finally to isomorphic React.js

https://www.youtube.com/watch?v=gMvvb6F8dgk

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

#30

Post by orangecat »

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…

Unicode support out of the box

utf16 support, which isn't the same thing: https://mathiasbynens.be/notes/javascript-unicode

easy manipulation of strings, arrays, and dictionaries

JS objects aren't dictionaries; all keys are coerced to strings, they lack basic operations like getting a list of keys or values, and iterating over keys can bite you if you forget hasOwnProperty.

Python comes pretty close, with slightly wonky scoping and Unicode bolted on

And equality operators that aren't utterly insane, a usable standard library, local rather than global scope by default, classes, namespaces, modules...

ES6 does look a like a large improvement. Mainly because it fixes misfeatures and adds capabilities that better languages dealt with years ago.

Post reply on HN