14 ms·

JavaScript web apps considered valuable

138 points by bpierre 11y ago

falcolas 11y ago
I agree that Javascript web applications have a place. The problem is that the pendulum has swung too far, and folks are using Javascript everywhere. Static content generation on the client side, rendering non-interactive content, on the backend, in the build process, as a generic scripting language... the list goes on. We're watching programming and design concepts which played out back with Windows 95 being hailed as "the future of programming". We're being told "worse is better" as Javascript is being used to turn our computers against their users by serving as a vector for malware, ads, and bots. It's a mess, and it's going to take pushes from the far side of the pendulum's swing to bring it back to a sane place. If the pendulum was actually stalled too far towards "server side only", I'd agree that "server side only" articles would be too much - but we're not there. > We can only improve the user experience with the front-end technologies we have. No, we are more than capable of degrading the user experience with the front end technologies we have. There's a lot of proof of that on the web today. Delayed full page ads, pop-overs for every third word, hijacked scrollbars, malware installs...
- Wintamute 11y ago
  JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. It's no less deserving than any other language to be run on a server, as part of a build, generic scripts, whatever. Browser security issues arise because it's hard to resolve total user security across the public web coupled with highly interactive scriptable web pages ... its got nothing to do with the JavaScript language per se. It's fair enough to argue against the level of control scripts happen to have over the browser, but web page scripting could be implemented in <insert some other language here> and the same issues would be present. Your comment comes across as ignorant and prejudiced I'm afraid.
  - donatj 11y ago
    NPM and the community that surrounds it is a nightmare. I guess you could be talking about Bower but either way they are far from good,let alone best.
    - Wintamute 11y ago
      I was talking about npm. And I find the JS community welcoming, friendly and passionate and for the more serious npm modules out there highly technically literate, but hey it's a subjective thing I suppose :/
      - kuschku 11y ago
        So, the package manager that doesn’t do proper deduplication and, thanks to nested dependencies, runs over the file path length limit on multiple platforms?
        Silhouette 11y ago
        FYI, the nesting and deduplication were fixed in NPM 3. It uses a flat structure now. Unfortunately, in their place the version resolution algorithm is now subject to order dependency: the same package.json file, run at the same time with the same packages available in the NPM repository, can give different results on different machines depending on what had already been installed.
        paulddraper 11y ago
        Yep. Solved long file paths. All we had to give up was determinism!
        its2complicated 11y ago
        Ha ha, the effing path length limit drove me crazy! There'd be 50 node_modules folders and Windows wouldn't let you delete anything; It was nuts! I had to start renaming directories to "a", "b", "c", and so on until I cut the size down. I like JS for quick personal projects, but I'm glad I don't use it professionally anymore.
merb 11y ago
> Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc. Good that GMail is created with GWT. So it doesn't even use JavaScript. Most people are so afraid of JavaScript that they create hella crazy abstractions (Angularjs [Google], ReactJS [Facebook]) and even then Microsoft and Google trying to avoid JavaScript more and more with Typescript or Dart, they transpile it. JavaScript maybe is valuable in the web, but not in it's current form. So much quirks that you either spend using a library or fixing browser incompabilites. A lot of people here said that transpiling will be used a lot in the upcoming years, and I think that also. People will more and more. They want to use Python/Scala/Java/Whatever on both sides. Also it will reduce complexity by a lot. Currently your typical webapp has, a server-side technology (even if you are using node), then you have a web frontend which uses at least npm, however mostly you end up with npm, bower, gulp/grunt, webpack and whatever. > Client-server architectures instead of monoliths What about small teams? They can't split their monolith since it will become unmanageable. So if they have two apps, frontend/backend it's still a mess to manage these projects with a small team. > We need to stop excluding JavaScript apps from “the web as it was intended”. JavaScript apps are “of the web”, not just second-class citizens “on the web”. In my eyes JavaScript should be used where it is needed, but not used in stuff which never should touch it. JavaScript is still a mess.
- delambo 11y ago
  I think gmail was built using closure which is JavaScript. https://developers.google.com/closure/faq?hl=en#gwt https://developers.google.com/closure/faq?hl=en#gwt
