6 ms·

Is it really that important nowadays to build webapps in pure js or abstractions of it? We read articles about how many smartphones get superslow when executing

by hit8run 11y ago

Is it really that important nowadays to build webapps in pure js or abstractions of it? We read articles about how many smartphones get superslow when executing loads of JS code, how broken the development process is and how framework x tries to solve that broken flow. We make use of super heavy and complicated toolchains that are outdated half a year from now. I often hear and read things like: "You still use bower instead of npm?", "You still use coffee script?! Go with TypeScript.", "BackboneJS? Why not go with Angular?". Some requirements make it mandatory to do lots of stuff in the frontend. For example: SoundCloud is supposed to continue playing songs when users navigate around. Okay they need a pure JS page refresh experience. But the standard CRUD admin panel you write 90% of the time? There it's not wrong if a browser does what it is supposed to do. Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?

Uehreka 11y ago
Single Page Applications can enhance the user experience in many ways, even with more "boring" apps: * Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward. * Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one. * Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process. Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from: * Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text". * Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens. * Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions. My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.
- arohner 11y ago
  > Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from: Not really. While your points are all true, the two biggest factors that you can't really escape are 1) your SPA is still a 1 MB download 2) eval'ing 1 MB of JS before rendering is still slower than serving HTML. SPAs are a better experience, but they're still slower than conventional pages, and I wouldn't recommend their use on high traffic areas of your site, like the landing page.
  - Uehreka 11y ago
    Sure, and to be fair there are people who needlessly use angular, scrolljacking, and other horrible magicks when building something that doesn't need it. But my experience of the debate has been that there are many many people who think that MVC frameworks are only suitable for "cool" projects like soundcloud, and that the other 90% of front-end developers don't have legitimate use cases for them. I don't think this is a fair or informed assessment of the field, but it can sound like one because it appears to offer a "simple" solution. As for the 1MB download, angular is about 100KB minified (most of the space in angular is comments, which contain ALL of its documentation). Angular is also used in so many places that if you pull it from a CDN your users should never have to download it. In my experience, my SPAs themselves rarely outweigh 10-20KB. Worst case: I have to download 120KB of JavaScript and parse it. Still though, I find that AJAX requests to slow backends still take up most of the load time -- meaning that if my app was a conventional one, the page would take a while to appear at all, then load instantly. Of course, with Angular 2, I've heard server-side rendering comes into the picture, making the whole "where should I render my templates" discussion moot. Sure there's a lot of back and forth and a lot of complexity. But in my experience, many clients and businesses want the kinds of modern touches that only a SPA can give them, and the tooling we have around our code exists to make the task easier, even if it may seem complex at first.
- yuvipanda 11y ago
  Can't all those three things be done with simple AJAX too, instead of having to make your entire application Javascript based?
z1mm32m4n 11y ago
I don't know if you've used Heap before, but they're (necessarily) doing quite a bit more than loading a page when a user clicks on a link. Some applications necessitate more sophisticated user interactions.
ultim8k 11y ago
"Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?" Bloody hell! You've got to be kidding!
lfender6445 11y ago
"You still use bower instead of npm?" - this is a poor example, as bower is specifically geared towards frontend assets
- hippich 11y ago
  i seen trend where people prefer to use npm, write libraries, which could be used on both sides, and then use browserify to prepare it for usage in the browser. I am not saying it is good or bad, this is just another trend.
- grumblestumble 11y ago
  npm is pushing pretty heavily towards being the source for both backend and frontend js assets. a lot of interesting work happening on that front.
  - lfender6445 11y ago
    you are right, did not realize this http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging http://blog.npmjs.org/post/101775448305/npm-and-front-end-pa...
