6 ms·

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

by 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.
- Dr_tldr 11y ago
  So what you're saying is you don't know very much about JavaScript but you're willing to learn some once it becomes obsolete like Java?
  - pikzen 11y ago
    Stable and field tested, with a majority of the marketshare, as opposed to using the flavour of the day because that's what's hip? Where do I sign up ? I mean, I do C# day to day, so boring is perfect :) Also, much to my dismay, I do try things outs, maybe not extensively, but enough, before criticizing them. I've used Angular, React, Ember, JQuery (yes, working on a 100% jquery SPA. It's as fun as you can imagine), then other things like Vue.js, Knockout, and quite a few more. Even Vanilla JS. So, while I will not pretend to be an expert, or even having advanced knowledge of Javascript, I'd like to think I kind of know what I'm talking about.
    - Dr_tldr 11y ago
      That's good to know, and I promise I wasn't (just) being snarky! The problem is that unless you're working with something low-level like C, by the time it's stable and field tested, the language has also gotten kind of brittle, there's a mountain of bad code, and new features don't undo the damage done by the bad patterns of the past. Javascript also has mountains of bad code and bad practices, but a lot of it's being accumulated in frameworks which are getting created, tested, found wanting, then dropped, with the good parts surviving on, either in new frameworks or as part of the standard. I won't lie though, I'm as framework exhausted as everyone else right now and it can't go on like this for much longer. Using something like C# (which I see as "good Java") would be a nice change of pace. Definitely check out Ampersand and Webpack with React, they're kind of coalescing to provide a saner, "use only what you need" approach.
- bphogan 11y ago
  I agree with all of those points. But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. So what are ya gonna do? See, I hate JS. I think it's terrible. If there were any other choices out there, I don't even think it would still be a thing if there were any other options. But it's a requirement of a modern web developer to know how to do it well. And I'm a web developer. So I'm going to be good at it. At least as good as I can be given the tools I use and constraints I have.
  - simi_ 11y ago
    > But meeting the needs of customers is what I get paid to do That was like being slapped with a good dose of pragmatism – I love it! Wrt the later part of your post, try Dart. It's annoying in entirely new ways, but it does away with a lot of JS pains; it's also mature, powerful, and production-oriented. It even comes with a VM to run it in, so you can pretend it's a real –boy– language. Its obscurity also means that it can be hard to come across help/tools (emacs completion, anyone?), but despite all the shortcomings I enjoy using it, and am happy to back Google's bet on Dart.
    - bphogan 11y ago
      Thanks for the recommendation. I'm currently annoying myself by learning Elm. :)
  - M2Ys4U 11y ago
    > But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. >So what are ya gonna do? Both. Do the initial render (well, HTML generation) server-side, and update the state client-side when the user performs an action (or receives an event from the server). Use real, accessible URLs for links, and use pushState when updating client-side.
    - bphogan 11y ago
      I'd love to see books, screencasts, or tutorials that talk about doing this beyond the very trivial. I hear people talk about it, but whenever I ask, they can't show me code because reasons. This makes me skeptical. And based on what I see in the wild... lots of loading progress bars, etc, I don't see widespread use of this technique.
- icebraining 11y ago
  This post is dangerously approaching flamebait.
  - douche 11y ago
    Doesn't necessarily make it false... JS is such a piss-poor language. I'd rather write QBASIC if it ran in a browser.
    - estefan 11y ago
      Agreed, but ES6 is a big improvement. I've just gone back to it and I must admit, it's not actually too bad now if you use babel + webpack.
    - illicium 11y ago
      >QBASIC if it ran in a browser http://tayeandjoe.com/qbarcade/games/qbasic.html http://tayeandjoe.com/qbarcade/games/qbasic.html
- TimJYoung 11y ago
  This is probably going to send this whole thread on a wild tangent, but here goes... I've posted this before, but check out this link: http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html That app was created with our web development product (check the site if you want to know more), and has the following characteristics: Two files, one HTML loader and one monolithic JS app, so latency during loading is minimal. The HTML loader is ~189K and the JS app is ~462K, and includes the entire runtime and UI layer, and a lot of the control/component library. Both the HTML and JS are aggressively compressed/obfuscated by a compiler, and the coding is done in a statically-typed, OO/procedural language with RTTI and other nice things. The UI was designed using a WYSIWYG designer with two-way tools (code-behind). So, there are products/tools out there that will do something along the lines of what you want. And the existing JS engines are very good in terms of performance, so all that developers like us need to do is some quick compilation to JS and we're all set. However, I do agree with you on two points: 1) JS, by itself, just isn't structured enough for large-scale applications. 2) The push towards libraries and away from frameworks was misguided because JS, by itself, doesn't have the means to allow for this approach to be successful. Instead, what we have now is every single small library reproducing the same functionality over and over again. Case in point: I was looking at writing an external interface (tells our compiler how to type-check external JS code) to ChartJS this week (great little library), and started looking at the code. 80-90% of the "common" code in the library was code that was already present, in some form, in our UI/runtime layer, and that was around 70K right there. Multiply this by the number of small libraries, and you end up with a lot of duplication of functionality that is, essentially, dead weight. I don't know if it's 10MB of dead weight, but it's pretty significant.
  - dsp1234 11y ago
    190KB of maxgridtest.html took 1.44 s to download 462KB of maxgridtest.js took 2.63 s to download 5.2MB of datasets?method=rows&dataset=IPCountry&Country=%27United%20States%27 took 21.22 s to load "39246 rows load in 40948 msecs" - 41secs total just to see something! This is not an awesome presentation, and misses some of the stuff the previous commenters mention about "windows 3.1" like "don't load an entire dataset in memory, but show a small slice of it at a time". At the time, memory was very limited, so developers were forced to be efficient, and it was good for users. Even on my old 486 DOS machine, I could load up a spreadsheet application, and navigate through it (with way more than 40k rows) at nearly instant speed because it was smart about what it was doing and what it's limitations were (memory, disk access speed, etc)
