6 ms·

Rich client side web apps gone too far (2014)

65 points by zo1 12y ago

carsongross 12y ago
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.
- zo1 12y ago
  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 http://en.wikipedia.org/wiki/Grail_%28web_browser%29
woah 12y ago
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.
- mattdeboard 12y ago
  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.
  - TheAceOfHearts 12y ago
    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.)
    - mattdeboard 12y ago
      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. [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
      - chase-seibert 12y ago
        +1 I think that React.js is actually a much better model, closer to how you would render full page renders on the server.
    - soulchild77 12y ago
      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.
gingerrr 12y ago
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 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
- mattdeboard 12y ago
  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.
  - dgreensp 12y ago
    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.
    - mattdeboard 12y ago
      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.
bsaul 12y ago
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.
- QuantumRoar 12y ago
  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.
  - lucian1900 12y ago
    > 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.
  - bsaul 12y ago
    "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.
  - vegedor 12y ago
    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.
bikamonki 12y ago
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.
- mslate 12y ago
  What is "BASS"?
  - bikamonki 12y ago
    BAAS -> Backend as a service. For example: parse.com or firebase.com * It was mispelled, fixed it already
- jbergens 12y ago
  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.
  - bikamonki 12y ago
    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.
dgreensp 12y ago
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).
carsongross 12y ago
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.
- gradstudent 12y ago
  > 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. JavaScript is a clusterfuck. More Javascript is not the answer.
  - carsongross 12y ago
    Which is exactly why intercooler.js uses plain HTML attributes, rather than javascript: http://intercoolerjs.org/ http://intercoolerjs.org/
    - curiously 12y ago
      very cool! although I feel more comfortable with using jQuery for posting.
cromwellian 12y ago
"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.
chewxy 12y ago
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.
- javiercr 12y ago
  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 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 https://www.youtube.com/watch?v=gMvvb6F8dgk
zo1 12y ago
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.
- nacs 12y ago
  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 http://diveintohtml5.info/history.html [2]: https://docs.angularjs.org/guide/$location https://docs.angularjs.org/guide/$location