jbeja 11y ago
"Is this such a bad thing to keep things simple?" And you are claim that your way is simpler? To me all the thing that you rant about are just different. If things with the web rendering would started with the front-end instead the back-end, then you would be ranting the same stuff on the opposite side and you would be saying that SPA are simpler.
zachrose 11y ago
Beyond the technical reasons mentioned here, I'd wager that the emphasis on front-end specific apps and toolchains also has to do with dividing developers up in to front-end developers (who don't touch the database) and back-end developers (who don't touch HTML/CSS/JS). This approach has its merits and its drawbacks.
tomphoolery 11y ago
Not at all. You're just not hearing so much about that kind of thing because, in my opinion, we've beaten that dead horse already. The fact that building simple CRUD apps can be done quickly, reliably, and efficiently without the need to be on the cutting-edge of JavaScript wizardry is amazing, but it also means that you probably won't hear about it on Hacker News because it's not what "hackers" (in this case I mean people who like to experiment with new technologies) are getting into. The only reason why this is becoming more of a "thing" nowadays, at least on blogs and in the media, is because the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea, at least in practice on a grand scale. As a job, many web developers (myself included) use JavaScript only when absolutely necessary, and it's really just to make things "look nice". At work, JavaScript is not the thing that drives our entire application (in fact we have more than a few tests that ensure our apps' critical functions work even when JavaScript is disabled in the browser). But I've been experimenting with Ember, Electron, et. al., and it's pretty cool what you can do nowadays with JS alone. These new toolchains have brought and will continue to allow entirely new genres of web applications to be developed with ease, meaning my job gets a little more interesting. We'll probably always have/need CRUD apps, but as a web developer, your fate is no longer sealed in writing CRUD apps for the rest of your life. That's pretty neat!
- BerislavLopac 11y ago
  "the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea" No it isn't. This was written nearly 15 years ago: https://bitbucket.org/BerislavLopac/waexplorer https://bitbucket.org/BerislavLopac/waexplorer
mkhalil 11y ago
I hear you loud and clear. But that is what sort of happened: I figured out I could built simple CRUDS in minutes (literally) using scaffolding, and may a couple hours of editing for special cases. But I got bored, and went to look for what I could do differently. How to make it "smoother". I'm sure scaffolding and quickly generating CRUD with SPA's will happen soon enough and we will move on to something like "pure browser functions" using links and changing pages statefully.
frik 11y ago
Good bye TypeScript, Hello JavaScript

by hit8run 11y ago

Uehreka 11y ago

Single Page Applications can enhance the user experience in many ways, even with more "boring" apps: * Forums/Comment Threads - If I want to reply to a comment in a thread (like I'm doing right now) I don't want the page to refresh after I submit, causing me to lose my scroll position. Even worse is when discussion sites (cough HN) whisk you away to a whole 'nother page to submit your comment, then dump you back to the thread afterward. * Documentation - Let's say you have a long list of topics in a sidebar on the left. If I find a bunch of topics that I want to read and they're in the middle of the scroll, I'll be annoyed if the whole page refreshes when I click on one. * Forms - If I'm filling out a long form (like enrolling in school or applying for a job) and I enter something wrong, I want to know immediately. I don't want to hit submit, land back on the same page, then find where the error is. Even when sites do this well (by saving the whole state of the form and clearly indicating where the bad field is) it's still annoying. Client-side validation also saves server resources (even though you need to do server-side validation too): every time the client catches a validation error, that's one less postback the server needs to process. Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from: * Fonts - for some reason these seem to take a longer time to load than other assets (or maybe their absence is just more noticable). Using a tool like TypeKit can help to get around issues like "Flash Of Invisible Text". * Images - People not properly compressing images, using too many images, using PNG where SVG could possibly work are all contributing to slow page loads. Images are usually the largest things on the page (sometimes by an order of magnitude). They are also often demanded by "the business" in the same way that carousels are usually a result of a business compromise and not a deliberate design decision. Tools like grunticon and other gulp/grunt tasks can help mitigate these issues by ensuring that huge hi-res images have a compressed version and don't get sent to phones with tiny screens. * Ads - Many ad networks either don't run a tight ship or don't police the companies who they allow to run code on their client's sites. The further someone is from actually owning the page where the code runs, the less they often feel compelled to make good optimization decisions. My point is that a lot of this new-fangled front-end tooling (browserify/webpack, TypeKit, SVG, grunt/gulp, the <picture> element, etc.) are geared towards producing a better experience for the user. Many of them either emerged to deal with mobile web issues or found new importance in light of the problems developers (and businesses) face on the mobile web.

arohner 11y ago
> Following the emerging set of best practices (use a CDN, bundle/minify your code with a tool like browserify/webpack, don't block the critical render path) is enough to get your code to a point where it should run totally fine on mobile. The horrible state of mobile web performance more often results from: Not really. While your points are all true, the two biggest factors that you can't really escape are 1) your SPA is still a 1 MB download 2) eval'ing 1 MB of JS before rendering is still slower than serving HTML. SPAs are a better experience, but they're still slower than conventional pages, and I wouldn't recommend their use on high traffic areas of your site, like the landing page.
- Uehreka 11y ago
  Sure, and to be fair there are people who needlessly use angular, scrolljacking, and other horrible magicks when building something that doesn't need it. But my experience of the debate has been that there are many many people who think that MVC frameworks are only suitable for "cool" projects like soundcloud, and that the other 90% of front-end developers don't have legitimate use cases for them. I don't think this is a fair or informed assessment of the field, but it can sound like one because it appears to offer a "simple" solution. As for the 1MB download, angular is about 100KB minified (most of the space in angular is comments, which contain ALL of its documentation). Angular is also used in so many places that if you pull it from a CDN your users should never have to download it. In my experience, my SPAs themselves rarely outweigh 10-20KB. Worst case: I have to download 120KB of JavaScript and parse it. Still though, I find that AJAX requests to slow backends still take up most of the load time -- meaning that if my app was a conventional one, the page would take a while to appear at all, then load instantly. Of course, with Angular 2, I've heard server-side rendering comes into the picture, making the whole "where should I render my templates" discussion moot. Sure there's a lot of back and forth and a lot of complexity. But in my experience, many clients and businesses want the kinds of modern touches that only a SPA can give them, and the tooling we have around our code exists to make the task easier, even if it may seem complex at first.