- guscost 11y ago
  > Also it will reduce complexity by a lot. I have to disagree. Adding another layer of abstraction cannot reduce complexity, although it might make certain tasks easier. Consider assembly vs C as an example: C can make lots of programming tasks way easier, but the complexity of the system is not reduced. With C, this becomes apparent when the program segfaults. A garbage-collected language or Rust can prevent segfaults using a subsystem to manage and/or enforce memory ownership, again making lots of tasks easier, while adding even more complexity. In the case of transpile-to-JS languages, these can fix many of the shortcomings of JS and make lots of tasks easier, but they are a more complex system which can cause additional work if the generated code fails at run time, and the browser debugger brings up something completely different from your source code. Your point that we will see more transpiled languages in the future makes sense.
donatj 11y ago
> Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc. There is truly nothing about any of those that couldn't be done with a simple page refresh. Especially YouTube. Generally I find most of what JavaScript adds just irritating.
- ashark 11y ago
  I feel like Gmail reached a peak of Javascript use just slightly past what the basic-HTML version has, and everything since has just slowed it down and made it eat more RAM for little benefit. Sometime between then and now I'm sure they added some "helpful" frameworks that have contributed to the problem. Inbox is even worse. Our children won't believe we ever browsed the web in a graphical multitasking OS on 64mb of RAM and a single processor core. "Don't be silly, that wouldn't even be 1/6 enough to load Google Inbox!"
- esailija 11y ago
  That's hilariously clueless. Do you think youtube is just a <video> tag?
  - pikzen 11y ago
    Let's list Youtube's features that could be done with no Javascript * Displaying the video * Controlling the video (although with the browser's default controls) * Being logged in * Listing videos * Voting * Commenting * Suggested videos * Subscribing Actually, I can't see a single thing that can't be done without Javascript. It has no complex notification system aside from annotations (and I'm not sure anyone enjoys annotations), nothing that isn't provided by browsers. But no javascript would require page refreshes, which makes for a worse UX. Eh, we survived refreshes before. Maybe browsers could even agree on a standard to refresh only part of the pages by querying the server themselves. Throw in five lines of JS to save to localStorage the current time on the video and restore it on reload.
    - Touche 11y ago
TimJYoung 11y ago
This is what I tell potential customers that are evaluating our product that creates single-page web applications where the JS dynamically creates all content: if you want search engines to crawl the content, then you're not using the right product. It's a surprisingly easy decision when viewed in those terms. Most SAAS products that likely would be implemented as SPAs do not care about public search engine access, and are only used by B2B customers where you can dictate a certain minimum standard in terms of browser versions (IE). Everything else should be a traditional static web site with "decorative" JS, or "progressive enhancement".
- todd3834 11y ago
  Universal applications get the best of both worlds. That is why we created GlueStick https://github.com/TrueCar/gluestick/ https://github.com/TrueCar/gluestick/
- bphogan 11y ago
  Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. That said, the apps do need to remain accessible to those with screen readers, vision issues, motor impairments, and cognitive issues. They need to be accessible to those with slow or spotty connections. But search engine optimization is about content sites, not necessarily apps. Static pages are perfect for those cases, and I am thrilled to see more people coming around to that.
  - pikzen 11y ago
    >Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. So how's it going in JS land, are you guys still reimplementing Windows 3.1's message passing loop and hailing it as a revolution ? :^) Or maybe you're still busy pulling in literally 10+MBs of code on top of a 100+MB browser to fix the shortcomings of what is a terrible language ? Or maybe you're busy trying to get performances that matches what a 68060 could do thirty years ago. Oh right, browser vendors had to agree on WASM to get OK performance. So basically, not Javascript. But hey, I guess it's crossplatform. Kind of. But promised, once transpilers are good enough, once I can use a good, strongly staticly typed language, once the APIs are stable and the tooling becomes tolerable, I'll join the SPA side.