- WorldMaker 11y ago
  «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.» Typescript is a plenty good enough, statically typed language that transpiles to whatever flavor of JS/ES you need, including ES3 if for some reason you are stuck supporting IE < 8. Typescript has a good ecosystem of tooling (try Typescript in Visual Studio Code, for instance). As for API stability, it largely depends on the SPA Framework you want to try. Yes, the problem is that there are so many to choose from and some of them do wonky things like reimplement the old GUI message passing loops and call it progress. If you want my biased opinions on SPA frameworks: These days I use CycleJS when I get the choice, as it is simple, gets out the way, and built on top of RxJS for true reactive programming. It's simplicity provides a very small API overall and thus a considerable amount of stability for said API because of its smaller surface area. If you need something a bit more time tested with the broadest classic browser support, I think Durandal (Knockout-based) is a stable, well worn SPA framework. Having used Durandal in the past I admit that Aurelia, it's successor, is likely to have a similar stability, as it matures. TL;DR: The transpilers are good enough if you give them a shot. Typescript is a great statically typed language for the web. SPA APIs are crap shoot, but there are good options out there, especially if you stray just a tad out of the way of the hype trains.
- gbuk2013 11y ago
  It's not very fair, I feel, to drag browser binary size into it. Those hundreds of megabytes give you a UI. If you have a QT or GTK app then the dependency you will drag in will not be small (and heaven forbid you depend on some Gnome or KDE lib). I do agree about the browser UI performance though - why I can't scroll a page without the tearing effect in 2016 on an 8 core machine with 16GB of RAM is beyond me ...
- moron4hire 11y ago
  I didn't realize perf was that bad. Apparently, a 68060 could run stereo 3D content on an Oculus Rift.

by bphogan 11y ago

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.

Dr_tldr 11y ago
So what you're saying is you don't know very much about JavaScript but you're willing to learn some once it becomes obsolete like Java?
- pikzen 11y ago
  Stable and field tested, with a majority of the marketshare, as opposed to using the flavour of the day because that's what's hip? Where do I sign up ? I mean, I do C# day to day, so boring is perfect :) Also, much to my dismay, I do try things outs, maybe not extensively, but enough, before criticizing them. I've used Angular, React, Ember, JQuery (yes, working on a 100% jquery SPA. It's as fun as you can imagine), then other things like Vue.js, Knockout, and quite a few more. Even Vanilla JS. So, while I will not pretend to be an expert, or even having advanced knowledge of Javascript, I'd like to think I kind of know what I'm talking about.
  - Dr_tldr 11y ago
    That's good to know, and I promise I wasn't (just) being snarky! The problem is that unless you're working with something low-level like C, by the time it's stable and field tested, the language has also gotten kind of brittle, there's a mountain of bad code, and new features don't undo the damage done by the bad patterns of the past. Javascript also has mountains of bad code and bad practices, but a lot of it's being accumulated in frameworks which are getting created, tested, found wanting, then dropped, with the good parts surviving on, either in new frameworks or as part of the standard. I won't lie though, I'm as framework exhausted as everyone else right now and it can't go on like this for much longer. Using something like C# (which I see as "good Java") would be a nice change of pace. Definitely check out Ampersand and Webpack with React, they're kind of coalescing to provide a saner, "use only what you need" approach.
bphogan 11y ago
I agree with all of those points. But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. So what are ya gonna do? See, I hate JS. I think it's terrible. If there were any other choices out there, I don't even think it would still be a thing if there were any other options. But it's a requirement of a modern web developer to know how to do it well. And I'm a web developer. So I'm going to be good at it. At least as good as I can be given the tools I use and constraints I have.
- simi_ 11y ago
  > But meeting the needs of customers is what I get paid to do That was like being slapped with a good dose of pragmatism – I love it! Wrt the later part of your post, try Dart. It's annoying in entirely new ways, but it does away with a lot of JS pains; it's also mature, powerful, and production-oriented. It even comes with a VM to run it in, so you can pretend it's a real –boy– language. Its obscurity also means that it can be hard to come across help/tools (emacs completion, anyone?), but despite all the shortcomings I enjoy using it, and am happy to back Google's bet on Dart.
  - bphogan 11y ago
    Thanks for the recommendation. I'm currently annoying myself by learning Elm. :)