yuvipanda 11y ago
Can't all those three things be done with simple AJAX too, instead of having to make your entire application Javascript based?

z1mm32m4n 11y ago

I don't know if you've used Heap before, but they're (necessarily) doing quite a bit more than loading a page when a user clicks on a link. Some applications necessitate more sophisticated user interactions.

ultim8k 11y ago

"Load a page when a user clicks on a link. Is this such a bad thing to keep things simple?" Bloody hell! You've got to be kidding!

lfender6445 11y ago

"You still use bower instead of npm?" - this is a poor example, as bower is specifically geared towards frontend assets

hippich 11y ago
i seen trend where people prefer to use npm, write libraries, which could be used on both sides, and then use browserify to prepare it for usage in the browser. I am not saying it is good or bad, this is just another trend.
grumblestumble 11y ago
npm is pushing pretty heavily towards being the source for both backend and frontend js assets. a lot of interesting work happening on that front.
- lfender6445 11y ago
  you are right, did not realize this http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging http://blog.npmjs.org/post/101775448305/npm-and-front-end-pa...

jbeja 11y ago

"Is this such a bad thing to keep things simple?" And you are claim that your way is simpler? To me all the thing that you rant about are just different. If things with the web rendering would started with the front-end instead the back-end, then you would be ranting the same stuff on the opposite side and you would be saying that SPA are simpler.

zachrose 11y ago

Beyond the technical reasons mentioned here, I'd wager that the emphasis on front-end specific apps and toolchains also has to do with dividing developers up in to front-end developers (who don't touch the database) and back-end developers (who don't touch HTML/CSS/JS). This approach has its merits and its drawbacks.

tomphoolery 11y ago

Not at all. You're just not hearing so much about that kind of thing because, in my opinion, we've beaten that dead horse already. The fact that building simple CRUD apps can be done quickly, reliably, and efficiently without the need to be on the cutting-edge of JavaScript wizardry is amazing, but it also means that you probably won't hear about it on Hacker News because it's not what "hackers" (in this case I mean people who like to experiment with new technologies) are getting into. The only reason why this is becoming more of a "thing" nowadays, at least on blogs and in the media, is because the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea, at least in practice on a grand scale. As a job, many web developers (myself included) use JavaScript only when absolutely necessary, and it's really just to make things "look nice". At work, JavaScript is not the thing that drives our entire application (in fact we have more than a few tests that ensure our apps' critical functions work even when JavaScript is disabled in the browser). But I've been experimenting with Ember, Electron, et. al., and it's pretty cool what you can do nowadays with JS alone. These new toolchains have brought and will continue to allow entirely new genres of web applications to be developed with ease, meaning my job gets a little more interesting. We'll probably always have/need CRUD apps, but as a web developer, your fate is no longer sealed in writing CRUD apps for the rest of your life. That's pretty neat!

BerislavLopac 11y ago
"the idea of creating a web application that actually does stuff entirely with JavaScript is a relatively new idea" No it isn't. This was written nearly 15 years ago: https://bitbucket.org/BerislavLopac/waexplorer https://bitbucket.org/BerislavLopac/waexplorer

mkhalil 11y ago

I hear you loud and clear. But that is what sort of happened: I figured out I could built simple CRUDS in minutes (literally) using scaffolding, and may a couple hours of editing for special cases. But I got bored, and went to look for what I could do differently. How to make it "smoother". I'm sure scaffolding and quickly generating CRUD with SPA's will happen soon enough and we will move on to something like "pure browser functions" using links and changing pages statefully.

frik 11y ago

Good bye TypeScript, Hello JavaScript