This post makes me sad. Javascript, CSS and HTML can all be used powerfully, performantly and in a managed way where anyone can come on board and contribute. Facebook, Google and Microsoft all use the web stack to run huge companies. To broadly paint this web stack that so many people poured countless hours into making, as 'impossible' to use is doing it a great disservice.
What's sad is the zillions of hours wasted by engineers on an inherently flawed stack. What's sad is how ridiculously complicated it is to create and manage relatively simple UIs. What's sad is an entire generations of programmers growing up and thinking this is normal.
Programming is supposed to be about creating platforms for each other so we can continue solving higher (and higher) level problems. This web crap has us stuck fighting in the mud going nowhere.
Yes. Exactly what you said. It bothers me when people think solving broken Javascript problems is a valuable way to spend our civilizations scarce skilled manpower.
Well, they at least provide value to people without too much externalities which makes them much better than both fighting in the mud and all the adtech work that drives this mess.
> I'd say building Win32 GUIs in C++ was easier than current Web stack.
>Same with Java AWT and Swing libraries.
I will have to vehemently disagree. I have no experience with Win32 GUIs, but I still have nightmares about wrangling nested LayoutManagers: comparing that to the current state of the web (especially after Flexbox) is downright absurd.
I am very happy with: Typescript + (Sass|LESS) + framework (Angular|Bootstrap|ReactJS). I think the 'hardcore' devs who would rather avoid using abstractions (frameworks/JS transpilers) will have a torrid time with the front-end.
And I have to disagree with you. Doing UIs in native frameworks like JavaFX or even in a pure C++/WinAPI, is much more saner than doing any kind of UI in HTML/CSS. Ignoring flexbox for a second, which is kind of bleeding edge new thing, remind me - how exactly do you vertically center stuff with CSS? :P.
My two main issues with doing UIs on the web are:
- web stack is terribly unpredicatable; you're trying to force an inherently document-layout-oriented model into a free-form 2D canvas, which leads to layouts exploding whenever user switches browser/OS/device/timezone/whatever.
- the code makes no sense; no matter how crappy the Java APIs were (due to deficiencies of the language mostly), the code you wrote at least did what it said, because it expressed the UI concepts explicitly. HTML/CSS is a huge mess of insanity when it comes to doing UI work. I mean, in what reasonable world should the idea "center this" be expressed as "set the left and right margin to 'auto'"? CSS is full of stuff like that.
(And then there are some silly philosophies like "separation of form and content" which everyone touts, but rarely anyone actually follows; see e.g. grid layouts.)
Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things. When first approaching this world you get confronted with alphabet soups of packages all combined to "make front end development sane". Everybody seems to have their own soup, though, and many claim that theirs is the way to do development. The flexibility that so many Node-style devs love leads directly to this impenetrability and fragility.
> Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things
If they do the same thing, pick one and dig in. I really don't get this argument - walking down the cereal aisle will not generate this amount of antipathy despite the amount of choice available; why on earth should development different?
The optimal taste, texture and crunchiness is different for everyone, you can even default to the traditional oats or corn flakes if the newfangled cereals are too brightly-colored or too confusing for you[1].
I love the JS ecosystem and its Cambrian explosion - lots of ideas (good and bad) being tried out by other people[2] and the good ideas tend to be adopted by the more mainstream projects.
1. This is obviously a thinly veiled allusion
2. This is important - don't be the guinea pig and don't jump onto the latest and greatest.
> If they do the same thing, pick one and dig in. I really don't get this argument - walking down the cereal aisle will not generate this amount of antipathy despite the amount of choice available; why on earth should development different?
If I don't like the cereal I've wasted a couple of bucks. Picking the wrong framework can be much more costly in terms of time/money. And with the amount of framework churn you can't even make a good decision because in two years time everyone's moved on to the next big thing.
And as he said (and it bears repeating): "This is important - don't be the guinea pig and don't jump onto the latest and greatest."
How to pick the right one: age ("old" but not too old) x community x documentation
For the simplest developments I used jQuery (which is a thin layer over pure JS). If you need more complexity you could go for a higher level framework (but there were not so great things like JavascriptMVC)
PHP gets a lot of bad rap but Fb is built on it
There is no perfect solution. When I see people "praising" Win32 I can just laugh (no, really, anything is better than this: https://msdn.microsoft.com/en-us/library/bb384843.aspx) but I think the advantage of that is that there was only few alternatives so once the learning curve was gone that was it)
I have returned back to native UIs development (WPF/Forms/XAML/Android), after 4 years of web development, couldn't be happier in what concerns my productivity.
The difference between what you are doing and what desktop UI has always enjoyed is a component system that works flawlessly. The Web Components specification is a good step forward in this regard, but as many people have pointer out, try to do something trivial like a modal wizard in Java/.NET and try the same thing on the web side.
But none of your examples are as cross system portable and "native/normal feel" as writing an app that only works in chrome/chromium.
For the decades leading up to this stage cross system GUIs with a few simple library dependencies have been an unachieved "easy" task. Web remains as frustrating as ever because now we need it to work on all non portable browsers even on platforms that supports better ones. Then we want new features at an alarming pace that GTK could never normalize across *nixes.
Using the only non-browser that I think sort of got cross system portability working as an example.. I don't think things functioned reliably against the weird m$, Ibm and gcj Java implementations. But since they aren't really GUIs themselves with bookmarks, and familiar menus, no one gets upset when you tell them to replace an odd Java implementation before running a Java program.
Why is native/normal feel the end-all-be-all of UI systems? I've never quite understood why this is so desirable. Or why the answer seems to be using a shoddy UI system stuffed in a browser frame.
Because chances are that whatever custom UI/UX design you come up with isn't going to be better (or even as good as) OS UI toolkits that've been designed by experts, battle tested for decades, and used for every type of application known to man.
Applications with native UIs also tend to give a a better impression of responsiveness, and they reduce mental load for your users since they're don't have to relearn much (if anything). They can rest assured that every button and popup menu and text field (for example) functions identically to every other such control they've encountered on the system and in other native apps. This is worth way more than most people think.
One easy example of this is text fields in OS X. Native text fields there all have a form of emacs key bindings built into them to make powerful text navigation and manipulation a systemwide thing. Every application built with Cocoa gets this for free, but more often than not applications using non-native UIs don't implement this functionality at all. This is highly frustrating when you've worked said bindings into your workflow.
I know a great coder who refuses to start personal projects because he can't find UI libraries which are:
1. Cross-platform across mac-win-linux-android-ios
2. Built for a compiled language such as pascal or C++
3. Built to use native controls
4. Integrated to registered libraries through an interface like activex
5. Accompanied by a UI builder with design-time and runtime states and component builders.
6. Easily integrated to embedded and server-side SQL.
Sometimes we impose too many constraints on ourselves and never actually start anything. Fear of success?
Good point. And actually, Delphi matches many of those bullet points. Expensive, though. (The promo of the free Delphi 10.1 Berlin Starter version just got over on Aug 9. First time in a a while, maybe, since Turbo Delphi Explorer.)
I think writing an IDE or anything else with editor integration during the editor wars would be a similar analogy:
- you could push one or the other
- you could try to support users on both side based on the editor variable
- you could go the new route where only users who care enough to invest do
- you could go the Jed simplicity route.
In the end, IDEs like jetbrains have the new route with plugins for the factions. Most lower investment cases do the Jed route which is more like web neutral. No one who pushed the unwanted editor on its opposing group seems to be still standing.
It is a good idea because you reduce the learning curve for end-users of application by the use of common controls. Think about the MS-DOS era, and then Windows came along, with the ubiquitous F1 key everywhere, Ctrl-P and Ctrl-S, not to mention the toolbars, etc.
I'm coming up blank trying to think of web sites and chrome based apps that provide a look and feel consistent with - and as performant as - what is offered by the native platform.
I think we could divide in two types of interfaces: for data entry and for graphics/complex. For data entry, html/css is extremely easy, but for complex specialized interfaces it could be more dificult.
I wouldn't call Qt Designer "easy" in any sense of the word, but possibly that is because I have found how good that sort of tool can be, and it is called Interface Builder (Xcode), which isn't perfect, but should be what Designer strives for.
I've built native ui applications under win32 (API itself, MFC, ATL), os/2, x11, qt, gtk and more. Developing UI for each of these was a thing I found much more straightforward than web applications over the last decade.
The initial learning curve was higher, but once you had that knowledge it remained correct and relevant for years- sometimes decades.
And your application UX was faster and smoother. The minor lag between user interaction and UI action that we take as a given today in all but the most basic applications simply didn't exist if you wrote your UI to conform with the platform guidelines.
Even poor performing complex UIs typically did better than today's well written complex UIs - on hardware quite a bit less capable.
We've accepted he current hodgepodge because of portability, but if you've ever worked with the base platforms for any length of time , the difference is painfully clear.
This doesn't touch on how you could expect a consistent ui experience across all applications on an entire platform. It's hard to get that across even two web sites.
We are currently well into a full generation of developers and consumers who are unaware of what's being lost, because most of their interactions are with browser base applications and mobile phones. Waiting a few dozen to a few hundred extra ms for ui to respond is considered normal, if it's noticed at all.
Yes, from a purely presentational aspect, HTML/CSS is way better than Win32, etc. Things like a virtual DPI, easy-to-use transparency and alpha blending, no paint cycles, and much more.
However, displaying a modal window and handling messages in a local window-specific message loop is easy in Win32, and much more difficult in HTML/JS. In general, the browser makes it much more difficult to deal with synchronous operations like modal windows and server requests that require the application to wait on the response. This is how you end up with the overly-complicated mess that is callback-hell, which is then solved by another overly-complicated mess called promises.
So, presentation functionality = A+, foundational functionality for UIs = D.
But you should really compare these with modern desktop UI development. Anchors are awesome in .NET and don't get me started with Java layouts. UI design truly is better on the desktop side. Maybe it will be more difficult for a designer to develop a nice interface for a desktop program but that's about it.
I totally disagree with this. It is far easier to build an application in shitty old MFC than a thousand attempts and 10,000 random attempts to fix things in no content way.
The problem now is nobody can rationally understand the complexity. At least that was known before.
Perhaps the language may have been a barrier to some back in the day, but complexity vastly transcends that small issue.
Performance yes, you can't compete with that one because browsers don't let you control the low-level stuff. But the speed of development and the ease of doing complex layouts with css is hard to match (when you master css enough, of course), specially if you're trying to do UI from the code directly, without IDE helpers and visual builders.
The speed of development is very fast for the first 75%, and comes to a screeching halt for the last 25%. The web stack has no good way to answer basic questions like "does the user have arrow keys" or "what is the current mouse position." That's the point that you start to layer on the "hacks on hacks" that OP references.
True, but it should be possible to create high performance UI controls inside an HTML5 canvas element.
With canvas, every browser has hardware accelerated immediate mode rendering that could be used to create UI toolkits. Looking around the web, there are some attempts to make this happen, but none of them seem to be hugely popular.
Last time I looked into this (years ago), a big blocker was that nothing inside a canvas element is visible to accessibility APIs, so UI rendered in a canvas would be invisible to people using assistive technologies like screen readers.
Replace "WIN32 or MFC" with "iOS or Android" and the point still stands, especially on mobile devices where processing power is limited and battery life more important.
The web lets you reach a large audience in a way nothing else can. You have to get over yourself about the tools not being elegant, and make sure the thing you're using the flawed tools for is worth the aggravation.
The fact that you can reach a massive audience doesn't make any less true that the tooling sucks. If that first fact wasn't true, we would not be commenting on this issue...
That doesn't mean it isn't terrible to work with and couldn't be much better. Unless you think the tool flaws are inescapable aspects of reaching a large audience?
Jokes aside, the history of mathematics is a pretty worthwhile subject to study to truly appreciate the importance and implications of tools (or mathematical discoveries in this case). There's a reason why it took humans 2000 years after Euclid first wrote his 'Elements' to discover non-euclidean geometry...
Interesting, what native UI system is in your opinion easier to work with than web? Why then so many devs choose to use WebBrowser wrappers to render their desktop/mobile UIs because it's way faster and easier to develop with?
> Interesting, what native UI system is in your opinion easier to work with than web?
I'll answer that: every single one. I haven't ever seen a GUI system more complicated than the HTML/CSS/JS mess. The problem with these is that at first glance they look easy. Doing 'hello world' in HTML is little more than actually typing 'Hello world'. They only become a mess if you try to do something reasonably complex. The end result of this is that there are many people who start out with HTML and stick with it. They simply never experienced anything different.
> Why then so many devs choose to use WebBrowser wrappers to render their desktop/mobile UIs because it's way faster and easier to develop with?
No, it's cheaper to develop with. There are many more 'web developers' out there than mobile developers and they are usually very cheap to hire. The goal of corporations is not to build the best UI or to use the best tools, it is to make the most profit. A web-UI is usually considered good-enough by the suits and web 'developers' are a dime a dozen.
Which specific ones, for example? "Every one" could cover a lot of ground and doesn't have much information content. It's doubtful you have experience in every one, and it would be useful to know which specific ones have been tried and seem better.
AWT, Swing, Cocoa/CocoaTouch, Android, GTK+, QT, VCL, SWT, XAML, XUL, J2ME Polish are the one's I've used.
If I had to write a Web application I would probably start by writing a UI toolkit from scratch based on HTML5 Canvas and just bypass the whole HTML/CSS nastiness. I've written UI toolkits from scratch before (all the way down to the text rendering engine) and even that was probably less work than trying to work around HTML's mess.
The answer to your second question is manyfold. First, it makes a false presupposition, web development is not faster and easier. Second, most devs probably chose the browser as a platform because Apple was so tremendously successful at creating artificial "application barriers" -- making it uneconomical, problematic or even impossible to create well-behaving cross-platform applications. Building application barriers used to be Microsoft's primary concern (they invented the term for internal correspondence), they fought hard against Sun's original vision of Java, but has become Apple's main trump card for while, after Apple decided to give up making great and innovative hardware. Third, mobile apps became sexy but the fragmentation is too high (even just Android is way too fragmented).
So many devs and companies bite the bullet and decided to make a web page for desktop and mobile phones/tablets as a least common denominator.
If you disagree, show me one non-trivial web application with the performance and a user interface that matches or outscores a corresponding native application, and we can discuss why it's better than the rest and an exception. So far, I haven't seen a single example but there should be one or two.
Delphi 7 designer was a great improvement over delphi4 (we still use it at work) and yet delphi 2007 fixed some soap bugs and xe7+ is pretty decent as a cross platform ui development IDE.
You should try a newer version of the IDE/compiler. Delphi 10 Seattle and 10.1 Berlin are pretty damn good. Fast load times, editor is solid. The only real downside to the whole product is that the VCL (still) needs better layout management and easier ways to cope with scaling on high-DPI displays.
Many of those that use WebBrowser wrappers never used anything else other than web tools and aren't even aware of the RAD tooling we used like Delphi, for example.
What's the alternative? The division of platforms is a fact and how can you deal with it by only programming native apps? This is the best solution people have come up with. You talk as if it's all a hugr waste of time. I don't think so.
However, Unix doesn't suck half as bad as web development. Web development keeps a lot of problems alive that have been overcome in Unix development and everywhere else.
That's kinda the problem, though: Unix really is worse than VMS or Lisp Machines, when measured on certain axes (and I love Unix!); rather than fix it, or replace it with something even better (e.g. Plan 9), the computing industry has instead decided that POSIX is the end-all, be-all of OS evolution, and collectively ignored all the ways that life could be better.
It's very difficult, as I get older, not to survey the computing landscape and be profoundly bitter about our absolute and utter refusal to use better tools in order to achieve greatness. It's like people choosing to eat McDonald's when they could have an affordable home-cooked meal prepared for them, for essentially the same cost.
This is what makes me focus more on Windows, macOS and the mobile OSes.
Because these systems moved beyond what plain POSIX means.
Even on Apple and Google's OSes, their UNIX underpinnings are not that relevant, because most of the user space libraries and APIs don't have anything to do with UNIX.
Windows has its own legacy baggage and I wonder about the proposition that the mobile OSes' Unix underpinnings aren't relevant. Depends on what you're doing, I'd think.
Windows might have its own baggage, but with Windows 8 they have brought the original design of .NET from the ashes and assuming the current path is to maintain, those of us that like Windows will have a nice OO ABI alongside safe languages compiling to native code.
All the mobile OS relevant APIs don't have anything to do with UNIX.
All the Objective-C, Swift, Java, JavaScript, C++ APIs available on those OSes don't depend on being implemented on top of an UNIX kernel.
I mean .NET Native and the lessons of Midori finding their way into C# 7+ and C++/CX, alongside with emphasis on the C++ Core Guidelines, which started at Microsoft before Bjarne got involved.
People used COBOL to run large companies too. (Hell, they still do.) Doesn't mean it was particularly good for any definition of good.
Even the big companies can't do pretty basic things on the web, like justify text beautifully. It's not hard to imagine another world with much better typography on the internet. Ditto for better languages and a better layout system.
Most importantly, just because something has broad support and took a lot of effort does not put it beyond sharp criticism. That's no way to make progress and a perfect way to make entrenched worse-is-better technologies that managed to get popular even more entrenched.
> Facebook, Google and Microsoft all use the web stack to run huge companies.
And they throw huge amounts of resources at the web stack to do it. It might work for them, but I'm not sure that makes it powerful, performant, and manageable for those of us who aren't huge companies.
You probably do not have the complexity level of these companies either.
To me js and css are kind of manageable, a bit the same way as python: use strongly enforced linters forbidding anything ambiguous, do not jump every other day in a new sexy bandwagon, and do not let one line of code commited in without an automated test running it on a ci machine.
What I found harder to manage is the young FE devs themselves: for them it seems every new project, or every new view in the same project, is the opportunity to use a completely different, new toolset. Oh, and some new syntaxic sugar candies supposed to "save" a couple of keystrokes (which is the worst reason you can find to use a new syntax requiring its own tools). I find this very dangerous, especially when the github repos holding these tools are 3 months old.
> What I found harder to manage is the young FE devs themselves: for them it seems every new project, or every new view in the same project, is the opportunity to use a completely different, new toolset. Oh, and some new syntaxic sugar candies supposed to "save" a couple of keystrokes (which is the worst reason you can find to use a new syntax requiring its own tools). I find this very dangerous, especially when the github repos holding these tools are 3 months old.
This is because employers are demanding that candidates know the latest and greatest technologies (eg. looking for 5 years of experience in 1 year old technology). I'm an FE dev, and during my last round of interviewing 3-4 months ago I was asked about my thoughts on Redux, CSS Modules, Radium, Docker, GraphQL/Relay, ClojureScript/Om, etc.
If I need to be experienced with this stuff to stay employable because just doing my job isn't enough, then I'm going to learn it.
As an employer I would be negatively surprised if a candidate for FE never heard of react, angular, etc. But I also see a red flag of the candidate were to assure me to be knowing all of them bottom up. That would mean a lot of toy projects and unstable personality, if not plain lies. I'd be looking for someone able to work for some years on a code base, grasp its stack, improve the overall structure, quickly find and fix bugs in a sustainable way, etc.
Or move to the back-end, where things move at a more survivable pace. Here's the dirty secret, too: for the most part, the work you do there is actually easier than front-end work, since you have better tooling and frameworks that don't shift under you like quicksand. And building a CRUD backend to a REST API might be a tad tedious, but it's a whole lot less fiddly than mucking about with CSS and trying to make web UIs pixel perfect in every mongrel browser under the sun.
Honestly I would if not for the fact that backend interviews always test Crack the Coding Interview style data structures & algorithms knowledge, which I have no interest in spending my limited spare time preparing for (I didn't major in CS).
Your last paragraph describes my experience with web development exactly. Ironically I'm 22, but I've worked with people or talked to people online who want to use the "latest and greatest" for what could've been a simple CRUD app.
Javascript, CSS and HTML can all be used powerfully, performantly and in a managed way where anyone can come on board and contribute.
I disagree. Compared with other languages and technologies used for similar purposes, none of JS, CSS or HTML is particularly powerful or efficient, nor do any of them provide particularly good tools for helping new developers get up to speed or co-ordinating large teams working on the same project. I initially wrote a huge set of specific examples to support these claims, but on reflection I'm not sure criticising JS/CSS/HTML in excruciating detail would really advance the discussion here. Suffice it to say that best-in-class programming languages, document preparation software like TeX or high-end DTP applications, and representations like PostScript and PDF, have all been doing everything JS/CSS/HTML can do and much more for a long time.
Facebook, Google and Microsoft all use the web stack to run huge companies.
That's not the whole story, though, is it? For example, both Facebook and Google became successful primarily for the hard problems they've solved on the back end, particularly in terms of scalability. Facebook's main web site is nothing special in general UI terms, and their web-based tools for advertisers are awful. The search engine that took Google into the big leagues was famously extremely simple on the front-end, and while today they also have applications like Google Mail and Docs/Apps/whatever it is called this week in their portfolio, again the front-ends for those are still relatively simple in general UI terms and would probably be unremarkable in any other context.
To broadly paint this web stack that so many people poured countless hours into making, as 'impossible' to use is doing it a great disservice.
I don't see anyone saying it's impossible to use. However, it's probably fair to say that the state of the art in front-end web development is between one and two decades behind the general programming community, and that many relatively inexperienced people working in the web field are slowly but surely learning the same lessons (and repeating the same mistakes, and repeating them again) as the rest of the programming world did before. One of the biggest problems, IMHO, is that quite a few of those people now work for influential businesses like Google and Facebook, which means quite a few even less experienced developers assume they know what they're doing. And that's how you get framework fatigue, left-pad, "living standards", sites and apps written more than a year or two ago no longer working in modern browsers, and other such madness.
The corollary to that is that the system uses components that target the lowest common denominator. I'm not sure "anyone can contribute" is a good foundation for any complex technical endeavour - if we are speaking specifically of implementation.
That is not a corollary. While I disagree with the person you are quoting as far as web frameworks are concerned, this is about organization and documentation, not "components that target the lowest common denominator".
The first two paint points are perfectly solved by GWT[1]. But for some reason it isn't picked up by web community, even though you can still make really cool web apps with it.
GWT has been continually approved upon. Compilation is super fast now, and developing is a breeze with super dev mode. You can even debug your Java (precompiled) code within chrome. as a GWT user, I don't have to worry about all those things that trouble Javascript developers. Refactoring is easy as it is just Java.
Having used it for one or two projects I can say it solves some problems, but creates others, when trying to do more complex stuff it can be a pain (can't remember any specifics it was a few years ago).
> Facebook, Google and Microsoft all use the web stack to run huge companies.
It does require huge companies like these to work with the web stack painlessly and they're behind initiatives to make it even more cumbersome. You could say that they have an incentive to hamper competition by screwing up the web and they're doing it well.
I agree with you here. The front-end (JS, CSS, HTML) are there to stay and can be organized into clean and maintainable modules. Its not technically difficult but it is humanly hard: you need to put in place best practices, peer training and have lots of discipline. Lots of people are turning to React - probably because it gives you structure.
Often a developer is thrown into a stack that was built crooked and gets discouraged. Instead, its your job to get in there and clean it up. It may take months but you'll you yourself and your team a big service!
Hi, I'm the author of . It's my take on an anonymous location based chat. It's written in react, using node.js, websockets and a redis backend - deployed to heroku. I'm a big fan of omegle and slack, so I took some of the best bits and mashed them together with the gelocation API.
We've been working on a more thorough solution since then. I've posted about it many times, e.g. https://news.ycombinator.com/item?id=10104936, and no one will be more relieved when those days are over. I just hope everyone doesn't still disagree and propose more 4-minute fixes forever.
The API is available but not everyone has switched to it. There is a valid argument for backwards compatibility, like Linus refusing to break userspace even when it means rejecting some improvements. However, I'm in full agreement with you here. The benefit of usability improvements far outweighs the disadvantages of breaking screen scrapers, especially when so many of those scrapers exist solely to make HN more mobile friendly.
I'll look up the link, but previously dang (I think?) said that it will be slowly improved, in a minimal-impact sort of way.
Introduce the HN API gradually, get the scrapers to shift over to it, improve html generation and css used. Would be interesting to hear updates on that.
Just increase the font size on the main page by a couple of sizes. On both Chrome and FF Mobile it have to zoom in like crazy just to click on the "# comments" link.
Can I ask why, when using FF on Android showing the mobile version of HN, replies appear using different font sizes? Some are tiny, some are actually readable.
I have to zoom/unzoom constantly to read just a thread, or switch to the desktop version, which doesn't have this issue.
But there is no commenting, upvoting, etc (b/c of CSRF).
I tried rendering Hacker News in an iframe on a page with zoom set but they set X-FRAME-OPTIONS: DENY which destroys any hope of cross-origin css magic.
[edit] just tested zoom with a site that can be iframe-d and my css hopes were squashed - the size of the iframe is zoomed, but not its contents.
In fact, in stead of the ugly hack with background-image gifs for the tiny vote-buttons -- why not just use a couple of link-elements with proper unicode ▲ ▲ ▼ ▼ glyphs? If for some bizzare reason one wants to keep adding this via js in an otherwise very html4-ish design, those could be added with some css :after-magic -- but I don't see why one would do that.
Can you at least add an option to enable mobile CSS and view port settings on a per account basis? I know there are a lot of people on here who love tiny fonts but there are also lots that do not.
I've had this idea for quite a while for git visualisation tool where you open a project and can open a file and scrub through the timeline and see the changes live.
The fact that this idea is better suited inside an actual code editor (and not just a standalone app) and me not being brave enough to tackle writing a code editor is what is stopping me from doing it.
It seems to be caching game assets. After loading the game once (which took a while), the subsequent loading times were dramatically reduced. Though this is purely based off of quickly opening and closing the website, so I can't completely verify anything.
The browser already caches most things, and caching binary assets (like graphics) in localStorage would require base64 conversion, adding 30% of bloat to data size, not to mention computational overhead.
You would think the quality of the product already would accommodate a remote scenario, it's a really worthwhile addition even for casual consumers who do not actively participate in discussion.