- M2Ys4U 11y ago
  > But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. >So what are ya gonna do? Both. Do the initial render (well, HTML generation) server-side, and update the state client-side when the user performs an action (or receives an event from the server). Use real, accessible URLs for links, and use pushState when updating client-side.
  - bphogan 11y ago
    I'd love to see books, screencasts, or tutorials that talk about doing this beyond the very trivial. I hear people talk about it, but whenever I ask, they can't show me code because reasons. This makes me skeptical. And based on what I see in the wild... lots of loading progress bars, etc, I don't see widespread use of this technique.
icebraining 11y ago
This post is dangerously approaching flamebait.
- douche 11y ago
  Doesn't necessarily make it false... JS is such a piss-poor language. I'd rather write QBASIC if it ran in a browser.
  - estefan 11y ago
    Agreed, but ES6 is a big improvement. I've just gone back to it and I must admit, it's not actually too bad now if you use babel + webpack.
  - illicium 11y ago
    >QBASIC if it ran in a browser http://tayeandjoe.com/qbarcade/games/qbasic.html http://tayeandjoe.com/qbarcade/games/qbasic.html
TimJYoung 11y ago
This is probably going to send this whole thread on a wild tangent, but here goes... I've posted this before, but check out this link: http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html That app was created with our web development product (check the site if you want to know more), and has the following characteristics: Two files, one HTML loader and one monolithic JS app, so latency during loading is minimal. The HTML loader is ~189K and the JS app is ~462K, and includes the entire runtime and UI layer, and a lot of the control/component library. Both the HTML and JS are aggressively compressed/obfuscated by a compiler, and the coding is done in a statically-typed, OO/procedural language with RTTI and other nice things. The UI was designed using a WYSIWYG designer with two-way tools (code-behind). So, there are products/tools out there that will do something along the lines of what you want. And the existing JS engines are very good in terms of performance, so all that developers like us need to do is some quick compilation to JS and we're all set. However, I do agree with you on two points: 1) JS, by itself, just isn't structured enough for large-scale applications. 2) The push towards libraries and away from frameworks was misguided because JS, by itself, doesn't have the means to allow for this approach to be successful. Instead, what we have now is every single small library reproducing the same functionality over and over again. Case in point: I was looking at writing an external interface (tells our compiler how to type-check external JS code) to ChartJS this week (great little library), and started looking at the code. 80-90% of the "common" code in the library was code that was already present, in some form, in our UI/runtime layer, and that was around 70K right there. Multiply this by the number of small libraries, and you end up with a lot of duplication of functionality that is, essentially, dead weight. I don't know if it's 10MB of dead weight, but it's pretty significant.
- dsp1234 11y ago
  190KB of maxgridtest.html took 1.44 s to download 462KB of maxgridtest.js took 2.63 s to download 5.2MB of datasets?method=rows&dataset=IPCountry&Country=%27United%20States%27 took 21.22 s to load "39246 rows load in 40948 msecs" - 41secs total just to see something! This is not an awesome presentation, and misses some of the stuff the previous commenters mention about "windows 3.1" like "don't load an entire dataset in memory, but show a small slice of it at a time". At the time, memory was very limited, so developers were forced to be efficient, and it was good for users. Even on my old 486 DOS machine, I could load up a spreadsheet application, and navigate through it (with way more than 40k rows) at nearly instant speed because it was smart about what it was doing and what it's limitations were (memory, disk access speed, etc)
WorldMaker 11y ago
«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.» Typescript is a plenty good enough, statically typed language that transpiles to whatever flavor of JS/ES you need, including ES3 if for some reason you are stuck supporting IE < 8. Typescript has a good ecosystem of tooling (try Typescript in Visual Studio Code, for instance). As for API stability, it largely depends on the SPA Framework you want to try. Yes, the problem is that there are so many to choose from and some of them do wonky things like reimplement the old GUI message passing loops and call it progress. If you want my biased opinions on SPA frameworks: These days I use CycleJS when I get the choice, as it is simple, gets out the way, and built on top of RxJS for true reactive programming. It's simplicity provides a very small API overall and thus a considerable amount of stability for said API because of its smaller surface area. If you need something a bit more time tested with the broadest classic browser support, I think Durandal (Knockout-based) is a stable, well worn SPA framework. Having used Durandal in the past I admit that Aurelia, it's successor, is likely to have a similar stability, as it matures. TL;DR: The transpilers are good enough if you give them a shot. Typescript is a great statically typed language for the web. SPA APIs are crap shoot, but there are good options out there, especially if you stray just a tad out of the way of the hype trains.
gbuk2013 11y ago
It's not very fair, I feel, to drag browser binary size into it. Those hundreds of megabytes give you a UI. If you have a QT or GTK app then the dependency you will drag in will not be small (and heaven forbid you depend on some Gnome or KDE lib). I do agree about the browser UI performance though - why I can't scroll a page without the tearing effect in 2016 on an 8 core machine with 16GB of RAM is beyond me ...
moron4hire 11y ago
I didn't realize perf was that bad. Apparently, a 68060 could run stereo 3D content on an Oculus Rift.