devit 11y ago
JavaScript web apps are fine, as long as they are "isomorphic", i.e. the front-end code is also run on the server and the resulting HTML is sent to the client, and as long as it's possible to at least navigate to and read all the content without having JavaScript enabled.
anupshinde 11y ago
I am a JS dev (after a lot of experience in statically typed languages) and just amazed to see the comments in this thread. At one end its experts(or near-experts) and at other end is just ignorants who probably did some $(...).show() and call it javascript. No wonder why its hard to hire good javascript developers. People just don't appreciate how wonderful this language is.
- Matachines 11y ago
  Way too many C#/Java developers who used JS in the early 2000s and hated it still think it's the same language.
  - EvanPlaice 11y ago
    I probably fall into the opposite category. Moved away from statically typed languages back when .NET 3.5 was released and have settled on JS primarily JS for the past few years. I'm wiling to bet C# is 10x better than the last time I used it. Except, I don't have a good excuse to use it again to see.
  - douche 11y ago
    Way too many C#/Java/Haskell/Python/Ruby/Scala developers still use it today and still think it's a heaping pile of garbage.
  - voltagex_ 11y ago
    The MS AJAX control toolkit and UpdatePanel probably didn't help, either. I think I can probably say that Javascript engines are an order of magnitude faster than they were 16 (!) years ago. If I may make a generalisation, C#/Java devs are more likely to be "enterprise" developers and said enterprises were more likely to be the ones on IE <11. I know I fought damn hard to upgrade from IE8 just a couple of years ago. My webdev skills suffered as a consequence, too. Microsoft moved pretty fast once they realised that IE needed to compete again - and Visual Studio evolved alongside it (mostly). VS2015 is now a pretty good development environment for Javascript/Typescript and even includes some Grunt build support (although I haven't had a play with it yet).
lhorie 11y ago
I generally agree with the article, but the examples of javascript web apps that were given seem weak: > Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc The web apps that I use the most day-to-day are Trello, Slack and Gitter. IMHO, those are better examples of js bringing actual value to the table that progressive enhancement simply cannot. With that being said, the issue of overusing SPA technology when it doesn't fit the need is definitely real. Part of the issue comes from people wanting to pad their resumes w/ experience in "hot" technology, or people who do have a genuine interest in improving their skills, but are not very skilled in identifying the pros and cons of whatever "new hotness" or "best practice" they read on their favorite news aggregators. By extension these creates an industry for grunt work to maintain/refactor/rewrite everchanging codebases/frameworks. Coupled with the general tendency of people to favor new shrink-wrapped libraries over doing good ol' painstaking research, it's difficult to reverse that trend.
- workitout 11y ago
  >> Trello, Slack and Gitter Never used them, are they important? What do they do? I've used all the ones cited as bad examples.
  - lhorie 11y ago
    For me they are tools for work and they are the web apps that I use the most every day (I work remotely). Trello is a task management system where you organize tasks as drag-n-drop "cards" and Slack/Gitter are chat apps (Slack is for company chat and Gitter is for my open source project community). I do use Youtube/Facebook/Twitter etc as well, but I use them primarily for content consumption for entertainment, so my usage patterns of those services wouldn't be affected much if they were written without using javascript at all. In contrast, drag-n-drop and the ability for real-time collaboration are the killer feature of Trello (for me), and obviously there's no way web chat would ever work smoothly without js.
XCSme 11y ago
I am a huge fan of JavaScript myself mostly because I found it very fun to work with and that you can do anything with it at the moment (websites, games, native mobile apps, smart TV apps, program raspberry pies and much more). About single page apps now: don't do a SPA if your website is not really an interactive application. Do you have a game, photo editor, P2P video chat? If yes, go ahead, SPA is really great for those things but for God's sake do not create a single page app when your website actually has more pages with different content and no interactivity. Why try to emulate how a browser works (loading, rendering, etc...) inside the browser itself?
__derek__ 11y ago
Henrik Joreteg has a related talk[1] and post[2] on the evolution of web apps that are worth checking out. [1]: https://speakerdeck.com/henrikjoreteg/the-evolution-of-the-web-app-fluentconf-2015 https://speakerdeck.com/henrikjoreteg/the-evolution-of-the-w... [2]: https://joreteg.com/blog/viability-of-js-frameworks-on-mobile https://joreteg.com/blog/viability-of-js-frameworks-on-mobil...
- sotojuan 11y ago
  Here's another good one: https://youtu.be/okk0BGV9oY0 https://youtu.be/okk0BGV9oY0
