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

41–50 of 58 posts

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

#41

Post by georgemcbay »

In an ideal world right now would be just about the perfect time to introduce a real virtual machine (as a first class citizen with full DOM access rather than forcing it to live inside a display box) into the the browser space (including mobile browsers) rather than continuing to rely on a spotty designed-in-two-weeks (at least according to Netscape lore) language that is often (badly) used as a virtual machine.

I can't imagine it will actually happen for a few reasons, chief among them being browser vendor politics and the lingering taste of the failure of Java applets... but it would be nice.

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

#42

Post by findjashua »

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…

I would have to disagree here for 2 main reasons:

1. The vast majority of content I consume is, in fact, not static content, the only exceptions being HN and my bank statements. For almost everything else, I much prefer the interactive experience made possible by an SPA. This includes anything with a map (Yelp, Airbnb, Redfin), charts (google analytics), autocomplete (stack overflow) or chatting (google hangouts).

2. All SPAs are not the same - for every 10 second-load monstrosity (gmail), you have someone sending the markup from the server on the first load (airbnb)

With the explosion of mobile apps, people have a certain level of expectation in terms of UX, and a static site won't always meet those expectations.

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

#43

Post by masoudd »

josephagoss wrote: post #35

> The basic idea is that your app should be fully functional even if Javascript is disabled. Honest question, is this really possible? I write webapps and Javascript + Jquery makes a lot of stuff easy, hooking into button clicks, getting text from an input box and sending AJAX requests back to my server. Does anyone have an example of a web application with no Javascript? My next project will most likely use Golang a…

>Just being told I can replicate my application in html and css isn't helping.

You can't. But do you really need to? Couldn't your webpage work without suggestions popping up as query is typed into the input box? Your webpage should not stop working if you can't validate user input client side, etc... .

See:

http://en.wikipedia.org/wiki/Progressive_enhancement

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

#44

Post by chase-seibert »

findjashua wrote: post #42
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…

I would have to disagree here for 2 main reasons: 1. The vast majority of content I consume is, in fact, not static content, the only exceptions being HN and my bank statements. For almost everything else, I much prefer the interactive experience made possible by an SPA. This includes anything with a map (Yelp, Airbnb, Redfin), charts (google analytics), autocomplete (stack overflow) or chatting (google hangouts). 2.…

I agree. I value what javascript enables for those experience as well. I just wish more sites could implement those useful pieces and still get all the basic interactions correct. Too often, those are broken, I assume due to ignorance.

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

#45

Post by chase-seibert »

mattdeboard wrote: post #9
TheAceOfHearts wrote: post #7

Earlier quoted context omitted.

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

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

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

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

#46

Post by chase-seibert »

callum85 wrote: post #39
josephagoss wrote: post #35

> The basic idea is that your app should be fully functional even if Javascript is disabled. Honest question, is this really possible? I write webapps and Javascript + Jquery makes a lot of stuff easy, hooking into button clicks, getting text from an input box and sending AJAX requests back to my server. Does anyone have an example of a web application with no Javascript? My next project will most likely use Golang a…

> Honest question, is this really possible? Yes, loads of things work without JS. You can use Wikipedia, even to edit articles, with JS disabled – it's all simple HTML forms. JS just makes the experience smoother (adding buttons to help with WikiText formatting, etc). Most content and shopping websites work fine without JS. You asked how do you fire off AJAX requests without JS? You don't. You just design your app so…

Certainly a number of common interactions are not currently possible (or at least not optimal) without being able to use JS. Maybe some day we can get to a place with web components where many of those common patterns can be implemented with plain old HTML again.

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

#47

Post by chase-seibert »

orangecat wrote: post #30
dgreensp wrote: post #10

Earlier quoted context omitted.

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

ES6 admittedly borrowed a lot from Python. I just wish Guido had been successful getting Python supported as a first class language in Chrome; that might have actually given us a choice in the browser. Even then, I find it hard to imagine that ALL other browsers would have followed suit.

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

#48

Post by nostrademons »

josephagoss wrote: post #35

> The basic idea is that your app should be fully functional even if Javascript is disabled. Honest question, is this really possible? I write webapps and Javascript + Jquery makes a lot of stuff easy, hooking into button clicks, getting text from an input box and sending AJAX requests back to my server. Does anyone have an example of a web application with no Javascript? My next project will most likely use Golang a…

The idea behind progressive enhancement is that you prioritize your features, and then make the most fundamental features of your site work without Javascript while still giving JS-enabled users something extra to play with.

So in your example - no, you would not send AJAX requests back to the server in a real-time search application. It would not be "real time" at all. But you would still be able to search, and get back results. Then you add JS, and you can search as you type.

Relatively few sites do it like this these days - in general, anything that's a SPA that talks to JSON won't work at all with JS disabled. It takes a good understanding of your tools and of your users to prioritize like this, as well as a good dose of humility. But it also often results in better usability and UX design overall, because you know which features are really key and which are "nice to haves", and you don't compromise key features for extras.

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

#49

Post by [deleted] »

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…

[deleted]

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

#50

Post by vegedor »

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…

If the back-end serves javascript combined with the HTML, then you get a problem on iOS, because apple doesn't allow loading code, i guess.
Post reply on HN