Hacker News Reader

Comment by hit8run | Hacker News Reader

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?

View on HN

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!

"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

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.

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

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.

Good bye TypeScript, Hello JavaScript

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

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.

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.

you are right, did not realize this http://blog.npmjs.org/post/101775448305/npm-and-front-end-pa...

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.

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

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.

Can't all those three things be done with simple AJAX too, instead of having to make your entire application Javascript based?

Yes, but you often end up with half an angular app: a bit of templating, a bit of boilerplate around your AJAX calls, some AJAX here and there. But you quickly run into problems:

- Your designers need to change the markup of the invalid form alerts, and you have to point them to a string building function in your JS rather than an HTML template.

- Once they change the string builder, you need to run your unit tests to make sure it still works. If you don't have any way to do dependency injection, writing unit tests of client side code will be difficult.

- Now your presentation logic is split between front and back end. This makes engineering tasks like assessing test coverage and refactoring more difficult.

For some use cases AJAX only may work. When I'm doing a side project that involves a lot of visual stuff and little state management, I'll ditch the MVC framework and task runner and work with just jQuery or D3. But if I'm working on a large project where many other people are contributing, I want a framework that helps me write testable code and provides structure to help keep my concerns separated.

Every one of these features is doable in a more traditional web application with something like intercooler.js (which I created). Good UX does not require a SPA and it certainly does not require massive amounts of client-side code.

The scenarios you describe can be done with JS enhanced HTML pages. No need to do this as a complete single page application requiring tons of boilerplate framework code.

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

That's what middle-click to create a new tab is for.

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

If HN were a single-page app, I wouldn't use HN. Period.

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

Again, that's what middle-click is for.

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

Sure, that's a nice use for JavaScript. I just don't want to have to expose my entire system, and all my data, and every system I can connect to, to malware in return.

I have to admit, I'm not really interested in your restrictions on what people are allowed to use in browsers. You are definitely not the arbiter of the one true way, no matter how right you feel about your opinions.

Are you interested in security and privacy? Are you interested in functionality?

I am, of course, the arbiter of what I permit my browser, running on my computer and accessing my data, to do.

Opening a new tab works, but come on... It's a crude tool!

What percentage of internet users either have a middle-click or know how?

Ok how to middle click on a tablet? Press and hold, but that sucks.

How to middle click with an apple mighty mouse with no middle click? Press and hold cmd whilst clicking left click.

Middle click doesn't work and it if you are about to submit a comment on a thread how do you middle click to load the same page at the same scroll position?

One very important point against SPAs is URLs. URLs are central to the design of the web. Lets say I want to talk about a particular commit on github. I can just pick the URL for that commit and email it to someone else. They can click on the link and land directly on the commit page. If it is a single page app, I will have to tell them 'Go to this URL, click here, and then click there' etc.

Same case with blog posts. Sites like HN would not even exist if everyone published all their posts in SPAs.

Or you can build a SPA that supports jumping to a particular resource with a URL, Like not breaking the back button in a SPA, this is technically possible, even if it is all-to-rarely done.

Most SPAs I've used handle the routing with JavaScript, making your URL sharing use-case possible. It's not very hard to implement either, that stuff is covered quite early in most AngularJs resources out there. In fact, creating a large SPA without some sort of routing sounds like a nightmare.

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.

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

Reply on news.ycombinator.com