Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things to Know When Making a Web Application in 2015

blog.venanti.us

Post reply on HN
Print view View original

111–120 of 186 posts

Re: Things to Know When Making a Web Application in 2015

#111

Post by baddox »

fred2133 wrote: post #105
baddox wrote: post #87

Earlier quoted context omitted.

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…

You should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.

Just out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.

Re: Things to Know When Making a Web Application in 2015

#112

Post by TheAceOfHearts »

jameshart wrote: post #20

"You don't have to develop for mobile..." ... well, no. Technically you don't have to. But you almost certainly should .

I strongly disagree. There's tons of people that talk about how everything should be mobile first, but that's just not feasible for a lot of web applications. Stop trying to shove mobile into everything.

If I'm making a Web IDE or a Web Photoshop, it's very unlikely I'll be able to fit all of the functionality that's needed into a tiny mobile screen, and it's also unlikely I'll be able to get it to perform well. And you know what? That's totally fine, because if my demographic is gonna be people with 1920x1200 monitors on a powerful desktop machines, it'll work great. I'll build an amazing experience for desktop, because that's my target demographic.

A lot of enterprise applications are impossible to scale down to mobile as well, due to the sheer amount of customizability and information they provide. I don't know of many enterprise applications that support both mobile and desktop. If you want to support mobile for an enterprise app, you're better off designing a separate mobile variant of your application. This assumes you have the resources to do so, and that there's sufficient interest from your customers such that the decision to have a mobile variant makes sense.

Here's the thing, building a sophisticated application that works well on a tiny phone and scales all the way up to a 30'' monitor is not feasible at all for a lot of teams. I'd challenge you to show me a good example of a sophisticated app (e.g. along the lines of a Web IDE or Web Photoshop) that will scale nicely from a tiny mobile screen all the way up to an awesome 30'' display.

Re: Things to Know When Making a Web Application in 2015

#113

Post by superuser2 »

balls187 wrote: post #28
artmageddon wrote: post #22

Earlier quoted context omitted.

I took that to mean use both identity management as well as OAuth.

1. Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? 2. Security best practices subject to "open for interpretation."

While OAuth isn't "for" authentication, everyone uses it that way by "authorizing" access to "view your email address" which is as good as authenticating your email address.

Re: Things to Know When Making a Web Application in 2015

#114

Post by joepie91_ »

baddox wrote: post #87
joepie91_ wrote: post #65

Earlier quoted context omitted.

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…

> Sure there is, if you care about interactivity, responsiveness, and general user experience.

And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs.

> The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small.

Your use of the term 'probably' suggests to me that you have not run any actual metrics. Here's a short list of some examples:

- Bots and spiders

- Low-powered mobile devices

- Privacy-conscious users who use NoScript

- Terminal-based browser users

- Literally every single one of your users until the .js blob has completed downloading

- ...

Requiring JS for a website is not okay, end of story. We all collectively understood this 10 years ago, and I'm not really sure where along the way this understanding has gotten lost.

EDIT: Forgot that HN has a neutered version of Markdown. Fixed.

Re: Things to Know When Making a Web Application in 2015

#115

Post by joepie91_ »

tomjen3 wrote: post #81
joepie91_ wrote: post #65

Earlier quoted context omitted.

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

Maybe not all my clients support javascript, but substantially all I care about do. I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it. Works very well.

> Maybe not all my clients support javascript, but substantially all I care about do.

See here: http://bradfrost.com/blog/post/fuck-you/

> I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it.

That is a reverse CAPTCHA, it works very well, and has absolutely nothing to do with Javascript. They are typically implemented using CSS.

Re: Things to Know When Making a Web Application in 2015

#116

Post by ersoft »

billyhoffman wrote: post #89
vdaniuk wrote: post #73

Earlier quoted context omitted.

jQuery CDN cache hit rate is 99.8%[0], Google CDN numbers should be comparable. So yes, you are leveraging browser cache for most popular libraries. Also I was talking from the subsequent requests from the same client. [0] https://www.maxcdn.com/blog/maxscale-jquery/

You are confusing browser cache hits with a CDN/edge server cache hit.jQuery, or MaxCDN for that matter has no idea what the "hit rate" of a browser cache is. This sentence should be a big clue: "We usually average around 15,000 hits per second to our CDN with 99.8% of those being cache hits." "We" in that sentence is Kris Borchers speaking collectively about the jQuery foundation, talking a MaxCDN interviewer. But h…

Maybe they are talking about 200 vs 304 caches.

A browser can use be told to revalidate files, telling the server to return the content using the "If-Modified-Since" and "If-None-Match" headers. This way, the server will return 304 and empty content if the file has not changed or 200 and the file if it is new or it changed

Re: Things to Know When Making a Web Application in 2015

#117

Post by thekingshorses »

tspike wrote: post #39

First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance. > If you're just starting out with a new web application, it should probably be an SPA. Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity. In ne…

> I cannot comprehend why Reddit chose a single-page app for their new mobile site

They should but not the way they are making it.

It should be server side render for initial page (not just home page but any page). And mostly changing content through AJAX when you navigate between pages.

SPA is hard specially when it comes to usability. One of the biggest issue I see with SPA is going back. Browser handles back history pretty good for non-SPA. Replicating similar behavior in JS in not easy.

Reddit SPA should be like this with server side rendering. http://reddit.premii.com/

Re: Things to Know When Making a Web Application in 2015

#118

Post by baddox »

joepie91_ wrote: post #114
baddox wrote: post #87

Earlier quoted context omitted.

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…

> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. H…

> Your use of the term 'probably' suggests to me that you have not run any actual metrics.

What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers.

> Requiring JS for a website is not okay, end of story.

It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."

> We all collectively understood this 10 years ago

Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."

Re: Things to Know When Making a Web Application in 2015

#119

Post by joepie91_ »

baddox wrote: post #118
joepie91_ wrote: post #114

Earlier quoted context omitted.

> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. H…

> Your use of the term 'probably' suggests to me that you have not run any actual metrics. What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. > Requ…

> What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers.

I was refering specifically to websites, not webapps.

> It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story."

That analogy makes absolutely no sense, nor does your comparison to CSS. JS is an entirely different class of dependency than either CSS or web browsers.

JS is turing-complete, has a significantly bigger attack surface (both in terms of vulnerabilities and in terms of tracking), is much, much harder to optimize for a low-powered device than HTML and CSS, and so on.

Further, the web browser is a necessity to view something on the web. It is well understood, it is easy to optimize, and it is widely deployed. JS is no such 'required dependency' - and you should not make it one, when it can be done just fine without.

> Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."

The support/compatibility landscape for JS has not changed in those 10 years. The types of non-JS clients are still the same, the reasons for progressive enhancement are still the same. The only thing that has changed is standardization.

"Old" is not the same as "obsoleted". Unless you can come up with a concrete reason as to why this knowledge has been obsoleted throughout the past 10 years, it still applies.

And I'm getting a little tired of these poorly fitting analogies, you're using them as a crutch.

Re: Things to Know When Making a Web Application in 2015

#120

Post by noir_lord »

joepie91_ wrote: post #65
tspike wrote: post #39

First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance. > If you're just starting out with a new web application, it should probably be an SPA. Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity. In ne…

I fully agree with this. SPAs are for web apps , not web sites . For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should n…

I didn't even use a SPA for a webapp on my main work project I wrote a lightweight base and send down the page specific stuff and that model (so in a way it's lots of little SPA's not sure if that has a name) which means I get most of the advantages with few of the downsides.
Post reply on HN