Rich client side web apps gone too far (2014)
chase-seibert.github.io
Rich client side web apps gone too far (2014)
1–10 of 58 posts
Re: Rich client side web apps gone too far (2014)
#2Huh... 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.
Re: Rich client side web apps gone too far (2014)
#3can 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 of functionality - in this case, dynamic scope resolution - it's frustrating to see bad design choices in app code blamed on the language. vm authors are open with the optimizations they're making, just write your JS to leverage that performance gain
Re: Rich client side web apps gone too far (2014)
#4Huh... 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 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.
Re: Rich client side web apps gone too far (2014)
#5He 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.
Re: Rich client side web apps gone too far (2014)
#6can 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.
Re: Rich client side web apps gone too far (2014)
#7Huh... 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…
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.)
Re: Rich client side web apps gone too far (2014)
#8He 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 write an app that renders HTML and CSS that's served by a server, right?
I get that it seems sane to make an app out of your website when you already have an app for phones. But you must recognize that the web is really something else than a native program. And if you want to do it right, you need to treat every platform individually.
Re: Rich client side web apps gone too far (2014)
#9Earlier 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…
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.
Re: Rich client side web apps gone too far (2014)
#10can 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.
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 first-class function closures, high-performance garbage collection, and easy manipulation of strings, arrays, and dictionaries, for example. Python comes pretty close, with slightly wonky scoping and Unicode bolted on, but then JavaScript also has another Python doesn't, which is a spec with multiple first-class implementations, and not to mention a committee that is plotting a great path forwards into the future with fully backwards-compatible upgrades to the language.