open-source-ux 11y ago
An unanswered question in this debate is: what is a web app and what is a web site? Sometimes the boundaries are blurry and sometimes they are clear. For example, should a blog rendered in the browser be treated as a web app? Or rendered principally as HTML and CSS before it's sent to the browser (rather than rendered in the browser using Javascript). Here's an example: over 300K of Javascript to render a plain text page: http://elm-lang.org/blog/new-adventures-for-elm http://elm-lang.org/blog/new-adventures-for-elm My impression is that some developers are beginning to treat anything rendered in the browser as a web app - even plain web pages with no dynamic elements. Why do developers do this? Is it because it makes their life easier using a single tool or language for both dynamic and static content? Or is it because they want to learn a new framework that's popular or interesting? Whatever the reason, one has to ask if giving users a good and fast site experience comes anywhere into the equation.
- paulddraper 11y ago
  "Is it because it makes their life easier using a single tool or language for both dynamic and static content?" Mostly this. As soon as you add a bit of dynamicism, it becomes easier to do everything in one language/workflow.
wcummings 11y ago
Am I the only one wondering what the fuck "progressive enhancement" is? Even the "enhanceconf" website doesn't explain. >We're convinced progressive enhancement remains an important aspect in pushing the boundaries of the web while still providing a robust experience for every user. What? EDIT: >Your HTML is not more accessible or more semantic when it’s rendered on the server. IDIOT DETECTOR TO FULL POWER. It is by definition more accessible if it doesn't require Javascript to render.
- saurik 11y ago
  https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Progressive_enhancement
dschiptsov 11y ago
Each time yet another hipster posts his unique snowflake insights about why we absolutely need yet another bloatware to build websites on this vey site (which is just static html pages over an FS storage in less than MB of code, including a dialect of Lisp and related DSLs) a kitten dies somewhere.

138 points by bpierre 11y ago

I agree that Javascript web applications have a place. The problem is that the pendulum has swung too far, and folks are using Javascript everywhere. Static content generation on the client side, rendering non-interactive content, on the backend, in the build process, as a generic scripting language... the list goes on. We're watching programming and design concepts which played out back with Windows 95 being hailed as "the future of programming". We're being told "worse is better" as Javascript is being used to turn our computers against their users by serving as a vector for malware, ads, and bots. It's a mess, and it's going to take pushes from the far side of the pendulum's swing to bring it back to a sane place. If the pendulum was actually stalled too far towards "server side only", I'd agree that "server side only" articles would be too much - but we're not there. > We can only improve the user experience with the front-end technologies we have. No, we are more than capable of degrading the user experience with the front end technologies we have. There's a lot of proof of that on the web today. Delayed full page ads, pop-overs for every third word, hijacked scrollbars, malware installs...

Wintamute 11y ago
JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. It's no less deserving than any other language to be run on a server, as part of a build, generic scripts, whatever. Browser security issues arise because it's hard to resolve total user security across the public web coupled with highly interactive scriptable web pages ... its got nothing to do with the JavaScript language per se. It's fair enough to argue against the level of control scripts happen to have over the browser, but web page scripting could be implemented in <insert some other language here> and the same issues would be present. Your comment comes across as ignorant and prejudiced I'm afraid.
- donatj 11y ago
  NPM and the community that surrounds it is a nightmare. I guess you could be talking about Bower but either way they are far from good,let alone best.
  - Wintamute 11y ago
    I was talking about npm. And I find the JS community welcoming, friendly and passionate and for the more serious npm modules out there highly technically literate, but hey it's a subjective thing I suppose :/
    - kuschku 11y ago
      So, the package manager that doesn’t do proper deduplication and, thanks to nested dependencies, runs over the file path length limit on multiple platforms?
      - Silhouette 11y ago
        FYI, the nesting and deduplication were fixed in NPM 3. It uses a flat structure now. Unfortunately, in their place the version resolution algorithm is now subject to order dependency: the same package.json file, run at the same time with the same packages available in the NPM repository, can give different results on different machines depending on what had already been installed.
        paulddraper 11y ago
        Yep. Solved long file paths. All we had to give up was determinism!
      - its2complicated 11y ago
        Ha ha, the effing path length limit drove me crazy! There'd be 50 node_modules folders and Windows wouldn't let you delete anything; It was nuts! I had to start renaming directories to "a", "b", "c", and so on until I cut the size down. I like JS for quick personal projects, but I'm glad I don't use it professionally anymore.

