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

51–58 of 58 posts

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

#51

Post by findjashua »

chase-seibert wrote: post #44
findjashua wrote: post #42

Earlier quoted context omitted.

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.

True, coming from Backbone, I've run into my share of broken views, but we're beginning to see newer libraries, like React, that provide better abstractions and reduce the possibility of introducing bugs.

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

#52

Post by bikamonki »

jbergens wrote: post #21
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.

Yes and yes. I was exagerating to make a point and the tradeoff is control. However, unless you run a datacenter with a fat connection, you also give control to your vps/cloud providers. Now, if by control you mean having 'readable' logic exposed on the client, that is also true, but some services like parse.com offer cloud code.

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

#53

Post by bikamonki »

findjashua wrote: post #51
chase-seibert wrote: post #44

Earlier quoted context omitted.

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.

True, coming from Backbone, I've run into my share of broken views, but we're beginning to see newer libraries, like React, that provide better abstractions and reduce the possibility of introducing bugs.

I take it you've experienced the event-ghost nightmare or the parent-child view disaster? I've used bbjs 2yrs now and are also looking to try react. Have you? What bbjs problems does it solve? What do you miss from bbjs? I also understand the two are not strictly comparable: bbjs is mvc, react is v. Do you use react for views only?

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

#54

Post by gingerrr »

mattdeboard wrote: post #6
gingerrr wrote: post #3

can we stop conflating the presence of tons of bad practices in the wild with flaws in JS as a language? every language gives you ways to shoot yourself in the foot (c++ anyone?), if you choose to pull the trigger it's not the language's fault. i may not have been writing JS as long as this author (8 years to his 12) but I got over the ambiguity of `this` values 7 years ago. languages exist to provide a specific set…

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.

the fact that "javascript sucks" wasn't the point of the essay is EXACTLY my point - in an article that should be about calling out bad practices in designing web client experiences, there are judicious sprinklings of criticism of the underlying language, without attempting to distinguish those harms from the harms of bad choices in implementation. that sort of conflation is intellectually sloppy and ultimately leads to both sides 'reflexively' responding.

I'll definitely agree that javascript has room for improvement, but i'm not sure by what objective standard you're measuring its design chops. If you consider the goal of JS to be an incredibly flexible, light language with powerful runtime dynamicism and a strong focus on client-only needs, I'd say it's fairly well-designed. If you're holding it up against python as a server scripting language, it probably doesn't quite measure up. and if you're holding it up against all other languages and measuring by some 'general-purpose utility' ruler, that's a pretty pointless exercise - as I said in my original comment, languages are designed to solve specific problems, and JS is no exception.

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

#55

Post by gingerrr »

mattdeboard wrote: post #13
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…

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.

while the particular effectiveness of a runtime's GC is determined by the VM, JS the language doesn't provide operators or types to represent manual memory management - so it's a pretty core feature of the language that whatever VM it runs on will use garbage collection (or at the very least transparent automatic memory management) to reclaim memory.

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

#56

Post by mercer »

bikamonki wrote: post #53
findjashua wrote: post #51

Earlier quoted context omitted.

True, coming from Backbone, I've run into my share of broken views, but we're beginning to see newer libraries, like React, that provide better abstractions and reduce the possibility of introducing bugs.

I take it you've experienced the event-ghost nightmare or the parent-child view disaster? I've used bbjs 2yrs now and are also looking to try react. Have you? What bbjs problems does it solve? What do you miss from bbjs? I also understand the two are not strictly comparable: bbjs is mvc, react is v. Do you use react for views only?

React isn't just 'v', but you do generally want to use something alongside it that takes care of the data. I've had a great experience using the flux pattern with Reflux.js (which is one of the 'simpler' flux implementations.) Another interesting option is Baobab.js, although that still seems to be in heavy development.

I've also used flux with Ractive.js, which in some ways is perhaps an easier introduction into the flux/react approach. Might want to check that out.

I find it hard to describe how incredibly simpler everything is now that I don't use BB anymore. With some of the stuff that 'just works' in my current setup I can't even begin to think of a clean way to do in Backbone.

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

#57

Post by findjashua »

bikamonki wrote: post #53
findjashua wrote: post #51

Earlier quoted context omitted.

True, coming from Backbone, I've run into my share of broken views, but we're beginning to see newer libraries, like React, that provide better abstractions and reduce the possibility of introducing bugs.

I take it you've experienced the event-ghost nightmare or the parent-child view disaster? I've used bbjs 2yrs now and are also looking to try react. Have you? What bbjs problems does it solve? What do you miss from bbjs? I also understand the two are not strictly comparable: bbjs is mvc, react is v. Do you use react for views only?

@mercer pretty much nailed it - I use react+reflux, and it's made life a lot easier. If server-side html is important to you, check out flummox.

As for mvc, I would say react+reflux is more like mvvm than mvc. I don't miss anything from backbone and can't imagine going back, good riddance.

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

#58

Post by soulchild77 »

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

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…

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