igl 12y ago
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.
bottled_poe 12y ago
I remember reading javascript for the first time some years ago. It was hate at first sight. Why are there so many ways to write the same thing? Why is this forsaken language so horrible to read? Compiler support? Type system? Debugging tools? Someone needs to clean up this mess. As long as javascript is the dominant web client programming language, the browser will continue to be the platform of the future, but never the present.
josephagoss 12y ago
> 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 as the server side, and I'm having a really hard time imagining how to send AJAX requests back to the server on user events (such as the user typing into a box in a real time search application) without using Javascript. Apparently I've missed a whole area of web development if this is all possible with no Javascript. Isn't this like saying your Windows game should be fully functional without a graphics card? I mean, on most web applications, they are that, applications. Maybe I just don't know enough, but I feel like I need a programming language in the browser to create the client side of the application, how do I fire off AJAX events when a user types something without Javascript? I'm honestly trying to learn more here, I need examples of web apps with no Javascript, I need a book or something. Just being told I can replicate my application in html and css isn't helping.
- callum85 12y ago
  > 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 it basically works as a set of HTML pages connected by hyperlinks and form submissions. Then you add JS to enhance things. > Apparently I've missed a whole area of web development if this is all possible with no Javascript. Yes you have. When I started (~12 years ago), JS was only used for little whizzy effects here and there, not much else. Then JS started becoming more viable due to prototype and jQuery, but it was always the most flakey part of web development, and we learned to use it cautiously as an optional layer of enhancement. You couldn't rely on it always working. It was a way to 'differentiate' your site, not a serious building block. Now, everything has changed, JS is everywhere and we tend to call things 'apps' more than 'sites'. I spend 70% of my day writing JS. I'm not sure if I agree with the JS-bashing sentiment of the article. But I do think it's still good practice to design your app so it delivers your core content/functionality without JS. Most stuff (blogs, e-commerce, forums, etc) can be built like this. (Admittedly some things like p2p streaming apps just can't.) Then you can use JS to enhance things, like enhancing your basic search form with as-you-type suggestions. This approach makes your codebase more structurally sound and less entangled, and makes your app more resilient.
curiously 12y ago
There's so much frontend jobs now that as much as I hate it and no it's wrong, I am forced to learn it to keep up. There's just no choice. The stakeholders have decided suddenly JS is the new way to write apps, these type of people won't know how to code if you put a gun to their heads, even worse are developers refusing to use conventional tools like PHP or Python or Ruby for writing server backends. I've never forced JS or SPA on someone that had no place for it but unfortunately they are willing to pay more to have it rewritten in JS.
georgemcbay 12y ago
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.

65 points by zo1 12y ago

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.

zo1 12y ago
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 http://en.wikipedia.org/wiki/Grail_%28web_browser%29

woah 12y ago

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.

mattdeboard 12y ago
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.
- TheAceOfHearts 12y ago
  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.)
  - mattdeboard 12y ago
    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. [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
    - chase-seibert 12y ago
      +1 I think that React.js is actually a much better model, closer to how you would render full page renders on the server.
  - soulchild77 12y ago
    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.

gingerrr 12y ago

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

mattdeboard 12y ago
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.
- dgreensp 12y ago
  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.
  - mattdeboard 12y ago
    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.

bsaul 12y ago

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.

QuantumRoar 12y ago
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.
- lucian1900 12y ago
  > 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.
- bsaul 12y ago
  "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.
- vegedor 12y ago
  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.

bikamonki 12y ago

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.

mslate 12y ago
What is "BASS"?
- bikamonki 12y ago
  BAAS -> Backend as a service. For example: parse.com or firebase.com * It was mispelled, fixed it already
jbergens 12y ago
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.
- bikamonki 12y ago
  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.

dgreensp 12y ago

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

carsongross 12y ago

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.

gradstudent 12y ago
> 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. JavaScript is a clusterfuck. More Javascript is not the answer.
- carsongross 12y ago
  Which is exactly why intercooler.js uses plain HTML attributes, rather than javascript: http://intercoolerjs.org/ http://intercoolerjs.org/
  - curiously 12y ago
    very cool! although I feel more comfortable with using jQuery for posting.

cromwellian 12y ago

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

chewxy 12y ago

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.

javiercr 12y ago
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 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 https://www.youtube.com/watch?v=gMvvb6F8dgk

zo1 12y ago

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.

nacs 12y ago
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 http://diveintohtml5.info/history.html [2]: https://docs.angularjs.org/guide/$location https://docs.angularjs.org/guide/$location

igl 12y ago

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.

bottled_poe 12y ago

I remember reading javascript for the first time some years ago. It was hate at first sight. Why are there so many ways to write the same thing? Why is this forsaken language so horrible to read? Compiler support? Type system? Debugging tools? Someone needs to clean up this mess. As long as javascript is the dominant web client programming language, the browser will continue to be the platform of the future, but never the present.

josephagoss 12y ago

> 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 as the server side, and I'm having a really hard time imagining how to send AJAX requests back to the server on user events (such as the user typing into a box in a real time search application) without using Javascript. Apparently I've missed a whole area of web development if this is all possible with no Javascript. Isn't this like saying your Windows game should be fully functional without a graphics card? I mean, on most web applications, they are that, applications. Maybe I just don't know enough, but I feel like I need a programming language in the browser to create the client side of the application, how do I fire off AJAX events when a user types something without Javascript? I'm honestly trying to learn more here, I need examples of web apps with no Javascript, I need a book or something. Just being told I can replicate my application in html and css isn't helping.

callum85 12y ago
> 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 it basically works as a set of HTML pages connected by hyperlinks and form submissions. Then you add JS to enhance things. > Apparently I've missed a whole area of web development if this is all possible with no Javascript. Yes you have. When I started (~12 years ago), JS was only used for little whizzy effects here and there, not much else. Then JS started becoming more viable due to prototype and jQuery, but it was always the most flakey part of web development, and we learned to use it cautiously as an optional layer of enhancement. You couldn't rely on it always working. It was a way to 'differentiate' your site, not a serious building block. Now, everything has changed, JS is everywhere and we tend to call things 'apps' more than 'sites'. I spend 70% of my day writing JS. I'm not sure if I agree with the JS-bashing sentiment of the article. But I do think it's still good practice to design your app so it delivers your core content/functionality without JS. Most stuff (blogs, e-commerce, forums, etc) can be built like this. (Admittedly some things like p2p streaming apps just can't.) Then you can use JS to enhance things, like enhancing your basic search form with as-you-type suggestions. This approach makes your codebase more structurally sound and less entangled, and makes your app more resilient.

curiously 12y ago

There's so much frontend jobs now that as much as I hate it and no it's wrong, I am forced to learn it to keep up. There's just no choice. The stakeholders have decided suddenly JS is the new way to write apps, these type of people won't know how to code if you put a gun to their heads, even worse are developers refusing to use conventional tools like PHP or Python or Ruby for writing server backends. I've never forced JS or SPA on someone that had no place for it but unfortunately they are willing to pay more to have it rewritten in JS.

georgemcbay 12y ago

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.