merb 11y ago

> Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc. Good that GMail is created with GWT. So it doesn't even use JavaScript. Most people are so afraid of JavaScript that they create hella crazy abstractions (Angularjs [Google], ReactJS [Facebook]) and even then Microsoft and Google trying to avoid JavaScript more and more with Typescript or Dart, they transpile it. JavaScript maybe is valuable in the web, but not in it's current form. So much quirks that you either spend using a library or fixing browser incompabilites. A lot of people here said that transpiling will be used a lot in the upcoming years, and I think that also. People will more and more. They want to use Python/Scala/Java/Whatever on both sides. Also it will reduce complexity by a lot. Currently your typical webapp has, a server-side technology (even if you are using node), then you have a web frontend which uses at least npm, however mostly you end up with npm, bower, gulp/grunt, webpack and whatever. > Client-server architectures instead of monoliths What about small teams? They can't split their monolith since it will become unmanageable. So if they have two apps, frontend/backend it's still a mess to manage these projects with a small team. > We need to stop excluding JavaScript apps from “the web as it was intended”. JavaScript apps are “of the web”, not just second-class citizens “on the web”. In my eyes JavaScript should be used where it is needed, but not used in stuff which never should touch it. JavaScript is still a mess.

delambo 11y ago
I think gmail was built using closure which is JavaScript. https://developers.google.com/closure/faq?hl=en#gwt https://developers.google.com/closure/faq?hl=en#gwt
guscost 11y ago
> Also it will reduce complexity by a lot. I have to disagree. Adding another layer of abstraction cannot reduce complexity, although it might make certain tasks easier. Consider assembly vs C as an example: C can make lots of programming tasks way easier, but the complexity of the system is not reduced. With C, this becomes apparent when the program segfaults. A garbage-collected language or Rust can prevent segfaults using a subsystem to manage and/or enforce memory ownership, again making lots of tasks easier, while adding even more complexity. In the case of transpile-to-JS languages, these can fix many of the shortcomings of JS and make lots of tasks easier, but they are a more complex system which can cause additional work if the generated code fails at run time, and the browser debugger brings up something completely different from your source code. Your point that we will see more transpiled languages in the future makes sense.

donatj 11y ago

> Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc. There is truly nothing about any of those that couldn't be done with a simple page refresh. Especially YouTube. Generally I find most of what JavaScript adds just irritating.

ashark 11y ago
I feel like Gmail reached a peak of Javascript use just slightly past what the basic-HTML version has, and everything since has just slowed it down and made it eat more RAM for little benefit. Sometime between then and now I'm sure they added some "helpful" frameworks that have contributed to the problem. Inbox is even worse. Our children won't believe we ever browsed the web in a graphical multitasking OS on 64mb of RAM and a single processor core. "Don't be silly, that wouldn't even be 1/6 enough to load Google Inbox!"
esailija 11y ago
That's hilariously clueless. Do you think youtube is just a <video> tag?
- pikzen 11y ago
  Let's list Youtube's features that could be done with no Javascript * Displaying the video * Controlling the video (although with the browser's default controls) * Being logged in * Listing videos * Voting * Commenting * Suggested videos * Subscribing Actually, I can't see a single thing that can't be done without Javascript. It has no complex notification system aside from annotations (and I'm not sure anyone enjoys annotations), nothing that isn't provided by browsers. But no javascript would require page refreshes, which makes for a worse UX. Eh, we survived refreshes before. Maybe browsers could even agree on a standard to refresh only part of the pages by querying the server themselves. Throw in five lines of JS to save to localStorage the current time on the video and restore it on reload.
  - Touche 11y ago

