12 ms·
Static Web Apps – A Field Guide
- deleted 13y ago[deleted]
- daleharvey 13y agoDisagree with a few things, the title 'static is better', is hyperbole, its a different environment. Also the 'the doesnt mean they are any less capable' is pretty much by definition wrong. That being said I absolutely love the architecture, pretty much every application I build these days starts with switching my github default branch to gh-pages. I work on http://pouchdb.com http://pouchdb.com and use that for storing and syncing data. not having to worry about how my servers are configured / how they are running, how to move an application makes me feel like I can build what I want then when I come back in 2 years it 'just works', with dynamic applications I always feel there is a maintenance burden that I cant shake.
- e12e 13y ago> Disagree with a few things, the title 'static is better', is hyperbole, its a different environment. This. I feel I might fall under the hn banhammer soon, but I really wish people would actually read Fieldings thesis (introducing REST) -- it's a really good overview of the different architectures one might use for a client-server system. It' not just REST, REST is a natural conclusion drawn from the alternatives when the goal is a highly performing system for hypermedia: https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_2 https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch... But it's worth noting that fat-client styles are also in there, and the trade-offs mentioned are worth keeping in mind (no, there is no silver bullet -- you actually should choose an architecture that fits your problem domain. Shocking, isn't it?).
- bowlofpetunias 13y agoI wonder if people who advocate this as "better" have ever build anything even remotely complex. It's this kind of simplistic tunnel vision why many engineers look down their noses at "web development". Also, this is nothing but a marketing site for a "static web hosting service", which explains the superficial buzzword bingo.
- mbleigh 13y agoYour derision comes with a dearth of actual reasoning as to why "complex" applications don't work from a static architecture perspective or how you define complexity.
- rquantz 13y agoSo is this just another way to talk about the now-ubiquitous thick-client app? Or is there something revolutionary I don't see in my cursory look at this site? There is definitely something to be said for building separate services as your API, rather than thinking your static assets have to be married to the data processing backend. But calling that a static app is misleading -- it's still dynamic, and in fact the server is still processing data, it's just distributed.
- badman_ting 13y agoThe assets served to the client are static, they can be served by a simple server, cached through CDNs, etc.
- derengel 13y agoI don't know how it is static either or are you referring that it is 'static' only from the web browser(consumer) point of view? for example, in the backend you could be generating a value from a database.
- badman_ting 13y agoIt's really not worth sperging out about this. It just means the HTML/JS/CSS assets delivered by the front-end server do not change.
- mtrimpe 13y agoSperging out? Are you serious?
- abrichr 13y agoI had to look this one up: Sperging out: When someone goes on a long, in-depth, overly elaborate explanation long after everyone already gets the point, but will not fucking end. [1] http://www.urbandictionary.com/define.php?term=Sperging%20out http://www.urbandictionary.com/define.php?term=Sperging%20ou...
- foreigner 13y agoThe elephant in the room is performance. They can't help mentioning "perceived performance" but conveniently haven't gotten around to explaining that in detail. In my experience browser performance is a struggle, and it's always faster to do as much as possible on the server.
- badman_ting 13y agoI think performance is slightly more complicated than that. For just a document, like a blog post, I totally agree -- and find it irritating that Blogger has a "static app" now just to serve a damn page with a blog post. But for an application, doing it this way can front-load things, so that the startup time for the app is long, but transitioning between states can be faster.
- jakejohnson 13y agoA great example of this in action is Apostle.io. There's a short delay to front-load things and then the app becomes blazing fast when transitioning between states. Internally, it's only making JSON requests to an API that it needs for the view/state. Only parts of the DOM are updated instead of re-rendering the entire page.
- couchand 13y agoAlso indexing by search engines or the like. Expecting a web crawler to resolve your JavaScript code to produce a complete page is probably a recipe for pain.
- mbleigh 13y agoSearch friendliness is probably the biggest problem yet to be completely solved for static apps. There are workarounds, but they are admittedly less than perfect. However, given the general web development trends towards JS-driven interfaces and upcoming standards like Web Components, I don't think it's going to stay unsolved for much longer.
- mbleigh 13y ago
- kennethkl 13y agoWhy take a step back in technology?
- Gracana 13y agoI think you're misunderstanding what they mean by "static." The served pages are static html and javascript, and the javascript loads other resources from the server. The "static" part just means there is no page rendering occurring on the server.
- otterley 13y agoOut of all the processes that must occur to render a dynamic server-side response (database queries, computations, etc.), assembling HTML ("page rendering") is probably one of the least expensive. This seems like a premature optimization to me.
- reverius42 13y agoIt's not just a performance optimization. It's a cleaner architecture that's easier to test.
- badman_ting 13y agoIt certainly has its advantages. I would even say if you can get to a point where your app is totally static, you should do it. But if there's even a little server-side state things can get complicated pretty quickly. For example, say your app uses hash/fragment URLs, and users need to be logged in to access the app. A user hits yourapp.com/#/whatever, but isn't logged in, so you bounce them to the login page. Except, oops, the hash/fragment doesn't get sent to the server, so your login page doesn't know where to redirect the client after logging in.
- ethikal 13y agoThere are ways around this. With ember it is possible to use browser history to mask the hash... http://emberjs.com/guides/routing/specifying-the-location-api/ http://emberjs.com/guides/routing/specifying-the-location-ap...
- hibikir 13y agoI used to work at a place that switched to only building apps this way. It was architecturally simple, but for random business apps, there was one major difficulty: The tooling felt like going back on a time machine. You have all this tools out there for download, but almost all of them don't do quite what you want, are not easy to extend without just getting tied to an old version forever, and have trouble interacting with each other. When you get developers that are wishing they were back using Swing because it was easier, you know you have trouble.
- jonny_eh 13y agoGot any specific examples?
- fidotron 13y agoSwing is/was verbose for simple stuff, but beyond a fairly low complexity bar it is enormously preferable to the web stack, at least from a developer perspective. While Java got somewhere with the whole deployment thing it was never quite as slick as the web, and that's the killer aspect of the web really. What is funny about the web these days is how they're very slowly reinventing all the things NeXT were doing in the 80s, only using a lot more memory and CPU in the process. Ironic given it started on a NeXT in the first place.
- ludicast 13y agoThe tooling is now awesome (imho). I am the furthest thing from a node.js fanboy, but as a build pipeline it is awesome. Being able to have a gulpfile take care of compiling jade, coffeescript and sass, triggering live reloads, etc., immediately makes me smile. As a former-Flex developer who dealt with some heinous build-times because the tooling was worth it, I now have a better front-end alternative with sub-quarter-second build times. And if you have a json-serving backend (rails, spray.io, whatever) you can set up easy double tests of your front-end logic, where you mock out the backend, and then run slower "integration" tests where you include it. Might sound wacky but I've found this to be a way to quickly develop robust systems. For me, angular's dependency-injection makes it even easier. So this static-koolaid took a while for me to drink, but I'm liking it more all the time.
- 13y ago
- daemonk 13y agoIsn't this really just advocating clear separation/encapsulation between client-side and server-side? IE. create a "static" web app that can get data from server side through REST API or allow you to plug in other sources of data (pouchdb).
- minhajuddin 13y agoWhat a coincidence, I have been building a CMS which spits out static HTML which uses the same bolt icon :) http://getsimplesite.com http://getsimplesite.com I think static apps are best suited for very simple apps which don't have a lot of business rules, simple CRUD apps are the best candidates for this kind of a setup. Once you go beyond a simple app doing things on the server is much easier.
- mantrax4 13y agoAnd you also make the same unsubstantiated claims of superiority, without any explanation. What is this magical hosted CMS that limits my freedom, exactly?
- minhajuddin 13y agoMany CMSes ask you to write your templating code in something which is safe to run on the server, check http://get.harmonyapp.com/ http://get.harmonyapp.com/ for instance it forces you to use liquid templates. Getsimplesite on the other hand uses plain javascript to write page templates.
- mantrax4 13y agoSo then the solution that comes to mind before I drop my entire stack to use yours, is to simply use the language the CMS itself was written in (Python, PHP, whatever), instead of the CMS. Sorry. Work on your value proposition.
- jcolemorr11 13y agoI honestly misunderstood the definition when I first read it. I've built a variety of web apps (old php + mysql, actual static content, nodeJS + angular), and I this terminology escaped me. I've never looked at an Angular app and referred to it as static? In fact, what is defined here is the exact opposite of what I'd assume was a static application.
- dickeytk 13y agoyou can totally use s3 with pushState sites. They allow you to set custom redirection rules
- mbleigh 13y agoRedirects don't maintain URL state. If I make a redirect rule that points everything to /index.html, once I get to /index.html the browser doesn't keep the old URL in the location bar.
- simonw 13y agoAllow me to describe a revolutionary way of creating web applications. I call it "Pages and forms". If you need to display some information, you use an abstraction called a "page" - a full HTML document served from a URL. You can generate the HTML using a variety well understood, easily tested server-side frameworks. You can even just serve static HTML saved in a file. Pages are easy to scale, easy to link to and work on every device, platform and browser released since IE and Netscape 3 back in 1996 (or earlier if you don't need to rely on the Host header). How about adding interactivity? That's where "forms" come in. Forms allow your application to request information from users and submit it back to your server using a simple and widely understood key/value mechanism. By combining pages and forms you can build applications that work everywhere, are easy to link to, easy to maintain and can be scaled to handle anything you can throw at them.
- oneeyedpigeon 13y agoAdd a thin-layer of javascript for immediate feedback on certain UI operations, and I'm sold.
- tonyedgecombe 13y agoIt won't catch on :)
- Rusky 13y agoStatic web apps are excellent for things like webmail, Google Docs, etc. that aren't going to be crawled. It's simpler there, and is probably how things should work in a hypothetical non-web-based but still deployed-web-style app ecosystem. For a blog, or a forum system, or twitter, or anything that should be crawled and linked to and shared, it doesn't really make sense, and "pages and forms" makes much more sense.
- deleted 13y ago[deleted]
- ams6110 13y agoSo we're back to Powerbuilder again.
- rubyn00bie 13y agoIn other breaking news: ) Earth still exists ) Human's breathe oxygen *) Cow's fart a lot Not to be a total arsehole, but I mean... uhh, what's the point of this? If anything, it sounds like, from the copy, they want you to make websites but instead of calling it a "website" because that's un-cool? I don't get it. // Start of semi-related rant I would also like to call this statement in their opening paragraph complete non-sense and almost simple minded: "Static web architecture eases common web development headaches without introducing additional complexity" After many years of doing web development, I can see programming in Java, Obj-C, or .NET is worlds easier for application development. Instead of 27 different platforms (IE, Firefox, Chrome, Safari on different platforms) I have one-- the god damn operating system. Was this always the case? Nope, but it is now. Is it easier to write a single screen on the web using JS, HTML, and CSS? Sure, but the return is marginally decreasing as the application grows. More screens, more complexity, the more HTML/CSS/JS start to show their age. Web development becomes actually more complicated than writing a native application.
- AdrianRossouw 13y agoI try and keep things static unless I have really good reason to do dynamically generated markup. There are still very good reasons for having a backend sometimes. There is a middle ground if you are primarily replacing a CMS though, which is using a static site generator like jekyll. This is something I learnt while working at [1] DevelopmentSeed. They also built a wonderful editor for github pages called [2] Prose. [1] http://developmentseed.org/blog/2012/07/27/build-cms-free-websites/ http://developmentseed.org/blog/2012/07/27/build-cms-free-we... [2] http://prose.io http://prose.io
- anishkothari 13y agoProse is seriously awesome! Thank you :-)
- klapinat0r 13y agoHaving skimmed the available articles, I'm still left asking: How does authorization work here? As in, do you use it to 200 or 401 an url (example.com/static/klapinat0r/feed). Or are they simply advocating serving HTML as templates and updating with js? If so, that's hardly news is it? By their definition that'd be Hybrid though, right?
- mbleigh 13y agoAuthentication and Authorization are handled via JS calls to back-end services that know. Did you read http://www.staticapps.org/articles/authentication-and-authorization http://www.staticapps.org/articles/authentication-and-author... -- if so, what doesn't make sense from that perspective?
- klapinat0r 13y agoWhether or not this was a new take on static + auth, as it sounded like it was the standard client-js apps (which you confirmed it is). Not that it's not a valid approach, I just assumed it was something new.
- deleted 13y ago[deleted]
- skrebbel 13y agoThese people call an app "static" when all content is dynamically generated at runtime on the client-side. Everybody else calls these things "single-page web applications". I really don't see the point of defining a new, confusing term for an existing concept.
- mbleigh 13y agoBecause it's describing two different (but related) things. Jekyll blogs are static sites, but not Single-Page Apps, as an example.
- thruflo 13y agoI believe the point is to drive traffic to http://www.divshot.com http://www.divshot.com, re-labelling their snake oil as a uniquely cold-blooded essential along the way. I quote from their features page: > Fully featured? Yes. Get pushState with custom routes, clean URLs (goodbye, .html), and more. ... Whatever you choose, we support it. > S'all about you, dev, s'all 'bout you.
- mbleigh 13y agoActually, we built our static hosting service because we were already developing with a static web architecture and couldn't find an existing acceptable option for hosting. I'm building the platform because I believe in the technology, not espousing the technology because I built the platform. :)
- thruflo 13y agoI also believe in the technology and the general architecture you're espousing. I found the content on http://www.staticapps.org http://www.staticapps.org well written and constructive and the links to http://www.divshot.com http://www.divshot.com are unobtrusive. My reaction to http://www.divshot.com http://www.divshot.com is something else entirely. To solve the "problem" of static file hosting and deployment with a service that is "compatible with Angular and Firebase" and supports "pushState with custom routes" is clearly disingenuous. Not that there's anything wrong with effective marketing. If your target audience is people who don't know what the words mean, then knock yourself out.
- pygy_ 13y agoWhat's their plan for dealing with CSRF? For this type of app, the usual solution is to embed a token in the first response, shared between the page and the server, and use it for authenticated communication through the data channel (be it AJAX or a WebSocket). Consequently, the first page can't be static.
- camus2 13y agocant the first page just request a token through ajax?
- reverius42 13y agoyes.
- Joeri 13y agoThe token is returned by the auth service when the user logs in. The initial page bootstraps in unauthenticated mode and always has to query the auth service first to figure out if the user is logged in. That's how I've done it in the past.
- pygy_ 13y agoHow do you tell apart the app loaded in several tabs and and an attacker?
- mbleigh 13y agoCSRF is more or less impossible in a static site architecture. Since everything is just static HTML there are generally no form submission endpoints to attack. XSS can be very dangerous, as can session hijacking, but CSRF is pretty much moot on static apps.
- pygy_ 13y agoEverything is _not_ static: there's a data channel. If you need to support browsers that do not support localStorage, indexedDB or another kind of local, private storage, you must either restrict authentication to a single tab or provide a token on page load, and not later (one token per page load). This is less of a concern now, but it used to be the case.
- dpweb 13y agoThe static thing - I think its a reaction to the obvious inefficiency of dynamic pages, server processing for data that is only changed occasionally. Consider a blog which gets posted to once a week. Do you really need dynamic processing for every page render 24/7/365? Well, that's the way it works. But you have to have something additional for changing data/separate API. You can do the static site, but you still gotta have the XHR or JSONP calls to fetch dynamic data. You get a nice separation of UI/data, easier to tweak the UI - independent of the data (hand it off to a designer), and your separate data server can feed multiple apps or you open it up for the world to use.
- snowwrestler 13y ago> Consider a blog which gets posted to once a week. Do you really need dynamic processing for every page render 24/7/365? Well, that's the way it works. Isn't this the exact problem that a reverse proxy cache solves?
- dpweb 13y agoit does if you want to setup the 2nd piece, but I like nginx alot
- snowwrestler 13y agoA reverse proxy cache in front of a dynamic application can approach the best of both worlds. If the page requested is static, you get a fully rendered set of HTML etc. from the cache. If the page requested needs to be customized somehow, the request passes through the cache and hits the application, which custom-renders a new page to send back.
- BinaryIdiot 13y agoAfter looking over the site it seems to be advocating simply serving static content statically and / or create single-page web applications. I'm not entirely sure 100% static makes sense either. For instance serving debug versus minified versions of a website. Sure you could compile everything and create different outputs but that takes time and testing to setup; I haven't worked on a team that would really have the upfront time to do that. The alternative is loading assets via JavaScript but that's much slower than including the links upfront. The other issue is serving code that requires higher permissions to execute. I would rather leave chunks out if I know if can't be accessed from the server-side to make it a little more difficult for someone to figure out how to exploit my website. It's certainly not foolproof nor secure but I don't want to make it completely easy for someone to understand how all administrative functions and permissions work either. You could probably compile different versions of the website and control which gets served based upon authentication but that's even more upfront cost.
- mbleigh 13y agoThe great thing about a static app architecture is that for things like administrative functions you can usually easily build an entirely separate interface and application utilizing the same back-end resources. Security through obscurity is never sufficient, and static architecture makes you think through those concerns more thoroughly before deploy. See http://www.staticapps.org/articles/authentication-and-authorization http://www.staticapps.org/articles/authentication-and-author... for more on that subject. As to development vs production, minifying etc. that's something we're trying to solve with multi-environment hosting at Divshot.
- BinaryIdiot 13y agoIt's not typically cost effective or realistic to build an entirely separate interface for administrative functionality (in fact, for user experience purposes, it's typically better to be able to administrator changes in place). As I mentioned it's doable but requires additional upfront work that I have never had time to do on any project I get to work on. Obviously security through obscurity isn't sufficient as I said it wasn't security :) but I don't see any reason why a static architecture should make you think about those issues any more or less; you should already be doing so.
- mantrax4 13y agoCongratulations. With this arbitrary limitation you just eliminated the cheapest, most scalable and most simple part of the entire web application - HTML template rendering, to replace it with fragile and invisible to search engines JavaScript logic. I believe people in firm grasp of their common sense would take the practical hybrid approach and do what makes sense for each specific scenario, rather than rely on ideology to architect their app for them.
- mbleigh 13y agoIf you're running a mostly-public content site that depends largely on search engine traffic, static is probably not the way to go (yet). If your application lives mostly inside of a login, there's little reason to force yourself to render HTML from the server rather than building reusable APIs that can be shared across web, mobile, etc.
- mantrax4 13y agoFalse dichotomy. Building reusable APIs has nothing to do with forcing yourself to consume them with client-side JS. Maybe that approach works as a training wheels type of guide for developers who can't stay focused, but a service layer is pretty much the norm for any competently written web app, whether a particular API call is materialized with client-side or server-side view rendering. Few additional points about thinking intranet apps get a pass for being intranet: 1. Even on the intranet, it's good for people to be able to bookmark specific point of their navigation and query type (i.e. page, sorting order, filtering criteria, via URL query); it matches how they use the web, and improves their workflows and performance. People don't react well when the web app you developed just decided to pick up all the limitation of native apps, with none of the benefits of a native app (native UI, performance, OS integration etc.). Don't make it a crappy wanna-be-real-app web app, just make it a good web app, acting like a web app. Now, sure, if you try really heard, you can emulate it with a big number of static pages (so it works when you refresh) and manually synching everything with the browser History API, but whoops, you just blew your budget, deadline and doubled the number of tests your app needs to pass QA checks since your app now has complicated history management where it didn't need any (aside form ideology), instead of letting the browser and server work it out using the good old school ways of handling page state. 2. It's pointless waste to develop two set of practices, tools and processes for creating & maintaining public apps, vs. internal apps. What for? Feeling good inside that you saved 3% CPU on the server in view rendering? Please. I've gotten people fired over insisting on using their own pet practices like these (with no provable real-world benefit) over common sense, and wasting the business time and money. 3. In my practical the line between an intranet app and Internet apps is thing. So if an internal app becomes public (in a limited or full-blown capacity), it's a good idea you don't have to drop all the UI code and start over, mkay. I write intranet apps for a living (they mix server-side and client-side rendering).
- troels 13y agoI don't think the dichotomy of static vs. dynamic is that useful really. At least not if they are taken to mean pre-compiled vs. generated directly as a response to a http request. The so-called static pages are presumably still assembled by some programmatic pipeline (aka "dynamic"). What does matter, is that pages that are the same for all users, and that change rarely are served with proper caching headers. That way you can drop a http-cache in front of your app and voila, you have all the same benefits that a pre-compiled site would give you, but without the pain of having to use a completely separate process. The hard part is separating elements that have different frequencies of change from each other. For some reason, this is not something that popular web frameworks (Such as Rails) push very hard, but it's something I find extremely useful when building web apps. A classic trick is putting user-specific information (Such as your name + karma score in the top right corner of this site) in a separate ajax-call, while the main page is served with hard public-cache headers.
- alok-g 13y agoWeb development newbie here. Is there a starter template available on these lines that has the guts built-in, including both client and server code, user authentication, server-side database access, a default theme, etc., where the developer can start by defining the application-specific data models and business logic?
- jakejohnson 13y agoI recommend checking out some of the examples provided by Firebase. In particular, something like angularFire-seed (https://github.com/firebase/angularFire-seed https://github.com/firebase/angularFire-seed) is a great way to get started. Firebase can handle user authentication and data storage. AngularJS + Firebase is an amazingly productive combo. Set up Bower and use Bootstrap for the user interface, you’re all set. It would be a great idea to set up some boilerplates for StaticApps.org showing how easy it is to get started.