161–170 of 231 posts
Well, this is what people keep telling again and again, as if it was enough to repeat it to make it real, but I still have to see one web application that I would prefer to use over a desktop one.
Sure, we have hugely complex webapps, but the browser is a really a shitty environment to think of it as a "platform" to do anything else than to read documents.
Earlier quoted context omitted.
I agree with everything you wrote here. I too see the problem as primarily systemic. The problem here is also that users are kind of "captive consumers" of software; i.e. more often than not, there's no other choice besides either using or not using a piece of software. And even if there is a choice, it's usually between two or three pieces of softare, all competing with each other on shiny features and accumulating…
Well, since the problem is economic, the stink has to be economic. For consumers to make a stink, it means they have to withhold their money and stop purchasing wasteful products, not voice their complaints after purchasing. Despite how much time we all spend solving problems we fear we have but don't really have, most devs don't actually have the option to spend significant portions of their time optimizing, even if…
> For consumers to make a stink, it means they have to withhold their money and stop purchasing wasteful products, not voice their complaints after purchasing.
Yeah, but that's not easy to do either. I added that point in the ninja-edit to my previous comment. In my experience, in many areas consumers don't really have any real choice. I.e. you choose from what is available on the market, not from the space of all possible products. There is no good line for getting feedback from consumers to producers about options not explored, or even about the reason you refrain from buying something. Again, I currently have no idea how to approach this.
> Ember has always been driven by the idea that web apps are becoming more and more like native apps over time. Well, this is what people keep telling again and again, as if it was enough to repeat it to make it real, but I still have to see one web application that I would prefer to use over a desktop one. Sure, we have hugely complex webapps, but the browser is a really a shitty environment to think of it as a "pla…
Sure you have, I would make a huge bet you've used a website that you were unwilling to install the app for. On-demand, truly cross-platform app deployment is a huge feature, not to be underestimated.
> Ember has always been driven by the idea that web apps are becoming more and more like native apps over time. Well, this is what people keep telling again and again, as if it was enough to repeat it to make it real, but I still have to see one web application that I would prefer to use over a desktop one. Sure, we have hugely complex webapps, but the browser is a really a shitty environment to think of it as a "pla…
> but I still have to see one web application that I would prefer to use over a desktop one. Sure you have, I would make a huge bet you've used a website that you were unwilling to install the app for. On-demand, truly cross-platform app deployment is a huge feature, not to be underestimated.
HN!
(Especially messing with scrolling, badly.)
"The trend started by minifiers like UglifyJS and continued by transpilers like Babel will only accelerate." Those were predated by Closure Compiler, which was started with Gmail, and Closure Compiler in some ways still doesn't have an equal. Besides being a fully optimizing compiler, it also has a module system for code splitting, and optimization passes designed to move code at the method/property level from initia…
This seems to be something of a trend in the software library and tool world: A problem emerges. Some early, sharp thinkers create tools which attack the problem in a high level, abstract, powerful way... but also with the rough edges that come with being early. These tools get a few adopters, but not that many because it is difficult to see the value versus the obvious rough edges. Then other sharp thinkers, put off…
Altair -> Apple -> IBM -> Dell & clones. UNIX -> System V -> BSD -> Linux. MapReduce -> Hadoop. GMail -> Closure Compiler -> Traceur -> Babel. Google datacenters -> AWS -> Docker -> Kubernetes.
Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent…
"I'm wondering if there is a more holistic approach." The end game, once WebAssembly is fully integrated into the browser, is to expose the 3D API and/or a high-performance low-level 2D API (or both) and slowly, but surely, a "web browser" will become an environment where you download a full rendering engine for a website, written in an arbitrary language that has WebASM support, and in the end both DOM and JS will b…
Domain specific languages I suppose are the next cool aid. Or languages with a comprehensive macro system (like Elixir) can bridge the gap between these ways of thinking. This feels very frontend focused though - I'm wondering if there is a more holistic approach. I have an idea for a framework/project, that over web sockets, views the browser as a thin client for a server side representation; commands would be sent…
"I'm wondering if there is a more holistic approach." The end game, once WebAssembly is fully integrated into the browser, is to expose the 3D API and/or a high-performance low-level 2D API (or both) and slowly, but surely, a "web browser" will become an environment where you download a full rendering engine for a website, written in an arbitrary language that has WebASM support, and in the end both DOM and JS will b…