TimJYoung 11y ago

This is what I tell potential customers that are evaluating our product that creates single-page web applications where the JS dynamically creates all content: if you want search engines to crawl the content, then you're not using the right product. It's a surprisingly easy decision when viewed in those terms. Most SAAS products that likely would be implemented as SPAs do not care about public search engine access, and are only used by B2B customers where you can dictate a certain minimum standard in terms of browser versions (IE). Everything else should be a traditional static web site with "decorative" JS, or "progressive enhancement".

todd3834 11y ago
Universal applications get the best of both worlds. That is why we created GlueStick https://github.com/TrueCar/gluestick/ https://github.com/TrueCar/gluestick/
bphogan 11y ago
Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. That said, the apps do need to remain accessible to those with screen readers, vision issues, motor impairments, and cognitive issues. They need to be accessible to those with slow or spotty connections. But search engine optimization is about content sites, not necessarily apps. Static pages are perfect for those cases, and I am thrilled to see more people coming around to that.
- pikzen 11y ago
  >Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. So how's it going in JS land, are you guys still reimplementing Windows 3.1's message passing loop and hailing it as a revolution ? :^) Or maybe you're still busy pulling in literally 10+MBs of code on top of a 100+MB browser to fix the shortcomings of what is a terrible language ? Or maybe you're busy trying to get performances that matches what a 68060 could do thirty years ago. Oh right, browser vendors had to agree on WASM to get OK performance. So basically, not Javascript. But hey, I guess it's crossplatform. Kind of. But promised, once transpilers are good enough, once I can use a good, strongly staticly typed language, once the APIs are stable and the tooling becomes tolerable, I'll join the SPA side.

devit 11y ago

JavaScript web apps are fine, as long as they are "isomorphic", i.e. the front-end code is also run on the server and the resulting HTML is sent to the client, and as long as it's possible to at least navigate to and read all the content without having JavaScript enabled.

anupshinde 11y ago

I am a JS dev (after a lot of experience in statically typed languages) and just amazed to see the comments in this thread. At one end its experts(or near-experts) and at other end is just ignorants who probably did some $(...).show() and call it javascript. No wonder why its hard to hire good javascript developers. People just don't appreciate how wonderful this language is.

Matachines 11y ago
Way too many C#/Java developers who used JS in the early 2000s and hated it still think it's the same language.
- EvanPlaice 11y ago
  I probably fall into the opposite category. Moved away from statically typed languages back when .NET 3.5 was released and have settled on JS primarily JS for the past few years. I'm wiling to bet C# is 10x better than the last time I used it. Except, I don't have a good excuse to use it again to see.
- douche 11y ago
  Way too many C#/Java/Haskell/Python/Ruby/Scala developers still use it today and still think it's a heaping pile of garbage.
- voltagex_ 11y ago
  The MS AJAX control toolkit and UpdatePanel probably didn't help, either. I think I can probably say that Javascript engines are an order of magnitude faster than they were 16 (!) years ago. If I may make a generalisation, C#/Java devs are more likely to be "enterprise" developers and said enterprises were more likely to be the ones on IE <11. I know I fought damn hard to upgrade from IE8 just a couple of years ago. My webdev skills suffered as a consequence, too. Microsoft moved pretty fast once they realised that IE needed to compete again - and Visual Studio evolved alongside it (mostly). VS2015 is now a pretty good development environment for Javascript/Typescript and even includes some Grunt build support (although I haven't had a play with it yet).

lhorie 11y ago

I generally agree with the article, but the examples of javascript web apps that were given seem weak: > Most web apps I work with daily have highly sophisticated in-browser interactions that are built with JavaScript and can only be built with JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc The web apps that I use the most day-to-day are Trello, Slack and Gitter. IMHO, those are better examples of js bringing actual value to the table that progressive enhancement simply cannot. With that being said, the issue of overusing SPA technology when it doesn't fit the need is definitely real. Part of the issue comes from people wanting to pad their resumes w/ experience in "hot" technology, or people who do have a genuine interest in improving their skills, but are not very skilled in identifying the pros and cons of whatever "new hotness" or "best practice" they read on their favorite news aggregators. By extension these creates an industry for grunt work to maintain/refactor/rewrite everchanging codebases/frameworks. Coupled with the general tendency of people to favor new shrink-wrapped libraries over doing good ol' painstaking research, it's difficult to reverse that trend.

workitout 11y ago
>> Trello, Slack and Gitter Never used them, are they important? What do they do? I've used all the ones cited as bad examples.
- lhorie 11y ago
  For me they are tools for work and they are the web apps that I use the most every day (I work remotely). Trello is a task management system where you organize tasks as drag-n-drop "cards" and Slack/Gitter are chat apps (Slack is for company chat and Gitter is for my open source project community). I do use Youtube/Facebook/Twitter etc as well, but I use them primarily for content consumption for entertainment, so my usage patterns of those services wouldn't be affected much if they were written without using javascript at all. In contrast, drag-n-drop and the ability for real-time collaboration are the killer feature of Trello (for me), and obviously there's no way web chat would ever work smoothly without js.

XCSme 11y ago

I am a huge fan of JavaScript myself mostly because I found it very fun to work with and that you can do anything with it at the moment (websites, games, native mobile apps, smart TV apps, program raspberry pies and much more). About single page apps now: don't do a SPA if your website is not really an interactive application. Do you have a game, photo editor, P2P video chat? If yes, go ahead, SPA is really great for those things but for God's sake do not create a single page app when your website actually has more pages with different content and no interactivity. Why try to emulate how a browser works (loading, rendering, etc...) inside the browser itself?

__derek__ 11y ago

Henrik Joreteg has a related talk[1] and post[2] on the evolution of web apps that are worth checking out. [1]: https://speakerdeck.com/henrikjoreteg/the-evolution-of-the-web-app-fluentconf-2015 https://speakerdeck.com/henrikjoreteg/the-evolution-of-the-w... [2]: https://joreteg.com/blog/viability-of-js-frameworks-on-mobile https://joreteg.com/blog/viability-of-js-frameworks-on-mobil...

sotojuan 11y ago
Here's another good one: https://youtu.be/okk0BGV9oY0 https://youtu.be/okk0BGV9oY0

open-source-ux 11y ago

An unanswered question in this debate is: what is a web app and what is a web site? Sometimes the boundaries are blurry and sometimes they are clear. For example, should a blog rendered in the browser be treated as a web app? Or rendered principally as HTML and CSS before it's sent to the browser (rather than rendered in the browser using Javascript). Here's an example: over 300K of Javascript to render a plain text page: http://elm-lang.org/blog/new-adventures-for-elm http://elm-lang.org/blog/new-adventures-for-elm My impression is that some developers are beginning to treat anything rendered in the browser as a web app - even plain web pages with no dynamic elements. Why do developers do this? Is it because it makes their life easier using a single tool or language for both dynamic and static content? Or is it because they want to learn a new framework that's popular or interesting? Whatever the reason, one has to ask if giving users a good and fast site experience comes anywhere into the equation.

paulddraper 11y ago
"Is it because it makes their life easier using a single tool or language for both dynamic and static content?" Mostly this. As soon as you add a bit of dynamicism, it becomes easier to do everything in one language/workflow.

wcummings 11y ago

Am I the only one wondering what the fuck "progressive enhancement" is? Even the "enhanceconf" website doesn't explain. >We're convinced progressive enhancement remains an important aspect in pushing the boundaries of the web while still providing a robust experience for every user. What? EDIT: >Your HTML is not more accessible or more semantic when it’s rendered on the server. IDIOT DETECTOR TO FULL POWER. It is by definition more accessible if it doesn't require Javascript to render.

saurik 11y ago
https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Progressive_enhancement

dschiptsov 11y ago

Each time yet another hipster posts his unique snowflake insights about why we absolutely need yet another bloatware to build websites on this vey site (which is just static html pages over an FS storage in less than MB of code, including a dialect of Lisp and related DSLs) a kitten dies somewhere.