> The community has tossed out everything we’ve learned from the last 30 years of building applications in favor of being able to put something together quickly with complete disregard for maintainability or extendability.
That's spot on. You can add in to that that all the lessons of the process of developing software have also been discarded and are slowly being re-learned.
It is as if with the birth of the web there was a complete reboot of the IT industry which accidentally also re-formatted the drive that held our knowledge about how you go about software development (which is different from knowledge about what it is that you are building, and different still from the technical details of your implementation).
When it comes to technology messy is not a feature but a drawback. It precludes a very important thing from manifesting itself, reliability. The difference between the backbone of the internet (TCP/IP) compared to the maze that is web development is simply astounding. The amount of hoops you have to jump through to do stuff that was child's play on any computer 20+ years ago just because it is on the web completely baffles me.
People are actually proud of being able to make simple games or chat services using a browser. That is because it is so terribly difficult to do such simple things using the web as a delivery device.
- HTML
- JavaScript
- CSS
- Server side code (pick your flavor)
- HTTP
- websockets
- some real time extension (node or whatever)
- a persistence layer
And all that for the basic functionality of tying a few people on graphics terminals to each other. Oh, and to make it more interesting we're shipping actual code from one location to another so you have a few security nightmares extra.
I think you're underestimating the complexity of native apps. To duplicate functionality of a web app, you're still going to need to know your networking layer, whatever it is, and you still need to write a server and persistence layer; the only difference is on the client, where instead of HTML/CSS/JS you're building in one language... plus probably a GUI framework (which are not exactly known for their simplicity or ease of use). And there are security issues related to distributing native binaries too. When you say there are tons of extra 'hoops' to jump through, what do you mean?
I was on the Internet regularly 25 years ago. "Simple network games" did not exist, they had incredibly complex protocols and failure conditions (remember setting up Netrek?).
Chat services also incredibly difficult to run correctly over the Internet that there was no proliferation, there was... IRC. Which had its own major messes (recalling EFnet netsplits almost hourly in the early 90s).
Or let's talk about BBS'. So, you could do ANSI art fairly easily, but let's recall the hassle of handling multiple users on the software of the day. You usually didn't. BBS games (Tradewars, Legend of the Red Dragon, etc.) were turn based - someone dialed in, played their turn for the day, and waited for everyone else to dial in and play their turn. Email and Fidonet EchoGroups came in daily, or maybe twice a day, when you dialed into your upstream provider. The only way you could run a multitasking BBS with multiple phone lines was mostly DESQview, OS/2, or the BBS software itself had its own multi-threading.
The Internet didn't replace IRC and BBS'... the Web did. Not that they're gone completely, just no where near as important as they once were.
Network games are OTOH are still as complex as Netrek because they don't fit a Hypermedia architecture.
But ultimately I think you have nostalgia for a better world that never existed. Which is fine if you want inspiration for new ideas but... it is important to understand why the Web won: for many cases, it was better than what we had.
While you've undoubtedly worked at some great shops with other great engineers...can you say that the IT and development industry isn't as rickety as web development seems today? I mean, how can we really know? Today, we have github and stackoverflow and a myriad of other coding boards in which we can see the most horrible of code snippets -- and the way the mind works, we usually remember the horrid examples more than we do the average or decent ones. But we lack an ability to perform similar introspection on older code bases. But I think we've seen enough shoddy legacy code to assume that development has always had a variance in quality
I worked in a consultancy that primarily deals in websites and small apps for clients. Projects were generally underbid and handed to designers and engineers with the impetus to hurry your ass up so we can make money on this. As such, we were constantly throwing stuff together, duplicating code used elsewhere, no DRY, mounting technical debt. Don't get me wrong, this worked for us, so I couldn't complain much...
However, what irked me is that this mindset flowed into the SaaS and native mobile app-development side of the house as well. Fully or partly-spec'd native development is expected to result in something pretty and take no time at all, just like the web-design side. Very little interest in engineering things properly.
Fear of over-engineering absolutely should be ever-present as part of your efforts. But, I think we're taking this to extremes sometimes.
It's more like the ease of Web programming opened up programming to an entire new slice of the population that would never have had the opportunity to become programmers before.
These people don't have computer science degrees, so they spend a lot of time reinventing wheels. But lots of it works well enough despite all that, and as time passes, they learn and get better.
The messiness is a good sign, not a bad one. Thirty years ago these people would have had no options other than to be passive consumers of software other people made. Now they're making things for themselves! And some of what they make is good enough to help other people with their problems, too. That's a positive development, even if the things they make aren't always pretty.
I'm old enough to have used HyperCard, and while it was an excellent environment, it had some serious barriers to entry. For instance, using it required an expensive development kit, namely a Mac. Back in 1987 even a lowly Mac Plus would cost you $2,500, which in today's dollars is more than $5,000. Contrast that to the Web, which you can author for on the oldest, crustiest commodity hardware you please and where even back in the mid-'90s you could get started with just a text editor and a few bucks a month for hosting.
"HyperCard was far more accessible to non-computer scientists than the web is or has been."
A simple comparison of the total number of HyperCard stacks built versus the total number of Web sites built would argue otherwise. You can argue about whether HyperCard authoring is more intuitive than HTML authoring (I think it was), but as soon as the Web came along people decided for themselves which of the two they preferred to hack on.
> I'm old enough to have used HyperCard, and while it was an excellent environment, it had some serious barriers to entry. For instance, using it required an expensive development kit, namely a Mac. Back in 1987 even a lowly Mac Plus would cost you $2,500, which in today's dollars is more than $5,000. Contrast that to the Web, which you can author for on the oldest, crustiest commodity hardware you please and where even back in the mid-'90s you could get started with just a text editor and a few bucks a month for hosting.
Any computer was not cheap in 1987, much less one that sported a usable GUI environment that could run something on par with HyperCard. That had nothing to do with HyperCard.
> A simple comparison of the total number of HyperCard stacks built versus the total number of Web sites built would argue otherwise.
There were far, far fewer people actually running computers, much less collaborating on the internet, 26 years ago.
> You can argue about whether HyperCard authoring is more intuitive than HTML authoring (I think it was), but as soon as the Web came along people decided for themselves which of the two they preferred to hack on.
When the web came along, Apple had already made HyperCard inaccessible by charging a significant amount of money for the authoring tools, rather than shipping it with each Mac.
Even still, people were producing "My Favorite Links" and home pages, not apps.
"Any computer was not cheap in 1987, much less one that sported a usable GUI environment that could run something on par with HyperCard. That had nothing to do with HyperCard."
True, but (1) PCs were significantly cheaper than Macs, and (2) many, many more people already had PCs on their desks than had Macs. So unless you were one of the few who already had a Mac, getting started with HyperCard meant plunking down money for new hardware.
"There were far, far fewer people actually running computers, much less collaborating on the internet, 26 years ago."
Again true, but irrelevant. We're talking about contemporary mindshare, and starting in the early '90s HyperCard and the Web were competing against each other in real time. HyperCard had a long head start and yet even by 1995 (the year Netscape 1.0 broke out) it was clear the Web had all the momentum.
"Even still, people were producing "My Favorite Links" and home pages, not apps."
And the buzzed-about HyperCard stacks were always more like presentations than apps. So?
I'm not trying to run down HyperCard here, it was a brilliant, revolutionary product. But I just can't fathom how anyone could think it more accessible to newbies than the Web was at the same time. And the Web has only gotten more accessible in the years since.
Your examples all explain market forces that led to the web's rise -- rather than technological reasons.
> True, but (1) PCs were significantly cheaper than Macs, and (2) many, many more people already had PCs on their desks than had Macs. So unless you were one of the few who already had a Mac, getting started with HyperCard meant plunking down money for new hardware.
In 1987, the web wasn't invented yet, and Windows 1.0 was the best the PC had to offer. This had some interesting results in the marketplace, but doesn't really explain much other than the fact that there's value in cross-platform implementations.
Apple wasn't interested in making HyperCard/Claris cross-platform, so they didn't.
> Again true, but irrelevant. We're talking about contemporary mindshare, and starting in the early '90s HyperCard and the Web were competing against each other in real time. HyperCard had a long head start and yet even by 1995 (the year Netscape 1.0 broke out) it was clear the Web had all the momentum.
I remember that time quite clearly, and until the mid-to-late 90s, HyperCard and the web were in COMPLETELY different spaces.
People were building complex enterprise database-backed applications on top of HyperCard; meanwhile, on the web, we had static pages, and post-1993, if you were lucky, CGI-based e-mail forms and visit counters.
Even with the introduction of JavaScript in 1995, we didn't see much other than rotating banners in the status bar until much later. Simply put, the web was not being used for applications at that time.
By the time the web did "break out" in 1995, Apple had moved HyperCard to their Claris subsidiary, stopped producing updates, and started charging for the authoring tools (a funny thing to do, given that HyperCard had always been Smalltalk-like in combining authoring and consumption).
Essentially, the lack of updates and unreasonable pricing led to its demise. These are market forces, not technological ones, and do nothing to disprove that 26 years ago, there were tools accessible to normal humans.
> Even still, people were producing "My Favorite Links" and home pages, not apps.
I first went online in 1991 (so that my friends and I could keep playing Shadowrun all winter) and got into the web in 1993 (I was 16, pictures were a big deal). Back then, there was this sense that the web could be really great, but I don't think many people grasped what it could be used for. Search technology wasn't great, so starting on someone's home page and surfing was how most people explored the web.
The first thing I ever built on the web was a homepage for a Shadowrun character. It was basically walls of text in which I talked about his complete history, and a whole lot of links to gaming resources. Needless to say, I got all the girls in high school....:)
Thanks for taking me down memory lane - sometimes I forget just how incredibly excited I was when I first discovered the online world. Without a hint of hyperbole, I wouldn't be who I am (in fact, I might not even be alive) if not for the web. :)
Being an egalitarian, I have to keep reminding myself of this, even if I recoil at how messy some of the results are. Still, it behooves us to pause and reflect, and maybe consider if there is a better way? The first comment I read in this thread said that Obj-J and Cappuccino were hell to deal with, and much as I scoff at the idea, some people (read: a whole lot of web developers) aren't willing to spend a couple of days learning a new toolset. What we need to do is take the good stuff, the optimized, polished debugged and proven software and move it beyond merely libraries, toolkits and frameworks: we have to make it easier to use. This same dichotomy exist(s|ed) between PHP and everything else (eg, Perl, Python, Ruby), and inroads are being made there; why not try to make the same inroads with our web frameworks?
I can't say that this is a problem specifically in the web.
The landscape is littered with C frameworks, C++ frameworks, Java frameworks, .NET frameworks, and so on for every other language, that serves to abstract so much from the basics that it becomes so difficult to do basic things the <insert framework here>-way. The problem is that instead of being ancillary and supporting productivity, they are opinionated and try to do EVERYTHING for you, which just makes them really crappy DSLs.
This just happens to occur on the web a lot more because what we have to work with is inconsistent, sometimes poorly implemented, and confusing as hell to new players. So everyone and their dog tries to "solve" developing web applications by making you believe the DOM doesn't exist (jQuery, MooTools, etc). Some think HTML and CSS are too complicated and try to get you to believe those don't exist either (Ext, etc). Then some want you to forget that Javascript ever existed, or to make Javascript less Javascripty (GWT, Prototype/MooTools, etc).
The end result is a lot of opinionated dogma that rarely actually help us get things done (or get in the way more than help). If you pick a big framework, it's usually very good at whatever it was designed to build. But if you want to build something even slightly outside of that set, it becomes a massive cluster-fuck of WTF-inducing horrifying debugging and pain. Only the lightweight libraries that are massive value adds without enforcing a specific dogma on the user have been extremely successful.
The problem is that everyone is too opinionated and makes their software try to do your job for you. It's not really about the ease of use, it's about the ease of integration, extension, and whether they make our jobs easier or nightmarish. Yes, the web foundation is far from perfect, or even great, but most of these frameworks are far, far worse, since they massively and arbitrarily limit what you can do for the sake of some vision of simplicity.
The same problem exists in the native world. There is no consistent presentation layer that rivals the web, and even it isn't fully consistent (all browsers are different, and even the same browser on different platforms can behave differently). But it's a far cry from anything else.
As an aside, since JS isn't assembly, using it as a compile target to build applications foregoes a lot of the other fundamental technologies in a web browser. Sure, you might be able to compile <insert language here> into JS and have an application run in the browser, but that necessarily implies you're doing things like building the DOM manually, and sites like this tend to have significant performance issues. If you want it to work well, the best way currently is by using HTML/CSS/JS and by not letting a gigantic framework pretend that those things don't exist.
It is as if with the birth of the web there was a complete reboot of the IT industry
The web won. It fought a battle against many foes, and it came out on top.
Re-read that again and seriously think about it, because comments such as yours don't accept that simple reality. Do you contest it? Do you argue that the web somehow circumvented the competition?
For 15 years I've been promoting the web with groups that I've consulted with or led. For 15 years competitors have arisen with various alternative strategies, including MFC applications, Java Applets and then Web Start solution, .NET Winforms and then .NET WPF applications, Flex and Flash applications, Silverlight applications, and on and on.
And they all fell by the wayside. They lacked in features. They lacked in agility.
The only competitor that has made serious inroads are native apps on mobile devices, eking out an advantage due to the unique profile and unique input techniques of those devices, and of course gaming given that the web had no interest in gaming. The web is adapting.
If the advantages that you hold are true (in another post you argue that we salivate over stuff that was trivial 20 years ago. Yet ignore that we do things on the web that are just incredibly rich with but a few lines of markup and some ancillary code), those apps should have long devastated the web, teams making secure, easy to construct apps that run circles over those poor web developers.
I feel the true 'reboot' and memory loss happened with native mobile apps. How did we ever think this would be a good idea? As you mentioned, the unique inputs seemed to have temporarily blinded us to real progress we've made with the web. Why can't web-based apps accept all these inputs as well?
The other big problem we have is that we're stuck with this idea of having cute little icons to launch things. Why can't we have icons that just launch a specific URL? Because then App Stores wouldn't make any money then would they?
Edit - Would someone care to explain their downvotes? Surely HN users wouldn't think to use a downvote to express that they just disagree, right?
> Why can't we have icons that just launch a specific URL? Because then App Stores wouldn't make any money then would they?
That's what iOS 1.0 did. There were no native apps, just web apps that had cute icons that launched a specific URL.
People tried very hard to make that work. It didn't. The breadth and depth of mobile applications we see today only occurred once Apple provided a native SDK.
I think Palm & WebOS were on the right track by making their native apps still based on web technnologies. As far as I know there weren't any mobile inputs that those apps couldn't handle. Blaming limitations on tech seems silly. The decision was a business one.
Besides that, why take away the ability to create webbased apps? Could we not have the option if I know I don't care about any of the fancy stuff. There are so many apps out there these days which are just shells of an app with a WebView inside. It feels a bit ridiculous to have to buy Apple hardware to make a shell and then use our preferred dev environment to develop the site/internals of the app.
You can just write web apps for the iPhone, even today. And yes, you can create an icon in Speongboard so that it looks just like a native app. That's how I use Google Maps on my iPhone.
There were plenty of discussions about HTML5 vs native mobile apps. Big companies like Google and Facebook extolled HTML5, partly because they needed leverage against Apple's stronghold over the dominate ecosystem. So yes, the decision was a business one to begin with.
Then when reality didn't fit their agenda they've all since switched positions in 2012. Facebook rebuilding their iOS app with Obj-C, for example, to be as fast as possible. So then the decision ultimately became a technical one.
Maybe it'll flip flopped around soon. We did go through a period in the 90's when CD drives came out and everyone rushed in to deliver as much multimedia content on CDs as possible before that industry died and gave way to the ubiquity of the Internet.
>I feel the true 'reboot' and memory loss happened with native mobile apps. How did we ever think this would be a good idea?
Native apps weren't a good idea for innovative reasons or to push boundaries of what's achievable, they were a good idea for business reasons: vendor and platform lock in.
And yet web apps don't seem to solve vendor lockin either; see Facebook, Twitter and most recently (and poignantly) Google Reader. And before you mention that people were able to move from Google Reader to something else, you might want to consider it was because it was based on an open protocol (RSS) that wasn't tied to either native or web.
Unfortunately, this argument (which tends to imply technical excellence should trump all other factors in the success of a technology) has been used in technology for a long time, but frankly, in the end doesn't matter.
> The web won. It fought a battle against many foes, and it came out on top.
It won what, exactly? The war against Gopher for presentation of hypertext documents and information display? There's more to heaven and earth than data presentation and consumption.
The examples of genuinely great web applications are few and far between, if not near non-existent. Are Google Apps really the best the web has to offer?
Cappuccino provided one example of how to move the browser past the shackles of the traditional HTML/JS/CSS and into a world where developers could work with more accurate abstractions that actually represented the problem domains of application development.
This lesson has essentially been ignored, tossing out 3+ decades of experience our industry has in building applications.
There's more to heaven and earth than data presentation and consumption.
I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I order goods in a browser. I ship goods in a browser. I reserve items at the library in a browser. I watch movies in a browser. I listen to music in a browser. I push apps to my smartphone in a browser. I get directions in a browser. I find phone numbers in a browser. I phone people in a browser. I video conference in a browser...
I can go on and on all day. If you really want to argue that the web is a surrogate for Gopher, this conversation is futile.
> I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I order goods in a browser. I ship goods in a browser. I reserve items at the library in a browser. I watch movies in a browser. I listen to music in a browser. I push apps to my smartphone in a browser. I get directions in a browser. I find phone numbers in a browser. I phone people in a browser. I video conference in a browser...
I'd be interested to hear how those tools stack up against their native (or cappuccino) counter-parts, because implicit in your argument is that all these attempts to extend the web into the application space are better (and have 'won') over traditional approaches to application development, which I can't say has been my experience, even for the 'best-in-breed' solutions such as Google Apps.
Personally, I've found the surge of interest in native development via mobile to be invigorating, since it has meant a resurgence in applications that put user experience ahead of dogma (or even cost). I can hope that this continues to carry over to the desktop and other spheres over the next 5 years.
You can push apps to your phone with a native app? Maybe if you're using iOS. You can reserve items at a library with a native app? Which one? I don't know of any; do you? What do you use to manage photos, iPhoto? Is it really that much more powerful than flickr -- or even Facebook?
For many web-based tools, there aren't cappuccino/desktop analogs. They just don't make sense.
The success of the web makes horrifyingly apparent how important ubiquity and ease of deployment are. In they quest for users, they trump almost everything else.
It's awesome for things involving communication and relationships (banking, purchasing, and so forth) and for accessing content (Youtube is my main music discovery service, for example).
But I don't like doing everything in a browser. All the things you mention are transactional, but when I'm (say) writing music I much prefer to be in a native environment because the transactional stuff is a much lower priority. It's distracting, for many tasks. At the very least, I want to run some things without a browser frame of tabs, URL bar and so on without necessarily doing so in full screen mode.
> At the very least, I want to run some things without a browser frame of tabs, URL bar and so on without necessarily doing so in full screen mode.
Have you ever tried a Chrome Platform App? They don't have any browser chrome--they're just regular app windows, painted with whatever the developer likes--but they're still running in a browser. Sort of similar to Air/Silverlight.
>> I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I order goods in a browser. I ship goods in a browser. I reserve items at the library in a browser. I watch movies in a browser. I listen to music in a browser. I push apps to my smartphone in a browser. I get directions in a browser. I find phone numbers in a browser. I phone people in a browser. I video conference in a browser...
I do many of these things in a browser as well, not because the experience is so great, in fact, most of the time it's pretty horrible. Banking, photo management or video conferencing in the browser a great experience, really?
I sympathise with this article, and even though web applications have come a long way, I'm sometimes amazed by the collective cognitive dissonance that seems to be prevalent among people who develop web applications, pretending that all is fine and dandy in web application land, and we've long surpassed the point where web applications provide better experience than good native applications. They are simply nowhere near, and the fact that e.g. Google Mail (which is a great web application) is considered superior to e.g. something like Sparrow is quite frankly very amazing.
> the fact that e.g. Google Mail (which is a great web application) is considered superior to e.g. something like Sparrow is quite frankly very amazing
It's a good example actually. Even considering the less pretty UI, Google Mail is superior to Sparrow precisely because it is web-based. From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app. And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.
Why are 'spam and search' difficult-to-impossible in a native app?
For that matter, why are you equating 'the web' and 'server-side'? The standads IMAP protocol stores messages server-side while also enabling effecient server-side search. The standard managesieve protocol implements support for managing server-side filters from remote clients. Tools such as SpamAssassin perform intelligent per-user filtering server-side.
At that point, the only real differences between webmail and native clients are:
- UX
- Native clients use standardized protocols by default.
For one thing Spamassassin is quite hopeless compared to Gmail's filter (and yes I have compared). But more to the point I would absolutely equate web with server-side hosted app. For example, if you want to implement decent search it's probably going to be Lucene-based. So if you are just talking thin-client presentation layer, the app isn't really native in any case - the acid test for a non-web app is whether it works without an internet connection. (Other major differences would be ubiquity and maintenance.)
>> From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app.
You can configure Sparrow (or whatever native e-mail client) to simply connect to your GMail inbox and have all the spam filtering and search capabilities that GMail has. Even the default Mail.app on OS X and iOS (which isn't exactly feature rich otherwise) does this. As much as I like GMail as a service, their web front-end is actually the part I dislike most about it, which is why I almost never use it.
>> And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.
Well, first of all I don't like ads and I don't care about how service providers can monetize it because it's web-based. I'd much rather pay a monthly fee for the service and/or a one-time price for the app, than having a web UI full of crap I didn't ask for. Not a very strong positive for web-apps. As far as updates are concerned, I understand that a web-based service is much more flexible in that regard, but then again, it's not really hard to have self-updating native applications either.
I do my interactions with my bank in a browser, but my bank doesn't do the actual banking in a browser.
I could manage my photos in a browser, but I won't do "photoshopping" in a browser.
I watch movies in a browser, but I don't edit my home movies in a browser.
I listen to music in a browser, but I don't record or mix music in a browser.
I push apps to my smartphone in a browser, but I don't develop smartphone apps in a browser.
In general, I communicate or consume in a browser, but the worthy things - the creation - tends to happen outside of it.
Also, don't forget that all the things that consumers might ever see are just the tip of the iceberg - the vast majority of software and hardware development is done not for B2C apps/websites but for solutions that are B2B, business-process-internal or hidden in an appliance, never seen by any consumers.
I think you will end up doing every one of those things in a browser.
That browser will probably look less like a browser - since it does everything, it doesn't really need a window.
*Except for your bank doing your banking. Of course it will be offloading the work to a dedicated application. The rest, however, will be browser-based.
Actually I do most of that stuff in native mobile application now instead of in a browser.
Do you know why? Because the browser version sucks ass compared to the native version someone has designed for a phone UI. It makes me sick every time I pick up my phone to transfer money in my bank account while I sitting at a computer.
It's like there's a culture of cultivated ignorance around web apps.
The pop culture of web development strikes me as a spastic, young programmer who flits from framework to framework, always in search of some magic elixir to make application development more pleasant. They know it isn't quite right, but they don't want to give up the hard-earned, arcane JS knowledge they've used. Nor are they willing to sit down and admit that, maybe they need to sit down and learn a thing or two about how to structure programs better (as we all do)!
Instead, it's emotional blog posts and bikeshedding over inane topics (vim, Coffeescript), rather than looking at the deeper issue - the utter mediocrity of the tools they're using.
I've been doing software development very successfully for closing on two decades. I've developed in 680x0 assembly, x86 assembly, C, C++, MFC, ATL, Java, .NET and on and on in the fat-client space. I've watched with interest and anticipation as various parties have brought out the Next Big Thing.
I am also a strong advocate of web apps and have been for a long time. Reality has proven out my position as, as has mentioned, the web won the presentation tier (clearly this has nothing at all to do with data processing or database or system programming or anything of the sort).
In any discussion on web apps they are always held against an illusory foe that is all capable and all perfect. Let's get specific however -- I love Rdio and love their web app. They came out with a new .NET client so I of course gave it a whirl.
Worse, slower interface. Constantly updating (in big monolithic chunks). Consuming hundreds of MBs of memory.
I'm not trying to criticize specifically Rdio, but I guarantee that initiative started with someone slamming the web and its crazy mishmash of standards, promising that they'd do something that would exploit the full power of the client. The result was something much worse, holding the single and only advantage of "not in a web browser" (for what that's worth?). Amazon has fielded various trials with various rich apps (they usually partner with Microsoft), but you've never seen them because they never have a compelling story, coming with enough detriments that it outweighs the benefits. My local library system used to have a whole nasty Java interfacing tool that was an absolutely abomination, with a horrendous rickety interface that seldom worked properly, was slow, and was a beast. They replaced it with a dramatically better web interface.
Those are all just anecdotes, but they're constant across the space. Yet every post pretends that the web is a weakling that has no merit and no advantages, completely missing why it has made all of these wins against endless competitors.
Sorry, you're going to need to elaborate here or else you're really sensationalist. Also, you can't be serious about the community not admitting we need to learn how to structure programs better, as if that were the only problem. I didn't learn that UNTIL I started working on the web.
horrible but open , and i think that matters. After the flash and silverlight fiasco , though these tools are far more powerfull , you just cant trust a private business to provide you these tools on the long run. My alternative to that mess is Haxe, and it's going to be big.
> The examples of genuinely great web applications are few and far between, if not near non-existent. Are Google Apps really the best the web has to offer?
Every good web application beats its desktop rivals simply by being ubiquitious. People who dismiss the web typically ignore this simple fact completely. But it's always been true, you can look back to 1997 when Yahoo Mail killed the desktop email client business not by being flashier or better (it had full-page refreshes over 56k modems, awful!) but because you didn't have to ever worry about not having access to your email again.
Note that both of these articles kvetch about user experience and how the web simply can't compare to native apps, but emphasize that the ease of deployment matters more.
Also, note that the app store model obviates some of the deployment difficulties of native apps and makes it almost as easy to install native apps on the phone as it is to visit a web page.
(Apologies for the big rant, these are some ideas that have been rattling about in my head recently and your post made some things clearer in my mind. It's not meant to be a post of factual 'truths', but an explanation for my (and perhaps others) reaction against the web as the one platform to rule them all. So it's as much an emotional gut reaction as a logical one. )
I think this (desire for ubiquity/multi-platform) is the main reason I don't see eye-to-eye with the people who are pushing for web apps for everything. Web apps everywhere is great for large corporations that want to provide their service on as many platforms as possible. It's great for venture capital funded startups where the name of the game is to get as many users as possible and get bought out before your money runs out.
I'm a small indie dev though, I produce software (not software as a front end to a non-software business), and I'm not looking to become a billionaire (really!). I want to develop software because I enjoy it: to solve problems for real people, to solve my own problems. So really I don't care too much about being able to target every platform at once. I want to target the platforms I like, using the tools that I like, and as long as the platform has enough users to make it viable then I can do that with native software on open platforms (the latter is important and why I don't write iOS software, for example). There is the risk that the platform I target gets killed, but if a lot of people use it then that's generally going to be a slow process, and there is plenty of churn in web tech and standards anyway so it's not like it provides immunity to technological change. Additionally, I just have a hard time working with web technologies. I find them much harder to use, to the extent that if using html/css was the only way to write software I wouldn't be writing software at all and I'd go stack shelves in the supermarket instead. Maybe I'm just not smart enough to use them effectively, I don't know.
I guess this is partly the old 'software as craft'/'lifestyle business' argument, but it saddens me slightly that the big industry players are moving us away from the kind of industry where you can write software that interacts with some arbitrary bit of hardware in unsupported or unintended ways towards a much more controlled and profit orientated one (i.e. your software running everywhere being the most important criterion of all). Web people are not the only offenders here of course, but arguments against things like iOS have been well explored over the years.
Some people seem to view the web as some kind of beacon of freedom, the little guy fighting the big bad industry giants of Microsoft, Apple, Adobe and so on. But from where I am, the web is the big bad industry giants. Writing web software means being restricted to a very limited sandbox. The APIs available to me are decided by what a small cabal of powerful companies (Apple, Microsoft, Google, Mozilla, Nokia and maybe a few others) can agree on. None of their interests align with mine (why would they?).
If Gopher had taken off and supplanted native development to the extent that people were using platforms that could only run Gopher apps, would the current web even exist? All user facing software being written to a single standard and API has good things about it, but it also limits new ideas tremendously ("sure you can add X feature you just need to get it through this committee of industry heavyweights first and get them all to agree, and then wait for them to ship it").
What is important to me is that data uses open standards, whether at rest or in motion. If people control their data, and it is in open formats, then there is little companies can do to lock them in. Which is good for me as a dev since I can write software to help users work with that data. Web technologies don't do much to help me there, in-fact for the most part they have made it easier for companies to keep users data locked away on their server in unknown formats or behind proprietary API...
Interesting perspective and good food for thought.
My one point would be perhaps the way things are now is because it's good enough. Using the web and building for it is good enough for a lot of people, the speed bumps and systems in place are good enough for the majority.
But I do agree, we've gotten to a point where a handful of corporations dictate how everyone else get to do the neutron dance and that the bleeding edge needs to be examined and worked on so that change can occur.
This is interesting enough you should write it up as a blog post and submit it. You're not going to get the discussion you deserve posting something this interesting deep in a thread on a tangentially related article.
Most desktop applications that where written for the desktop back in the 90's and early 00's where boring internal business stuff, not well known shrink-wrapped stuff such as MS Office.
Today, almost all that development has moved to the web.
>And they all fell by the wayside. They lacked in features. They lacked in agility.
No, no and no. The web "won" because its simple and the lowest common denominator was good enough for most people. The web has always been far behind in terms of features and agility (depending on what you're trying to optimize when it comes to agility). The web won solely because it was "open" and every company had a stake in ensuring no one company could sustain their monopoly. The web sucks and it did not win on its merits.
But it has won nevertheless. The question then is what we are to do to move the web into the realm of applications. I don't have an answer, but one advantage mobile apps hold is UI standardization.
There is no one right way to build an app for the web the way there is for Android or iOS. That's a problem for both the applications authors and users. Cappuccino attempted to solve that problem in a way that did not appeal to programmers, it seems. jQuery UI succeeded to a point, and now Bootstrap seems to be the framework of choice. Perhaps a widget-based UI framework that can target the desktop and mobile devices would make sense.
Which is one of the strongest selling points of Emacs and Vim. Ubiquitous doesn't equate to web based; there are plenty of native apps that are ubiquitous, and on top of that they don't require a constant network connection, or that the server is up. It also seems to me that if you have the source, you can get the software running just about anywhere.
It just happened to be that all browsers adopted HTML/CSS/JS and now we use that as an application platform (despite it being designed for sharing documents). It won because there is no other choice but it kind of still sucks which is why there is so much complaining about it.
>The web won. It fought a battle against many foes, and it came out on top.
What utter BS. You are essentially celebrating the victory of consumer commerce, not technology X over technology Y.
Think about it.
There never was any battle between the "Web" and "MFC, Java Applets, Webstart, .NET, Flash, Silverlight". Those thing survive & even thrive in places where nothing else would do. Do you really think everybody in investment banks & brokerages fire up their browser first thing in the morning ? 99% of what they did, do & will continue to do, will continue to be done via native apps - mostly C#, C++, .NET & Java apps. This is just plain reality. It isn't because they are lazy or don't grok the web. Processing realtime trading feeds isn't the browser's strength. Sure I'll show you an iframe with some ticker, equities blotter, trading tickets ...but that's just consumer commerce. I'm soliciting your cash - Here consumer, click on this Buy button, give me your money. After that ? Once you fire off your client request, that's when 99% of the task actually begins, and it ain't on the browser, no siree.
The web is just the tip of the iceberg. Most of the action is below the surface of the water, and that's not the web & will never be.
To your point - the whole idea behind Webstart, Java applets, Winforms, was to mimic the native UI on the web & try to offload as much client-side logic to the client's machine.
Turned out customers didn't like "fat clients" - they wanted textfields & simple input forms, accept their inputs & go away & process the inputs elsewhere.
We said - Hey, you guys have a fast processor & slow network, let's do this one-time applet download/Webstart download/Silverlight app download, & once done, we won't tax your network, we'll just tax your machine. I wrote one of the first equities trading applet for Goldman Sachs. It was a fat client ~100 MB, you actually waited 10 minutes for the install. But it did so much - all the trading rules validation, portfolio construction & computation, everything happened inside that applet. Once the applet downloaded, it felt & behaved like a native desktop app. It was so much more powerful. There was actual science in that applet. It took a doen CS PhDs to build the infrastructure for shipping that. We fucking got dozens of patents...pseudo-realtime trading applet over the web ha ha ha! Today, the interface is so dumb - zero download time - but they hit the network so much harder. Absolutely nothing happens on the client. To check whether a simple trade is valid, you have to hit the server multiple times during the workflow. Customers are ok with it because the network has gotten so much faster. They were downloading ~100MB applets on 56.6k modems, now they have superfast broadband, so it makes sense to hit the server more & do less on the client box. So you just hire an 18 year old & he'll build a polished web UI for the trading applet over a weekend. That doesn't mean all those CS PhDs just up & died. They just migrated to the server side, where all the action now happens.
So this isn't success of the web & failure of the applet - its success of broadband. Network penetration today is massive & ubiquitous. You can place million dollar trades over android. You couldn't do this just 10 years back. At that time, applets were state of the art. In hindsight, the whole exercise appears pointless. 100MB applets WTF, just use underscore dot js & ajax & broadband & a little bit of markup & your trading window shows up on a tiny 4 inch android cellphone. Yeah, true, but we didn't have any of that back then. Cut us a little slack, will ya.
"You are essentially celebrating the victory of consumer commerce, not technology X over technology Y."
It isn't celebrating to point out a reality of the world relative to a post that seems to imagine that every other solution was handicapped in the race. And it IS completely based upon technical merit.
"Do you really think everybody in investment banks & brokerages fire up their browser first thing in the morning ? 99% of what they did, do & will continue to do, will continue to be done via native apps - mostly C#, C++, .NET & Java apps."
Humorously I build software for the financial market. Our presentation tiers are almost entirely through web apps. The competitors I was talking about -- the ones who poured cement on their own feet -- went the "thick client" route. And we keep on iterating.
"The web is just the tip of the iceberg."
Yes. No kidding. I'm not building a database in the DOM. I'm not processing trades in JavaScript. This discussion is about the presentation tier. Every criticism of the web always holds that you could toss together something so much better in some illusory, never proven alternative, but that simply isn't true.
Yup, I build software for the financial market too. Years ago we were struggling to persuade companies that they should use html instead of sliverlight or flash. Last year, they pretty much all realised at once that they'd built millions of dollars worth of key software in dead technologies (and often struggled too). They're all back now, wanting products and help with their HTML/JS.
I broadly agree, but I think perhaps your thesis is a bit premature given the latest push for mobile apps, and (perhaps more dangerous to the web), walled gardens like Facebook.
But I think the open web will win in the end, not because of any inherent technical advantage (in some ways it's behind native apps still in terms of performance, look and feel etc), but because the open web has so many advantages for developers and users that in the end it will overcome its disadvantages. Performance and UIS are improving constantly on the web (contrary to the opinion of this poster), so the gap is narrowing. At some point the performance won't matter, offline web work will become possible, the network will be fast and ubiquitous enough and the advantages of the open web will come to the fore.
As a developer of web apps and mobile apps, the contrast between deploying a few fixes a day to a website, and working hard on new app versions only to have them rejected by an anonymous gatekeeper at Apple, often for inscrutable and unjustified reasons, then waiting days or weeks for approval, could not be more marked. Things are easier on the desktop, but there are still far more hurdles to deployment, and that matters a lot, as you hint above. The only thing I really miss on the web is a great language to script web pages in, but that will come (js is not my favourite language), and you can use any language you want on the backend, and no-one need know.
As a user, the advantages of the open web (i.e. not walled gardens like Facebook) will I think have an irresistible pull - advantages like linkable, shareable content, content on any device, even unforeseen ones, not having to rebuy apps but just subscribing once and accessing content from anywhere. The fact that the web is not controlled by a single vendor as most commercial operating systems or devices are is an added bonus.
Finally, I'd argue that the radical simplicity of web technology is actually its greatest strength, as it means it can be deployed almost anywhere, even with limited resources, and give at least some value to users for decades and over any new devices which come out, as opposed to the binaries being created for current platforms which in a decade will be forgotten or dumped by their vendor in favour of the newest flavour of opendoc, .Net, whatever... I find it fascinating that the web delivers consistently better results by virtue of keeping the tech simple and backwards compatible.
I agree that web developers in general and web development in general follows this trend. But his evidence for it is unconvincing to non-existent. Caring about file size is not a symptom of "tossing out everything we've learned from the last 30 years".
I disagree. Web programming can be fundamentally different from application programming.
Application programming tends to be far more complex, far more planned, and far slower. Applications last for years and years, and new releases might take multiple years.
Whereas web programming can be extremely experimental, prototype-y, with multiple releases a day. It's also vastly faster to program.
This isn't an argument against good architecture -- far from it. But it does mean that the kind of long-term planning and investment that makes good traditional applications, isn't always applicable to website programming.
Due to the nature of the market, "complete disregard for maintainability or extendability" is sometimes a good thing, because you can iterate faster. Think of a lot of web programming as prototype programming -- then, you go back and re-architect, re-engineer, etc., as desired.
"Application programming tends to be far more complex, far more planned, and far slower. Applications last for years and years, and new releases might take multiple years."
Really?
You can build non-web apps just as fast as web apps. There are decades of tools and programmer experience doing this daily. You can't build Autocad or Photoshop as quick as you can churn out a buggy Rails site, but that's comparing apples to oranges.
> You can build non-web apps just as fast as web apps.
I expect the underlying point was that most popular native platforms today almost force you into best practices which does add some upfront cost.
On the web you can throw up a single page PHP script full of SQL injection vulnerabilities and Javascript spaghetti and you are off the races. There is generally no equivalent for a modern GUI system. You typically need to start with a full MVC infrastructure in order to even begin to interface with the system libraries.
When you take care to craft your website using the same best practices the differences become negligible, but a large number of developers do not care about architecture and can take shortcuts that make it feel like they are moving faster.
"comparing apples to oranges" that is kind of the whole point here.
Most of the arguments in this thread are coming from two totally different perspectives. Some holding doggedly to various ideals and dogmas and instead of trying to learn the new domain, they try and make the apples look like oranges. This never works. Most are right about this or that when it comes to the domain that they are experienced in, but when economics forces people into a new problem space some don't try and learn the new space as a thing in and of itself, instead they try and adapt their methodologies and abstract to a different problem space they are more familiar with. That is where these conflicts come from.
"Cool URLs don't change." Quickly fixing my server is great and all, but the fact that I can push a button and instantly break millions of hyperlinks is a fundamental problem with the architecture of the web.
It's not that there was a complete reboot of IT. It's that web solutions are just now being applied to problems we already solved years ago in other industries (telco, defense).
The web wasn't originally intended to be used to provide native like experiences and so the foundations for that just weren't there. So yes, people had to re-invent and re-discover all those desktop frameworks but this time in a javascript & html environment.
I think the obsession over desktop like frameworks in Javascript is due to the fact that there just isn't a clear winner yet and that is because the foundations required to support a clear winner just don't exist yet.
-We need the ability to scope CSS to a given section of the document. I want to be able to import someone's widget (or set of widgets) and not worry about style collisions.
-We need a better solution for storing templates (pre-compiling them into .js files or storing them in <script type="text/template"> just seems awkward)
-We need a better way to bundle CSS with its resources. I.e., if I have a css file in "components/bootstrap/styles" that refers to "../img/pic.png" it is going to break when I concatenate all my CSS files into one and drop them in "/"
-We need a better module system. Yes, requirejs is good but I'd like to say I depend on "package.name.x" and not care where it comes from or who provides it. It should just get loaded for me (this has been solved for years in the Java world via OSGi).
-We need a better build system. Yes, grunt is good but I have to put in all sorts of logic to handle the above problems.
-I should be able to place custom tags in HTML and have the browser create my user-defined component for me. I.e., <usr:combo> should find the correct template and backing javascript and construct the component.
There won't be a winner and the re-invention will continue until these foundations are put in place.
Good news! Many of these very problems are being worked on right now. The component issue you raised is being fixed with web components: http://www.html5rocks.com/en/tutorials/webcomponents/shadowd... which should be making its way into stable browsers in a matter of months. The module system is being fixed by ES6 modules which should be appearing in Firefox and Chrome within the year. I haven't heard anything about namespaced CSS and I agree that's something that we need.
Even as someone relatively new to development and a native of the web this seems so clear to me. The web was originally just a way of sharing documents. It is both a miracle and heresy that we have managed to do so much with it. We could very well do with some foundational rethinking of what the web is beyond all the web 2.0 buzzwords.
That said, I have never understood the driving need for desktop like frameworks. The problems that ubiquitusly networked applications and communications technology face are nothing like those of kernel code, commandline applications, or modern applications like CAD Photoshop. All the things you mention that need fixing desperately need it, but I don't think a desktop like framework/library/standard for the web will ever 'win' because the web is not trying to solve the problem of a virtual desktop, it is trying to solve the problem of a non-homogeneous ubiquitously networked data exchange layer.
Amen brother. A lot of the problems stem from the cargo culting of various technologies and patterns (I'm looking at you, inflexible templating languages).
Also a lot of these issues come from looking at each piece in the development cycle separately rather than holistically. Frameworks like meteor are starting to address this, but we still have a lot of work to do.
>Ember is very close to the “micro” side of things, but at a “whopping” 49KB (less than a second download on a dial-up internet connection
Chances are that you probably never had a dial-up connection. 49KB on dial-up generally takes around 10 seconds.
Besides this point, the accusatory tone towards front-end developers and 'the rest of the world' that did not understand you isn't helping to get your point across. You were in the wrong place in wrong time. It happens. Move on. There are better things to do, and bitterness only hurts yourself.
perhaps that's the size of the script uncompressed, and gzip crunches it down to < 10KB? dunno for sure. could be the factor of 8 thing that another commenter suggested.
>Ember is very close to the “micro” side of things, but at a “whopping” 49KB (less than a second download on a dial-up internet connection)it’s still far too big for many.
Erm, isn't dial up at 56kilobits per second? It will take much longer than a second to download 49KB.
The web is the only future of software development. It's open, free, innovative, and unpredictable. It didn't pick your Cappuccino, sorry for you, but that's OK for the rest of us.
Something will come along and replace it when we finally pile too much on something that wasn't designed to do UI in the first place. The questions are "what" and "when" not "if".
There's no way yet another webapp framework, no matter how close it emulates the desktop, is going to gain lots of traction when it mandates users to use... Objective-J and JavaScript.
Seriously: being on your high horses and all is fine and well but your article is an oversimplification as to how the web works and as to what devs need and want.
For example lately I've been very interested in flapjax (FRP UI) and webfui (Clojure / ClojureScript with automated synchronization between the client and the server).
Functional programming and FRP UI may be the way forward. I'm not saying it is but I'm saying it may. What does Cappunico have to offer from the standpoint of determinism and reproducibility? Seen from a sufficiently distant paradigm, any web framework is the old, broken, inneficient way of doing things. Even your beloved Cappunico which you wasted so many time on.
Cappunico is a failure. It doesn't have to do with you being too intelligent and having figured out things earlier than others. It's just that there are many who devs do not want Objective-C / JavaScript and who want instead something really disruptive. As long as the one really disruptive thing doesn't come along, there shall be competition between lesser solutions (which Cappucino being one) Deal with it.
Randy's probably right about how silly all the tiny reinventions of UI frameworks are. And, though I'm generally unsympathetic to claims that a project is a failure because people don't want to learn the tools, I think it's safe to say here that asking people to use a language that's only marginally less horrible than JavaScript is not going to be a win from any perspective.
But he fails to realize that doing UI in a Cocoa-like framework is totally fucked (to be clear, I do Cocoa touch for a living; I'm speaking from experience).
I'd be making an understatement if I said I was unexcited about Cappuccino because it fails to even approach solving any of the truly important problems of UI work, which are (as you hinted) less about "can I make the table scroll quickly" and more about "can I decouple this monstrous mess of data, dependent requests, and presentation". As you note, FRP looks like a step in the right direction toward solving that problem. Traditional Cocoa-like approaches are a step backwards in that area, not forwards.
I think he was simply pointing out the fact that we've stagnated at the same level of abstraction in the web space for a long time. Cappuccino is just the example he's using to point out where we were relative to where we are and in that light it's almost a regression.
For the purposes of his larger argument, the way that Cappuccino delivered its abstractions (Objective-J) isn't as important as what it allowed you to do with the web.
Second this; while I'm not a web dev, I do bump into it occasionally, and it pains me any time I see someone re-re-re-inventing the wheel, often badly. I don't know about Obj-J or Cappuccino, but just the OP's comments about modules had me nodding in agreement.
Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite? If you want a full featured enterprise SQL DB, why not just use PostgreSQL? And don't even get me started about Walyand/Mir as opposed to Xorg, or the whole debacle of disabling separate /usr because of rewriting things like init to use glib and other non-base system dependencies. The hubris, lack of knowledge of history, lack of foresight, and just plain lack of professionalism (to put it politely) are staggering.
> Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite?
SQLite is native C, H2 is Java. There are significant deployment and potential stability advantages to not using native binaries in your Java software.
There have been some neat hacks to get sqlite running under Java, including using a tool that translates MIPS binaries to run under the JVM, allowing the use of libsqlite as 'native Java' code: http://nestedvm.ibex.org/
This is, however, not something you'd likely want to use unless you absolutely need to interoperate with sqlite's data format.
I noticed that the fully native Java was a big selling point on H2. Admittedly, I'm not doing much Java these days (slight understatement), but I was under the impression that the Java interfaces to SQLite were fairly mature? Top two links in Google go to a very informative SO answer with lots of options and SQLJet. Bad sign though that "apt-cache search sqlite | grep -i java" gives no results on Debian stable. I'll grant that fully native Java is a compelling reason in some use cases ;) I'm now curious what they use for SQLite on Android, as I know fairly well that it's used all over the place there.
H2, more than anything else, is great for testing. It can emulate oracle and DB2 syntax, among others, to allow us to reasonably approximate a running system on our own machines, then test against the big database (which is much slower) at a later stage.
Fully native java and an in-memory implementation mean that we can very quickly implement it in our systems.
This is my feeling, too. I do iOS development for living and whenever I have to do some web programming, I feel like writing in assembly, having to micro-manage things I should not care about.
It pains me that Cappuccino has received so little interest, for despite all its possible drawbacks it represents a very interesting path for future web programming.
> whenever I have to do some web programming, I feel like writing in assembly, having to micro-manage things I should not care about.
That applies in the opposite direction too. Native programming seems to involve jumping through insane hoops just to do simple things:
Like "put some text on the screen, this part is bold".
Or "open this web page".
Or "put these things next to each other, with 10px in between, unless the screen is a little narrower, then put the second one below with no margins".
Or "I want to play with the layout of this every day for the next month, have the new layout download every time someone uses this app".
I can write complete, ready-to-distribute web apps that do those things in 1-3 lines of code. Doing so in iOS takes many layers of indirection.
Look at something like Ember.js. The abstractions being put in place are fascinating. Or CSS. It's is an incredibly powerful abstraction on something that iOS just scratches the surface of.
The truth is, both the web and iOS have evolved to deal with specific pain points. Some things that are easy on one are hard on the other.
This idea that web programming is under-abstracted seems really narrow-minded to me.
Have we stagnated? Or has the rise of lower powered web-enabled devices forced us to re-think the classic rule of programming (ie that applications can progressively increase their system requirements as PCs are progressively becoming more powerful to handle the load).
Let's remember that even as recently as 2-3 years ago, top end phones and tablets were single core ARM processors clocked at ~1GHz. And devices of that spec are still in wide spread use even now.
The point of the HTML is that it's an open standard which should work on any internet device regardless of platform, patents and what not. While I admire the ambition of the guys who push the envelope of what the web can do, they often forget that everyday sites also need to cater for low end devices used by everyday folk.
This trend is likely to continue as the billion or so potential customers in emerging markets start getting their hands on affordable smartphones.
The idea right now for telecoms and device manufacturers is more about getting their stuff in as many people's hands as possible, not about whether they can replace a screaming desktop with a handheld.
We have stagnated because new APIs, frameworks, environments appear at a rate too high for anyone to build meaningful things on top of them before they become obsolete again. We also wait longer until we adopt these new technologies, therefore narrowing the time frame to actually use them even more.
Low end devices are a good point, my main gripe with all these frameworks is that they make it very easy to break many conventions of the web (URLs no longer work as intended, extra efforts is needed to make the pages crawlable etc.).
We're stuck at the same level of abstraction because the platform forces us to. The base html/css controls are incredibly simplistic, to the point of being pretty much useless for building proper UI. Everyone is struggling with how to abstract their way around this fact.
You have solutions like gwt, cappucino and extjs which build custom ui components that behave properly, ad the infrastructure to tie them together. This works, but only if you never step outside the framework, and only if you're willing to deal with bloat, which sucks. Then you have frameworks which just give you the infrastructure, not the custom ui components, like ember or backbone. That also works, but because html's core controls are horrible the only way to get a great ui out of that is to build really custom ui, essentially rebuilding what the complicated frameworks already provide out of the box, which sucks. And then you have one-shot solutions that try to bring just one or a few ui elements to the web, trying their best to fit into the raw platform. That also works, but because the raw platform is so painful to use, it doesn't scale.
Really, the problem is that html/css/js is the wrong base for building abstractions on. I have great hopes for shadow dom and web components, but that's only the beginning of what we need. The platform itself needs to evolve a great deal to make building high-quality ui something that doesn't lock you into a vendor's toolset.
Personally i chose extjs and am waiting it out until the platform matures underneath it. I'd like to see the extjs codebase evaporate as parts of it get replaced by native code, until it's nothing but syntactical sugar on top of a rich base platform. That's going to be a while though.
He can blame the technicians for being lazy or stupid, and he does it, but the fact remains, they didn't wanted to use his tech.
Some front-end devs are technicians that need to generate value quickly, and most can't afford investing time in a new complex system that may disappear tomorrow. If there are no clear advantages on the business side that justifies the investment, then there is no pressure to the front-end devs to do it.
Good engineering also means optimizing technical designs for the usage of the technology in order to reduce costs. That includes factoring in the skills of the technicians that are going to use the tech (and the cost of training them).
There's no way yet another webapp framework, no matter how close it emulates the desktop, is going to gain lots of traction
My objection is right here. No need to mix in the Objective-J at all.
Microsoft's ASP.NET tried to do this thing, to a surprising amount of success. The context then ofcourse was "Web 1.0" pre-Digg internet and the only other "big thing" being PHP.
Microsoft managed to take the whole "Draw a GUI in Visual Studio and it's a done app" thing and take it to the web, much like it originally defined Windows-programming with Visual Basic. It was an immense success and very cool.
Then Web 2.0 (as much as I hate that term) came and changed the game.
Then not working on the raw metal became an obstacle to making ASP.NET do all those cool things which everyone else was doing. It's killer feature (not having to know HTML) became it's Achilles Heel. It's abstractions became a hinderance to all the things you actually knew how to do once the framework got out of your way.
I may be a tad pessimistic and cynical, but I doubt a framework whose main goal is to give you a non-webby workspace will be a long term success when you're actually working on the web.
Microsoft learned that (too late?) and have tried to remedy the situation with ASP.NET MVC, but by the time that became useful, it seems lots of .NET developers went off to find cool stuff elsewhere.
A new framework like that, right now, seems like an utterly dead end.
JavaScript is compiled by every modern browser, in fact it has some of the most advanced compilers that are out there. And the dichotomy of "scripting" vs compiled languages is false. You may be thinking of dynamic and static typing.
A language interpreted at runtime, by an application that runs inside an operating system (which may or may not be virtualized) that boots into protected mode. Let me get this straight, you're ostensibly describing this as being "bare metal"?
Have you ever heard the terms "kernel mode" or "ring zero"?
Oh wait, you qualified it as "the 'metal' of the web"... so it's an "analogy". Sorry to be pedantic, but when people say "bare metal" in the context of platform virtualiztion, "bare metal" literally means just that. The executable code is compiled into binary that directly correlates to the copper wires (and etched semi-conductors, or perhaps even vacuum tubes) of the specific, real, tangible machine intended to execute the code. JavaScript is nothing like this.
Maybe the packets and datagrams of transmission protocols are the "bare metal of the web", but JavaScript most certainly is not.
You're really reading too much into his analogy; it was a quick informal way to get a point across and everyone (should have?) understood what he meant.
> The executable code is compiled into binary that directly correlates to the copper wires (and etched semi-conductors, or perhaps even vacuum tubes) of the specific, real, tangible machine intended to execute the code.
You do realize it's been a while time since the ostensible instruction set and corresponding assembly language of most modern CPUs translated directly to the bare metal execution model of the machine. http://en.wikipedia.org/wiki/X86#Current_implementations Even on RISCier architectures, virtual memory, deep instruction pipelining, super-scaler dispatch, branch prediction, multi-layer caching, inter-core cache coherency, etc. introduce a huge amount of abstraction between the instruction you write and the actual execution on "bare metal".
On current chips, x86 machine code is as much a virtual machine as java byte-code. It's abstractions all the way down, you just pick different levels for different classes of work and "bare metal" is now just a label for one below where you landed.
>On current chips, x86 machine code is as much a virtual machine as java byte-code.
I understand what you're trying to say, but this is way off base. x86 instructions may not align exactly a processor's primitive operations, but that doesn't mean abstraction makes x86 similar to the JVM, at least not anymore than it is similar to a Bible printed on papyrus. But nobody cares if ancient Hebrew is just as much a virtual machine as Java, so stfu.
But! IN THEORY You could still construct a processor out of electromagnetic relays (springs, contacts, leads and solenoids only), if perhaps your goal was to never exceed 100 Hz.
(...at first I was going to point out http://www.bigmessowires.com but it turns out that beyond the wire wrap connections, he's still using modern semi-conductor packages)
The metaphor is apt. JS is a terrible terrible language (with some nice features). It's very easy to do the wrong thing. It's very hard to organize large projects and it needs higher level frameworks to be usable and portable. And with projects like asm.js it will be a necessity (not an option) to write in a higher-level language in order to generate performant JS web apps. So the "raw metal" metaphor is apt.
As far as I know, Microsoft's ASP.NET was kind of a failure. It produced Frontpage-grade (e.g. dirty) html. It did the wrong thing by default and didn't help much with the right thing.
It also brought in some clueless people who had no idea how HTTP, HTML and JS work, with questions like "why my button.hover event does not work" (this was pre-ajax, the event code was on the server and had no ways of knowing the user is hovering over the button).
Maybe it was OK for CRUD and internal applications but not for ordinary websites or sophisticated web apps.
.Net MVC is seen as a success: clean HTML, predictable things under the hood, jquery.
Eventually, yes. Which I addressed. But prior to the whole Web 2.0-thing, it was actually pretty successful by lots of means.
I'm not saying ASP.NET MVC is superior in most respects. There's no doubt about that, but it was clearly a late-started initiative which should have started much earlier. ASP.NET already had lost its respect and was a waning star by the time they got the first version out the door.
These days it's actually fairly pleasant to work with. The only thing I can say I really dislike about it is that you can still find the traces of all the old ASP.NET warts there, if you go beneath the hood.
Edit: Thanks for being the only one replying to the actual topic at hand, as opposed to doing inane discussions about what "real metal" is these days. And that's coming from someone with a degree in electrical engineering and design of digital electrical circuitry.
I think ASP.NETs popularity wasn't because developers thought it was cool, it was because Microsoft was very effective at selling it to management. What better sales pitch than to suggest you could whip up a "rich" business application with a series of drag and drops and a few tweaks to the code, in no time at all!
You've nailed it. From another aspect frameworks and abstracting libraries are designed for reusable assets, paradigms, and resources. This is great if you want to create cookie-cutter websites, like corporate CMSs.
This style of thinking damages applications. Yeah you've made it easy to build a form with validation, but users don't need half the form fields, let alone the form itself. Also if you thought about it, you could have came up with a more innovative way to capture user data that would lead to more registrations, and thus more users.
He didn't even mention the Dojo Toolkit. Dojo has all of the challenges Cappucino faces, except that its all Javascript, as opposed to Objective J. Dojo has the awesome table grid, the widgets, all of that. I don't use it anymore, but it was pretty powerful on the project I uesed it on.
although it seems to be "yet another web framework", be careful when you try to reject it only because of that.
Web frameworks happen because people try to leverage their existing knowledge, skills or codebase in a web domain.
i.e. GWT & Vaadin are web frameworks where you use java and there is literally no need to know JS/HTML/CSS to create some really nice web apps that perform well.
I don't want to say that you don't need JS/HTML/CSS knowlede to build web app. But those frameworks allow people to be productive with almost no such skills.
If you actually bothered to read his post, he was actually using ember.js as his example, which is decidedly not written in Objective-J. It's plain javascript with handlebars templates.
A couple of years ago a London based start-up came to me asking for help finding a Cappuccino/Objective J developer. I pride myself at being able to find needles in haystacks but finding a dedicated Cappuccino dev in London was proving impossible. During a moment of desperation I fired a very simple email to Randy asking for suggestions and I got a reply within 24 hours with a few names suggested from the Cappuccino community who were UK based and a couple of suggestions on what sort of developer would find the transition to Objective J easier than others.
Randy's passion for Cappuccino was blatant and his excitement at seeing the framework expand in the UK was admirable. The fact that someone so passionate has become so frustrated is a shame.
Best of luck at Google Randy and thanks for taking time out to help a stranger.
Your day job is to build a piece of web software and you can’t take a few days to learn the ins and outs?
This is the opinion I had when all of the previous Ember flare ups happened. My thoughts were exactly this. It would behoove so many of us to simply spend more time with new technology and ideas before we simply throw our hands up and say "it confuses me".
You have a new-fangled thing for everyone to use. Scratch that, everyone who's been in your shoes, with your particular pains. Great, you solved a problem. Take some time to explain on your blog or in your GitHub README.md the context of your solution. "Because I can!" is a fine reason, but I don't spend time exploring something that was built because it was possible to build it.
So your new-fangled thing looks like it's a solution to a problem I'm having. I start to implement it and ... oh dear $DEITY, it's a mess. I don't mean it's ugly, I mean it's completely inextensible. It's a specific solution where a generic one would suffice. Or worse, you didn't think outside your little box to discover that this "fix" will debilitate 95% of the web servers on the planet if they were to try this solution.
My advice: if you build it, A) explain why, B) learn to build it well.
Fair. I'm only suggesting that before we collectively steam roll an open source project and its volunteers with "I don't get it, so it sucks" mobs, that maybe we spend a weekend with it. Maybe over that weekend we learn "oh dear $DEITY". And maybe, just maybe we contribute back to it in an effort to "help".
> This reaction to Ember just baffles me. Your day job is to build a piece of web software and you can’t take a few days to learn the ins and outs?
Couldn't agree more. While I do think that new technology should be intuitive and easy to use, you have to take the time to explore, learn and familiarize yourself with it. I think peoples' attention spans are way too short these days.
Time is money, and the larger your team is the more that the costs of learning a new tech are amplified.
Using his off-the-cuff, totally subjective "a few days" estimate, and assigning 'few' at a conservative 2 days, that would mean my team would spend roughly 50 days doing nothing but learning this one very specific technology. That's 50 days of not producing revenue or otherwise addressing client concerns.
Now, I'm not saying that we shouldn't be able to take time to do things like this (learn and embed new tech), but to dismissively say "a few days" like it's trivial is severely underestimating the impact of dropping everything during that time to do nothing but learn about a tech that will most likely be obsolete or superseded in only a few years time.
This is a big part of why I left Web dev, too. I'm just sick of working with amateurs. When I'm at work, I have things I want to get done. This isn't the classroom, my teammates' lack of comprehension of even things as simple as dependency injection and MVC is their fault, not mine. My productivity and coding power shouldn't have to be hampered just because I'm working with a bunch of code-until-it-works-sorta hacks.
The point seems to be that the web is cool and hip, which attracts people without computer science backgrounds. Without a solid footing in software design fundamentals, "hack it until it works" seems like a perfectly valid way to run a development cycle.
The desktop is not cool or hip, so the people doing it tend to be people who really want to be there, not chasing trends. It's a vast oversimplification of the situation, sure.
I think a fair number of us non-cs-ers end up in web development primarily because html/css is more accessible. I, myself, was more interested in design than coding, and I only learned the basics as a means to creating the designs I wanted. From there you might start learning some JavaScript, you might start learning some frameworks (like Backbone, or ember), and you might get fairly proficient with them... but I don't think the web attracts non cs people because it's "cool" or "hip".
Necessary but not sufficient. I've worked with a lot of very experienced, very persistent people, and I'm sure they even had good taste, but they were shitty coders. In fact, their persistence was a requirement for them to be able to get their jobs done at all, given how bad they were.
Kind of surprised to see that this was posted by Paul Irish, considering he's such a huge web evangelist.
There are definitely some valid points in the article, but at the end of the day, it's hard for me to accept that The Right Way™ to do web development is to completely abstract away HTML, CSS, and JavaScript.
Certainly I live and breathe the web and do everything I can to advocate for its success.
I helped out Randy with this post because I think this perspective is both legit and underheard. Plenty of folks that work tirelessly to improve the web platform share frustration that many developers for the platform don't take it seriously as an application development platform, don't learn from past mistakes, and don't adopt the lessons learned from other platforms.
So honestly I think this painful truth needs to be heard if we expect the web to meet its potential.
The front end "developer" community is awash with web designers who know enough jQuery (not Javascript, jQuery) to sprinkle some woo-woo on "websites", but who have no software engineering skills to create genuine rich, immersive applications.
And they're resentful because rich, immersive applications that require some engineering power, and some necessarily complex APIs are the way things are going.
And these people are noisy and influential.
But I think that's changing. We are going to have properly engineered, web mediated rich UIs. Not a mess of cobbled together freeware.
I'm sorry about the harsh tone of my other comment (most upvoted comment so far) but the tone of the author is aggressive so...
Now on Cappucino's website I read this:
"Cappuccino is an open source application framework for developing applications that look and feel like the desktop software users are familiar with."
and I can't help but think this is all wrong. There are many (most ?) users who are now familiar with webapps, not desktop apps. And what they want is definitely not a webapp looking like an old, outdated, Windows or Java / Swing app (which is exactly how Cappucino looks like).
What many user wants is webapps that look like webapps and if they are "forced" to use a desktop app, then they want a desktop app looking like a webapp (I'm thinking about the client-side desktop apps embedding a browser + JavaScript engine).
I'm also pretty sure that devs who have done both advanced HTML + CSS to "customize" the UI of their app do much prefer that over, say, the total and utter madness that Swing is (I'm speaking of what I know).
Yes, HTML and CSS have their warts... But you'd have to a masochist to want to create a desktop app using Swing.
Users I'm sure they don't want apps that looks like desktop apps: they now have browsers, iPad, Android tablets, etc. They hardly remember what an old Windows desktop app was like.
Devs I don't know: I've done my fair share of Swing and the last thing I want is go back doing that.
I kinda like this "simple / straight to the point" webapp worlds that we have right now.
I feel that the web culture in general is exciting, and often, moving almost too quickly for it's own good. To me, the service companies contribute greatly to the distaste people have for working with the web. Most are churn and burn outfits solely focused on the bottom line, which drive developers away from the web in search of a better fit both career and life wise.
You know, it would be cool if the text in your webpage took more than an awkward 30% width. And putting it in a bigger font size would be the shit, most definitely. Just saying :)
That said, this being butt-hurt about lack of adoption for your pet framework is just fucking overreacting. Yeah, I know, it's your shit, you made it, you're very proud, now it's personal. Bluntly: emulating a recognizable desktop interface in the browser is a shit idea. Your Mac OS emulation on a web browser over my Windows is the web equivalent of James Bond in pajamas. Not to mention that it completely destroys brand identification, and makes legal departments cry.
You wrote some cool stuff, it got you some fame and a job at Google. Stop whining.
I'm not a web developer, so maybe I just don't understand, but why is it so important to the author that there be wide adoption of Cappuccino? Why does it matter to him that the majority of the web dev community is favoring "micro JS"? Why does he care that other web devs don't want to take a day to learn ObjJ? Why would he leave a path he's so passionate about just because other devs aren't being good software engineers?
To me this feels a little bit of a stab at the community for not adopting cappuccino but I remember what happened. Several years ago you showed us what it could do. We were impressed, we wanted to play with it but no, we weren't allowed. Instead of opening it up to the community it was kept locked away. By the time it was released (if ever?) we'd moved on. Now we don't care, we have frameworks that are good to work with (like angular). File size has nothing to do with it.
Perhaps we've reached the point of too many layers of abstraction.
The web is designed for simple hyperlinked documents with some media elements. We've done a pretty good job of adding more stuff to it than that, but that doesn't mean it has proven wise or elegant.
This is precisely why I wrote my .NET routing framework, JuniorRoute (http://projects.nathanalden.com/JuniorRoute ). I was tired of cumbersome MVC abstractions (ASP.NET MVC, FubuMVC) that don't fit the nature of HTTP. Some abstraction tends to be necessary, but I believe the MVC architecture is not appropriate for server-side Web development. We need frameworks that get us closer to the metal rather than introducing paradigms that don't fit with the browser/HTTP world we live in.
This reaction to Ember just baffles me. Your day job is to
build a piece of web software and you can’t take a few
days to learn the ins and outs?
What compelling reason can you give me to take a few days to learn Ember and not insert one of a dozen alternatives? Or should I take a few days for each of the dozens of newfangled alternatives that pop up every year? Are a few days even enough when you want to truly experience whether some framework is worth it?
290 comments
[ 1.6 ms ] story [ 247 ms ] threadThat's spot on. You can add in to that that all the lessons of the process of developing software have also been discarded and are slowly being re-learned.
It is as if with the birth of the web there was a complete reboot of the IT industry which accidentally also re-formatted the drive that held our knowledge about how you go about software development (which is different from knowledge about what it is that you are building, and different still from the technical details of your implementation).
On top of all that the web is incredibly messy.
That is arguably both a bug and a feature. The web is an untended jungle, possibly the most diverse of any technical ecosystem.
Democracy and markets are messy too, but I think most of us would rather not give those up.
People are actually proud of being able to make simple games or chat services using a browser. That is because it is so terribly difficult to do such simple things using the web as a delivery device.
- HTML - JavaScript - CSS - Server side code (pick your flavor) - HTTP - websockets - some real time extension (node or whatever) - a persistence layer
And all that for the basic functionality of tying a few people on graphics terminals to each other. Oh, and to make it more interesting we're shipping actual code from one location to another so you have a few security nightmares extra.
Chat services also incredibly difficult to run correctly over the Internet that there was no proliferation, there was... IRC. Which had its own major messes (recalling EFnet netsplits almost hourly in the early 90s).
Or let's talk about BBS'. So, you could do ANSI art fairly easily, but let's recall the hassle of handling multiple users on the software of the day. You usually didn't. BBS games (Tradewars, Legend of the Red Dragon, etc.) were turn based - someone dialed in, played their turn for the day, and waited for everyone else to dial in and play their turn. Email and Fidonet EchoGroups came in daily, or maybe twice a day, when you dialed into your upstream provider. The only way you could run a multitasking BBS with multiple phone lines was mostly DESQview, OS/2, or the BBS software itself had its own multi-threading.
The Internet didn't replace IRC and BBS'... the Web did. Not that they're gone completely, just no where near as important as they once were.
Network games are OTOH are still as complex as Netrek because they don't fit a Hypermedia architecture.
But ultimately I think you have nostalgia for a better world that never existed. Which is fine if you want inspiration for new ideas but... it is important to understand why the Web won: for many cases, it was better than what we had.
Nowhere, and I really mean that, was the tech as botched as it has been on the web past the early days.
However, what irked me is that this mindset flowed into the SaaS and native mobile app-development side of the house as well. Fully or partly-spec'd native development is expected to result in something pretty and take no time at all, just like the web-design side. Very little interest in engineering things properly.
Fear of over-engineering absolutely should be ever-present as part of your efforts. But, I think we're taking this to extremes sometimes.
These people don't have computer science degrees, so they spend a lot of time reinventing wheels. But lots of it works well enough despite all that, and as time passes, they learn and get better.
The messiness is a good sign, not a bad one. Thirty years ago these people would have had no options other than to be passive consumers of software other people made. Now they're making things for themselves! And some of what they make is good enough to help other people with their problems, too. That's a positive development, even if the things they make aren't always pretty.
Not exactly: https://groups.google.com/group/comp.sys.mac.hypercard/brows...
(That was 26 years ago, and HyperCard was far more accessible to non-computer scientists than the web is or has been).
It's a mistake to think that because the web is popular, that one can draw directly from it axioms regarding how technology should be implemented.
"HyperCard was far more accessible to non-computer scientists than the web is or has been."
A simple comparison of the total number of HyperCard stacks built versus the total number of Web sites built would argue otherwise. You can argue about whether HyperCard authoring is more intuitive than HTML authoring (I think it was), but as soon as the Web came along people decided for themselves which of the two they preferred to hack on.
Any computer was not cheap in 1987, much less one that sported a usable GUI environment that could run something on par with HyperCard. That had nothing to do with HyperCard.
> A simple comparison of the total number of HyperCard stacks built versus the total number of Web sites built would argue otherwise.
There were far, far fewer people actually running computers, much less collaborating on the internet, 26 years ago.
> You can argue about whether HyperCard authoring is more intuitive than HTML authoring (I think it was), but as soon as the Web came along people decided for themselves which of the two they preferred to hack on.
When the web came along, Apple had already made HyperCard inaccessible by charging a significant amount of money for the authoring tools, rather than shipping it with each Mac.
Even still, people were producing "My Favorite Links" and home pages, not apps.
True, but (1) PCs were significantly cheaper than Macs, and (2) many, many more people already had PCs on their desks than had Macs. So unless you were one of the few who already had a Mac, getting started with HyperCard meant plunking down money for new hardware.
"There were far, far fewer people actually running computers, much less collaborating on the internet, 26 years ago."
Again true, but irrelevant. We're talking about contemporary mindshare, and starting in the early '90s HyperCard and the Web were competing against each other in real time. HyperCard had a long head start and yet even by 1995 (the year Netscape 1.0 broke out) it was clear the Web had all the momentum.
"Even still, people were producing "My Favorite Links" and home pages, not apps."
And the buzzed-about HyperCard stacks were always more like presentations than apps. So?
I'm not trying to run down HyperCard here, it was a brilliant, revolutionary product. But I just can't fathom how anyone could think it more accessible to newbies than the Web was at the same time. And the Web has only gotten more accessible in the years since.
> True, but (1) PCs were significantly cheaper than Macs, and (2) many, many more people already had PCs on their desks than had Macs. So unless you were one of the few who already had a Mac, getting started with HyperCard meant plunking down money for new hardware.
In 1987, the web wasn't invented yet, and Windows 1.0 was the best the PC had to offer. This had some interesting results in the marketplace, but doesn't really explain much other than the fact that there's value in cross-platform implementations.
Apple wasn't interested in making HyperCard/Claris cross-platform, so they didn't.
> Again true, but irrelevant. We're talking about contemporary mindshare, and starting in the early '90s HyperCard and the Web were competing against each other in real time. HyperCard had a long head start and yet even by 1995 (the year Netscape 1.0 broke out) it was clear the Web had all the momentum.
I remember that time quite clearly, and until the mid-to-late 90s, HyperCard and the web were in COMPLETELY different spaces.
People were building complex enterprise database-backed applications on top of HyperCard; meanwhile, on the web, we had static pages, and post-1993, if you were lucky, CGI-based e-mail forms and visit counters.
Even with the introduction of JavaScript in 1995, we didn't see much other than rotating banners in the status bar until much later. Simply put, the web was not being used for applications at that time.
By the time the web did "break out" in 1995, Apple had moved HyperCard to their Claris subsidiary, stopped producing updates, and started charging for the authoring tools (a funny thing to do, given that HyperCard had always been Smalltalk-like in combining authoring and consumption).
Essentially, the lack of updates and unreasonable pricing led to its demise. These are market forces, not technological ones, and do nothing to disprove that 26 years ago, there were tools accessible to normal humans.
I first went online in 1991 (so that my friends and I could keep playing Shadowrun all winter) and got into the web in 1993 (I was 16, pictures were a big deal). Back then, there was this sense that the web could be really great, but I don't think many people grasped what it could be used for. Search technology wasn't great, so starting on someone's home page and surfing was how most people explored the web.
The first thing I ever built on the web was a homepage for a Shadowrun character. It was basically walls of text in which I talked about his complete history, and a whole lot of links to gaming resources. Needless to say, I got all the girls in high school....:)
Thanks for taking me down memory lane - sometimes I forget just how incredibly excited I was when I first discovered the online world. Without a hint of hyperbole, I wouldn't be who I am (in fact, I might not even be alive) if not for the web. :)
The landscape is littered with C frameworks, C++ frameworks, Java frameworks, .NET frameworks, and so on for every other language, that serves to abstract so much from the basics that it becomes so difficult to do basic things the <insert framework here>-way. The problem is that instead of being ancillary and supporting productivity, they are opinionated and try to do EVERYTHING for you, which just makes them really crappy DSLs.
This just happens to occur on the web a lot more because what we have to work with is inconsistent, sometimes poorly implemented, and confusing as hell to new players. So everyone and their dog tries to "solve" developing web applications by making you believe the DOM doesn't exist (jQuery, MooTools, etc). Some think HTML and CSS are too complicated and try to get you to believe those don't exist either (Ext, etc). Then some want you to forget that Javascript ever existed, or to make Javascript less Javascripty (GWT, Prototype/MooTools, etc).
The end result is a lot of opinionated dogma that rarely actually help us get things done (or get in the way more than help). If you pick a big framework, it's usually very good at whatever it was designed to build. But if you want to build something even slightly outside of that set, it becomes a massive cluster-fuck of WTF-inducing horrifying debugging and pain. Only the lightweight libraries that are massive value adds without enforcing a specific dogma on the user have been extremely successful.
The problem is that everyone is too opinionated and makes their software try to do your job for you. It's not really about the ease of use, it's about the ease of integration, extension, and whether they make our jobs easier or nightmarish. Yes, the web foundation is far from perfect, or even great, but most of these frameworks are far, far worse, since they massively and arbitrarily limit what you can do for the sake of some vision of simplicity.
The same problem exists in the native world. There is no consistent presentation layer that rivals the web, and even it isn't fully consistent (all browsers are different, and even the same browser on different platforms can behave differently). But it's a far cry from anything else.
As an aside, since JS isn't assembly, using it as a compile target to build applications foregoes a lot of the other fundamental technologies in a web browser. Sure, you might be able to compile <insert language here> into JS and have an application run in the browser, but that necessarily implies you're doing things like building the DOM manually, and sites like this tend to have significant performance issues. If you want it to work well, the best way currently is by using HTML/CSS/JS and by not letting a gigantic framework pretend that those things don't exist.
Really? Thirty years ago many of the most popular home computers booted directly into a BASIC interpreter.
Programming hasn't become more or less accessible with the web. You just write JavaScript instead of BASIC nowadays.
The web won. It fought a battle against many foes, and it came out on top.
Re-read that again and seriously think about it, because comments such as yours don't accept that simple reality. Do you contest it? Do you argue that the web somehow circumvented the competition?
For 15 years I've been promoting the web with groups that I've consulted with or led. For 15 years competitors have arisen with various alternative strategies, including MFC applications, Java Applets and then Web Start solution, .NET Winforms and then .NET WPF applications, Flex and Flash applications, Silverlight applications, and on and on.
And they all fell by the wayside. They lacked in features. They lacked in agility.
The only competitor that has made serious inroads are native apps on mobile devices, eking out an advantage due to the unique profile and unique input techniques of those devices, and of course gaming given that the web had no interest in gaming. The web is adapting.
If the advantages that you hold are true (in another post you argue that we salivate over stuff that was trivial 20 years ago. Yet ignore that we do things on the web that are just incredibly rich with but a few lines of markup and some ancillary code), those apps should have long devastated the web, teams making secure, easy to construct apps that run circles over those poor web developers.
The other big problem we have is that we're stuck with this idea of having cute little icons to launch things. Why can't we have icons that just launch a specific URL? Because then App Stores wouldn't make any money then would they?
Edit - Would someone care to explain their downvotes? Surely HN users wouldn't think to use a downvote to express that they just disagree, right?
That's what iOS 1.0 did. There were no native apps, just web apps that had cute icons that launched a specific URL.
People tried very hard to make that work. It didn't. The breadth and depth of mobile applications we see today only occurred once Apple provided a native SDK.
The reasons for this are simply technical ones.
Besides that, why take away the ability to create webbased apps? Could we not have the option if I know I don't care about any of the fancy stuff. There are so many apps out there these days which are just shells of an app with a WebView inside. It feels a bit ridiculous to have to buy Apple hardware to make a shell and then use our preferred dev environment to develop the site/internals of the app.
There were plenty of discussions about HTML5 vs native mobile apps. Big companies like Google and Facebook extolled HTML5, partly because they needed leverage against Apple's stronghold over the dominate ecosystem. So yes, the decision was a business one to begin with.
Then when reality didn't fit their agenda they've all since switched positions in 2012. Facebook rebuilding their iOS app with Obj-C, for example, to be as fast as possible. So then the decision ultimately became a technical one.
Maybe it'll flip flopped around soon. We did go through a period in the 90's when CD drives came out and everyone rushed in to deliver as much multimedia content on CDs as possible before that industry died and gave way to the ubiquity of the Internet.
In the future, smart phones are the CDs.
Unfortunately, this argument (which tends to imply technical excellence should trump all other factors in the success of a technology) has been used in technology for a long time, but frankly, in the end doesn't matter.
Ask Betamax, OS/2, etc, etc.
It won what, exactly? The war against Gopher for presentation of hypertext documents and information display? There's more to heaven and earth than data presentation and consumption.
The examples of genuinely great web applications are few and far between, if not near non-existent. Are Google Apps really the best the web has to offer?
Cappuccino provided one example of how to move the browser past the shackles of the traditional HTML/JS/CSS and into a world where developers could work with more accurate abstractions that actually represented the problem domains of application development.
This lesson has essentially been ignored, tossing out 3+ decades of experience our industry has in building applications.
I do my banking in a browser. I do my email in a browser. I manage photos in a browser. I manage relationships in a browser. I do my taxes in a browser. I order goods in a browser. I ship goods in a browser. I reserve items at the library in a browser. I watch movies in a browser. I listen to music in a browser. I push apps to my smartphone in a browser. I get directions in a browser. I find phone numbers in a browser. I phone people in a browser. I video conference in a browser...
I can go on and on all day. If you really want to argue that the web is a surrogate for Gopher, this conversation is futile.
I'd be interested to hear how those tools stack up against their native (or cappuccino) counter-parts, because implicit in your argument is that all these attempts to extend the web into the application space are better (and have 'won') over traditional approaches to application development, which I can't say has been my experience, even for the 'best-in-breed' solutions such as Google Apps.
Personally, I've found the surge of interest in native development via mobile to be invigorating, since it has meant a resurgence in applications that put user experience ahead of dogma (or even cost). I can hope that this continues to carry over to the desktop and other spheres over the next 5 years.
For many web-based tools, there aren't cappuccino/desktop analogs. They just don't make sense.
But I don't like doing everything in a browser. All the things you mention are transactional, but when I'm (say) writing music I much prefer to be in a native environment because the transactional stuff is a much lower priority. It's distracting, for many tasks. At the very least, I want to run some things without a browser frame of tabs, URL bar and so on without necessarily doing so in full screen mode.
Have you ever tried a Chrome Platform App? They don't have any browser chrome--they're just regular app windows, painted with whatever the developer likes--but they're still running in a browser. Sort of similar to Air/Silverlight.
I do many of these things in a browser as well, not because the experience is so great, in fact, most of the time it's pretty horrible. Banking, photo management or video conferencing in the browser a great experience, really?
I sympathise with this article, and even though web applications have come a long way, I'm sometimes amazed by the collective cognitive dissonance that seems to be prevalent among people who develop web applications, pretending that all is fine and dandy in web application land, and we've long surpassed the point where web applications provide better experience than good native applications. They are simply nowhere near, and the fact that e.g. Google Mail (which is a great web application) is considered superior to e.g. something like Sparrow is quite frankly very amazing.
It's a good example actually. Even considering the less pretty UI, Google Mail is superior to Sparrow precisely because it is web-based. From the user's side, the way it deals with spam and search are two huge functional advantages which would be difficult to impossible in a native app. And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.
For that matter, why are you equating 'the web' and 'server-side'? The standads IMAP protocol stores messages server-side while also enabling effecient server-side search. The standard managesieve protocol implements support for managing server-side filters from remote clients. Tools such as SpamAssassin perform intelligent per-user filtering server-side.
At that point, the only real differences between webmail and native clients are:
- UX
- Native clients use standardized protocols by default.
Even though it caches all e-mail locally, works offline, and it is a native app?
You can configure Sparrow (or whatever native e-mail client) to simply connect to your GMail inbox and have all the spam filtering and search capabilities that GMail has. Even the default Mail.app on OS X and iOS (which isn't exactly feature rich otherwise) does this. As much as I like GMail as a service, their web front-end is actually the part I dislike most about it, which is why I almost never use it.
>> And from the vendor's side, the ability to manage updates and monetise through ads are clear benefits which keep the program running.
Well, first of all I don't like ads and I don't care about how service providers can monetize it because it's web-based. I'd much rather pay a monthly fee for the service and/or a one-time price for the app, than having a web UI full of crap I didn't ask for. Not a very strong positive for web-apps. As far as updates are concerned, I understand that a web-based service is much more flexible in that regard, but then again, it's not really hard to have self-updating native applications either.
I could manage my photos in a browser, but I won't do "photoshopping" in a browser.
I watch movies in a browser, but I don't edit my home movies in a browser.
I listen to music in a browser, but I don't record or mix music in a browser.
I push apps to my smartphone in a browser, but I don't develop smartphone apps in a browser.
In general, I communicate or consume in a browser, but the worthy things - the creation - tends to happen outside of it.
Also, don't forget that all the things that consumers might ever see are just the tip of the iceberg - the vast majority of software and hardware development is done not for B2C apps/websites but for solutions that are B2B, business-process-internal or hidden in an appliance, never seen by any consumers.
That browser will probably look less like a browser - since it does everything, it doesn't really need a window.
*Except for your bank doing your banking. Of course it will be offloading the work to a dedicated application. The rest, however, will be browser-based.
Do you know why? Because the browser version sucks ass compared to the native version someone has designed for a phone UI. It makes me sick every time I pick up my phone to transfer money in my bank account while I sitting at a computer.
The pop culture of web development strikes me as a spastic, young programmer who flits from framework to framework, always in search of some magic elixir to make application development more pleasant. They know it isn't quite right, but they don't want to give up the hard-earned, arcane JS knowledge they've used. Nor are they willing to sit down and admit that, maybe they need to sit down and learn a thing or two about how to structure programs better (as we all do)!
Instead, it's emotional blog posts and bikeshedding over inane topics (vim, Coffeescript), rather than looking at the deeper issue - the utter mediocrity of the tools they're using.
I am also a strong advocate of web apps and have been for a long time. Reality has proven out my position as, as has mentioned, the web won the presentation tier (clearly this has nothing at all to do with data processing or database or system programming or anything of the sort).
In any discussion on web apps they are always held against an illusory foe that is all capable and all perfect. Let's get specific however -- I love Rdio and love their web app. They came out with a new .NET client so I of course gave it a whirl.
Worse, slower interface. Constantly updating (in big monolithic chunks). Consuming hundreds of MBs of memory.
I'm not trying to criticize specifically Rdio, but I guarantee that initiative started with someone slamming the web and its crazy mishmash of standards, promising that they'd do something that would exploit the full power of the client. The result was something much worse, holding the single and only advantage of "not in a web browser" (for what that's worth?). Amazon has fielded various trials with various rich apps (they usually partner with Microsoft), but you've never seen them because they never have a compelling story, coming with enough detriments that it outweighs the benefits. My local library system used to have a whole nasty Java interfacing tool that was an absolutely abomination, with a horrendous rickety interface that seldom worked properly, was slow, and was a beast. They replaced it with a dramatically better web interface.
Those are all just anecdotes, but they're constant across the space. Yet every post pretends that the web is a weakling that has no merit and no advantages, completely missing why it has made all of these wins against endless competitors.
Sorry, you're going to need to elaborate here or else you're really sensationalist. Also, you can't be serious about the community not admitting we need to learn how to structure programs better, as if that were the only problem. I didn't learn that UNTIL I started working on the web.
Every good web application beats its desktop rivals simply by being ubiquitious. People who dismiss the web typically ignore this simple fact completely. But it's always been true, you can look back to 1997 when Yahoo Mail killed the desktop email client business not by being flashier or better (it had full-page refreshes over 56k modems, awful!) but because you didn't have to ever worry about not having access to your email again.
How Microsoft lost the API war: http://www.joelonsoftware.com/articles/APIWar.html
and
The Location Field Is the New Command Line: http://daringfireball.net/2004/06/location_field
Note that both of these articles kvetch about user experience and how the web simply can't compare to native apps, but emphasize that the ease of deployment matters more.
Also, note that the app store model obviates some of the deployment difficulties of native apps and makes it almost as easy to install native apps on the phone as it is to visit a web page.
I think this (desire for ubiquity/multi-platform) is the main reason I don't see eye-to-eye with the people who are pushing for web apps for everything. Web apps everywhere is great for large corporations that want to provide their service on as many platforms as possible. It's great for venture capital funded startups where the name of the game is to get as many users as possible and get bought out before your money runs out.
I'm a small indie dev though, I produce software (not software as a front end to a non-software business), and I'm not looking to become a billionaire (really!). I want to develop software because I enjoy it: to solve problems for real people, to solve my own problems. So really I don't care too much about being able to target every platform at once. I want to target the platforms I like, using the tools that I like, and as long as the platform has enough users to make it viable then I can do that with native software on open platforms (the latter is important and why I don't write iOS software, for example). There is the risk that the platform I target gets killed, but if a lot of people use it then that's generally going to be a slow process, and there is plenty of churn in web tech and standards anyway so it's not like it provides immunity to technological change. Additionally, I just have a hard time working with web technologies. I find them much harder to use, to the extent that if using html/css was the only way to write software I wouldn't be writing software at all and I'd go stack shelves in the supermarket instead. Maybe I'm just not smart enough to use them effectively, I don't know.
I guess this is partly the old 'software as craft'/'lifestyle business' argument, but it saddens me slightly that the big industry players are moving us away from the kind of industry where you can write software that interacts with some arbitrary bit of hardware in unsupported or unintended ways towards a much more controlled and profit orientated one (i.e. your software running everywhere being the most important criterion of all). Web people are not the only offenders here of course, but arguments against things like iOS have been well explored over the years.
Some people seem to view the web as some kind of beacon of freedom, the little guy fighting the big bad industry giants of Microsoft, Apple, Adobe and so on. But from where I am, the web is the big bad industry giants. Writing web software means being restricted to a very limited sandbox. The APIs available to me are decided by what a small cabal of powerful companies (Apple, Microsoft, Google, Mozilla, Nokia and maybe a few others) can agree on. None of their interests align with mine (why would they?).
If Gopher had taken off and supplanted native development to the extent that people were using platforms that could only run Gopher apps, would the current web even exist? All user facing software being written to a single standard and API has good things about it, but it also limits new ideas tremendously ("sure you can add X feature you just need to get it through this committee of industry heavyweights first and get them all to agree, and then wait for them to ship it").
What is important to me is that data uses open standards, whether at rest or in motion. If people control their data, and it is in open formats, then there is little companies can do to lock them in. Which is good for me as a dev since I can write software to help users work with that data. Web technologies don't do much to help me there, in-fact for the most part they have made it easier for companies to keep users data locked away on their server in unknown formats or behind proprietary API...
My one point would be perhaps the way things are now is because it's good enough. Using the web and building for it is good enough for a lot of people, the speed bumps and systems in place are good enough for the majority.
But I do agree, we've gotten to a point where a handful of corporations dictate how everyone else get to do the neutron dance and that the bleeding edge needs to be examined and worked on so that change can occur.
Today, almost all that development has moved to the web.
>And they all fell by the wayside. They lacked in features. They lacked in agility.
No, no and no. The web "won" because its simple and the lowest common denominator was good enough for most people. The web has always been far behind in terms of features and agility (depending on what you're trying to optimize when it comes to agility). The web won solely because it was "open" and every company had a stake in ensuring no one company could sustain their monopoly. The web sucks and it did not win on its merits.
There is no one right way to build an app for the web the way there is for Android or iOS. That's a problem for both the applications authors and users. Cappuccino attempted to solve that problem in a way that did not appeal to programmers, it seems. jQuery UI succeeded to a point, and now Bootstrap seems to be the framework of choice. Perhaps a widget-based UI framework that can target the desktop and mobile devices would make sense.
What utter BS. You are essentially celebrating the victory of consumer commerce, not technology X over technology Y.
Think about it.
There never was any battle between the "Web" and "MFC, Java Applets, Webstart, .NET, Flash, Silverlight". Those thing survive & even thrive in places where nothing else would do. Do you really think everybody in investment banks & brokerages fire up their browser first thing in the morning ? 99% of what they did, do & will continue to do, will continue to be done via native apps - mostly C#, C++, .NET & Java apps. This is just plain reality. It isn't because they are lazy or don't grok the web. Processing realtime trading feeds isn't the browser's strength. Sure I'll show you an iframe with some ticker, equities blotter, trading tickets ...but that's just consumer commerce. I'm soliciting your cash - Here consumer, click on this Buy button, give me your money. After that ? Once you fire off your client request, that's when 99% of the task actually begins, and it ain't on the browser, no siree.
The web is just the tip of the iceberg. Most of the action is below the surface of the water, and that's not the web & will never be.
To your point - the whole idea behind Webstart, Java applets, Winforms, was to mimic the native UI on the web & try to offload as much client-side logic to the client's machine.
Turned out customers didn't like "fat clients" - they wanted textfields & simple input forms, accept their inputs & go away & process the inputs elsewhere.
We said - Hey, you guys have a fast processor & slow network, let's do this one-time applet download/Webstart download/Silverlight app download, & once done, we won't tax your network, we'll just tax your machine. I wrote one of the first equities trading applet for Goldman Sachs. It was a fat client ~100 MB, you actually waited 10 minutes for the install. But it did so much - all the trading rules validation, portfolio construction & computation, everything happened inside that applet. Once the applet downloaded, it felt & behaved like a native desktop app. It was so much more powerful. There was actual science in that applet. It took a doen CS PhDs to build the infrastructure for shipping that. We fucking got dozens of patents...pseudo-realtime trading applet over the web ha ha ha! Today, the interface is so dumb - zero download time - but they hit the network so much harder. Absolutely nothing happens on the client. To check whether a simple trade is valid, you have to hit the server multiple times during the workflow. Customers are ok with it because the network has gotten so much faster. They were downloading ~100MB applets on 56.6k modems, now they have superfast broadband, so it makes sense to hit the server more & do less on the client box. So you just hire an 18 year old & he'll build a polished web UI for the trading applet over a weekend. That doesn't mean all those CS PhDs just up & died. They just migrated to the server side, where all the action now happens.
So this isn't success of the web & failure of the applet - its success of broadband. Network penetration today is massive & ubiquitous. You can place million dollar trades over android. You couldn't do this just 10 years back. At that time, applets were state of the art. In hindsight, the whole exercise appears pointless. 100MB applets WTF, just use underscore dot js & ajax & broadband & a little bit of markup & your trading window shows up on a tiny 4 inch android cellphone. Yeah, true, but we didn't have any of that back then. Cut us a little slack, will ya.
It isn't celebrating to point out a reality of the world relative to a post that seems to imagine that every other solution was handicapped in the race. And it IS completely based upon technical merit.
"Do you really think everybody in investment banks & brokerages fire up their browser first thing in the morning ? 99% of what they did, do & will continue to do, will continue to be done via native apps - mostly C#, C++, .NET & Java apps."
Humorously I build software for the financial market. Our presentation tiers are almost entirely through web apps. The competitors I was talking about -- the ones who poured cement on their own feet -- went the "thick client" route. And we keep on iterating.
"The web is just the tip of the iceberg."
Yes. No kidding. I'm not building a database in the DOM. I'm not processing trades in JavaScript. This discussion is about the presentation tier. Every criticism of the web always holds that you could toss together something so much better in some illusory, never proven alternative, but that simply isn't true.
Kind of sounds stupid without 6 paragraphs filling it out, huh?
But I think the open web will win in the end, not because of any inherent technical advantage (in some ways it's behind native apps still in terms of performance, look and feel etc), but because the open web has so many advantages for developers and users that in the end it will overcome its disadvantages. Performance and UIS are improving constantly on the web (contrary to the opinion of this poster), so the gap is narrowing. At some point the performance won't matter, offline web work will become possible, the network will be fast and ubiquitous enough and the advantages of the open web will come to the fore.
As a developer of web apps and mobile apps, the contrast between deploying a few fixes a day to a website, and working hard on new app versions only to have them rejected by an anonymous gatekeeper at Apple, often for inscrutable and unjustified reasons, then waiting days or weeks for approval, could not be more marked. Things are easier on the desktop, but there are still far more hurdles to deployment, and that matters a lot, as you hint above. The only thing I really miss on the web is a great language to script web pages in, but that will come (js is not my favourite language), and you can use any language you want on the backend, and no-one need know.
As a user, the advantages of the open web (i.e. not walled gardens like Facebook) will I think have an irresistible pull - advantages like linkable, shareable content, content on any device, even unforeseen ones, not having to rebuy apps but just subscribing once and accessing content from anywhere. The fact that the web is not controlled by a single vendor as most commercial operating systems or devices are is an added bonus.
Finally, I'd argue that the radical simplicity of web technology is actually its greatest strength, as it means it can be deployed almost anywhere, even with limited resources, and give at least some value to users for decades and over any new devices which come out, as opposed to the binaries being created for current platforms which in a decade will be forgotten or dumped by their vendor in favour of the newest flavour of opendoc, .Net, whatever... I find it fascinating that the web delivers consistently better results by virtue of keeping the tech simple and backwards compatible.
Worse is better after all.
I agree that web developers in general and web development in general follows this trend. But his evidence for it is unconvincing to non-existent. Caring about file size is not a symptom of "tossing out everything we've learned from the last 30 years".
Application programming tends to be far more complex, far more planned, and far slower. Applications last for years and years, and new releases might take multiple years.
Whereas web programming can be extremely experimental, prototype-y, with multiple releases a day. It's also vastly faster to program.
This isn't an argument against good architecture -- far from it. But it does mean that the kind of long-term planning and investment that makes good traditional applications, isn't always applicable to website programming.
Due to the nature of the market, "complete disregard for maintainability or extendability" is sometimes a good thing, because you can iterate faster. Think of a lot of web programming as prototype programming -- then, you go back and re-architect, re-engineer, etc., as desired.
Really? You can build non-web apps just as fast as web apps. There are decades of tools and programmer experience doing this daily. You can't build Autocad or Photoshop as quick as you can churn out a buggy Rails site, but that's comparing apples to oranges.
I expect the underlying point was that most popular native platforms today almost force you into best practices which does add some upfront cost.
On the web you can throw up a single page PHP script full of SQL injection vulnerabilities and Javascript spaghetti and you are off the races. There is generally no equivalent for a modern GUI system. You typically need to start with a full MVC infrastructure in order to even begin to interface with the system libraries.
When you take care to craft your website using the same best practices the differences become negligible, but a large number of developers do not care about architecture and can take shortcuts that make it feel like they are moving faster.
Most of the arguments in this thread are coming from two totally different perspectives. Some holding doggedly to various ideals and dogmas and instead of trying to learn the new domain, they try and make the apples look like oranges. This never works. Most are right about this or that when it comes to the domain that they are experienced in, but when economics forces people into a new problem space some don't try and learn the new space as a thing in and of itself, instead they try and adapt their methodologies and abstract to a different problem space they are more familiar with. That is where these conflicts come from.
> all the lessons of the process of developing software have also been discarded and are slowly being re-learned.
The web wasn't originally intended to be used to provide native like experiences and so the foundations for that just weren't there. So yes, people had to re-invent and re-discover all those desktop frameworks but this time in a javascript & html environment.
I think the obsession over desktop like frameworks in Javascript is due to the fact that there just isn't a clear winner yet and that is because the foundations required to support a clear winner just don't exist yet.
-We need the ability to scope CSS to a given section of the document. I want to be able to import someone's widget (or set of widgets) and not worry about style collisions.
-We need a better solution for storing templates (pre-compiling them into .js files or storing them in <script type="text/template"> just seems awkward)
-We need a better way to bundle CSS with its resources. I.e., if I have a css file in "components/bootstrap/styles" that refers to "../img/pic.png" it is going to break when I concatenate all my CSS files into one and drop them in "/"
-We need a better module system. Yes, requirejs is good but I'd like to say I depend on "package.name.x" and not care where it comes from or who provides it. It should just get loaded for me (this has been solved for years in the Java world via OSGi).
-We need a better build system. Yes, grunt is good but I have to put in all sorts of logic to handle the above problems.
-I should be able to place custom tags in HTML and have the browser create my user-defined component for me. I.e., <usr:combo> should find the correct template and backing javascript and construct the component.
There won't be a winner and the re-invention will continue until these foundations are put in place.
That said, I have never understood the driving need for desktop like frameworks. The problems that ubiquitusly networked applications and communications technology face are nothing like those of kernel code, commandline applications, or modern applications like CAD Photoshop. All the things you mention that need fixing desperately need it, but I don't think a desktop like framework/library/standard for the web will ever 'win' because the web is not trying to solve the problem of a virtual desktop, it is trying to solve the problem of a non-homogeneous ubiquitously networked data exchange layer.
Also a lot of these issues come from looking at each piece in the development cycle separately rather than holistically. Frameworks like meteor are starting to address this, but we still have a lot of work to do.
Chances are that you probably never had a dial-up connection. 49KB on dial-up generally takes around 10 seconds.
Besides this point, the accusatory tone towards front-end developers and 'the rest of the world' that did not understand you isn't helping to get your point across. You were in the wrong place in wrong time. It happens. Move on. There are better things to do, and bitterness only hurts yourself.
Erm, isn't dial up at 56kilobits per second? It will take much longer than a second to download 49KB.
Seriously: being on your high horses and all is fine and well but your article is an oversimplification as to how the web works and as to what devs need and want.
For example lately I've been very interested in flapjax (FRP UI) and webfui (Clojure / ClojureScript with automated synchronization between the client and the server).
Functional programming and FRP UI may be the way forward. I'm not saying it is but I'm saying it may. What does Cappunico have to offer from the standpoint of determinism and reproducibility? Seen from a sufficiently distant paradigm, any web framework is the old, broken, inneficient way of doing things. Even your beloved Cappunico which you wasted so many time on.
Cappunico is a failure. It doesn't have to do with you being too intelligent and having figured out things earlier than others. It's just that there are many who devs do not want Objective-C / JavaScript and who want instead something really disruptive. As long as the one really disruptive thing doesn't come along, there shall be competition between lesser solutions (which Cappucino being one) Deal with it.
Randy's probably right about how silly all the tiny reinventions of UI frameworks are. And, though I'm generally unsympathetic to claims that a project is a failure because people don't want to learn the tools, I think it's safe to say here that asking people to use a language that's only marginally less horrible than JavaScript is not going to be a win from any perspective.
But he fails to realize that doing UI in a Cocoa-like framework is totally fucked (to be clear, I do Cocoa touch for a living; I'm speaking from experience).
I'd be making an understatement if I said I was unexcited about Cappuccino because it fails to even approach solving any of the truly important problems of UI work, which are (as you hinted) less about "can I make the table scroll quickly" and more about "can I decouple this monstrous mess of data, dependent requests, and presentation". As you note, FRP looks like a step in the right direction toward solving that problem. Traditional Cocoa-like approaches are a step backwards in that area, not forwards.
I think he was simply pointing out the fact that we've stagnated at the same level of abstraction in the web space for a long time. Cappuccino is just the example he's using to point out where we were relative to where we are and in that light it's almost a regression.
For the purposes of his larger argument, the way that Cappuccino delivered its abstractions (Objective-J) isn't as important as what it allowed you to do with the web.
Another related example, I recently learned of H2 (http://www.h2database.com/html/main.html) and I honestly had to ask myself, why is this needed? If you want an embedded SQL DB why not just use SQLite? If you want a full featured enterprise SQL DB, why not just use PostgreSQL? And don't even get me started about Walyand/Mir as opposed to Xorg, or the whole debacle of disabling separate /usr because of rewriting things like init to use glib and other non-base system dependencies. The hubris, lack of knowledge of history, lack of foresight, and just plain lack of professionalism (to put it politely) are staggering.
SQLite is native C, H2 is Java. There are significant deployment and potential stability advantages to not using native binaries in your Java software.
There have been some neat hacks to get sqlite running under Java, including using a tool that translates MIPS binaries to run under the JVM, allowing the use of libsqlite as 'native Java' code: http://nestedvm.ibex.org/
This is, however, not something you'd likely want to use unless you absolutely need to interoperate with sqlite's data format.
Fully native java and an in-memory implementation mean that we can very quickly implement it in our systems.
It pains me that Cappuccino has received so little interest, for despite all its possible drawbacks it represents a very interesting path for future web programming.
That applies in the opposite direction too. Native programming seems to involve jumping through insane hoops just to do simple things:
Like "put some text on the screen, this part is bold".
Or "open this web page".
Or "put these things next to each other, with 10px in between, unless the screen is a little narrower, then put the second one below with no margins".
Or "I want to play with the layout of this every day for the next month, have the new layout download every time someone uses this app".
I can write complete, ready-to-distribute web apps that do those things in 1-3 lines of code. Doing so in iOS takes many layers of indirection.
Look at something like Ember.js. The abstractions being put in place are fascinating. Or CSS. It's is an incredibly powerful abstraction on something that iOS just scratches the surface of.
The truth is, both the web and iOS have evolved to deal with specific pain points. Some things that are easy on one are hard on the other.
This idea that web programming is under-abstracted seems really narrow-minded to me.
Let's remember that even as recently as 2-3 years ago, top end phones and tablets were single core ARM processors clocked at ~1GHz. And devices of that spec are still in wide spread use even now.
The point of the HTML is that it's an open standard which should work on any internet device regardless of platform, patents and what not. While I admire the ambition of the guys who push the envelope of what the web can do, they often forget that everyday sites also need to cater for low end devices used by everyday folk.
The idea right now for telecoms and device manufacturers is more about getting their stuff in as many people's hands as possible, not about whether they can replace a screaming desktop with a handheld.
Let make information available to everyone; then we can worry about making those sites fancier than a strippers underwear draw.
Low end devices are a good point, my main gripe with all these frameworks is that they make it very easy to break many conventions of the web (URLs no longer work as intended, extra efforts is needed to make the pages crawlable etc.).
You have solutions like gwt, cappucino and extjs which build custom ui components that behave properly, ad the infrastructure to tie them together. This works, but only if you never step outside the framework, and only if you're willing to deal with bloat, which sucks. Then you have frameworks which just give you the infrastructure, not the custom ui components, like ember or backbone. That also works, but because html's core controls are horrible the only way to get a great ui out of that is to build really custom ui, essentially rebuilding what the complicated frameworks already provide out of the box, which sucks. And then you have one-shot solutions that try to bring just one or a few ui elements to the web, trying their best to fit into the raw platform. That also works, but because the raw platform is so painful to use, it doesn't scale.
Really, the problem is that html/css/js is the wrong base for building abstractions on. I have great hopes for shadow dom and web components, but that's only the beginning of what we need. The platform itself needs to evolve a great deal to make building high-quality ui something that doesn't lock you into a vendor's toolset.
Personally i chose extjs and am waiting it out until the platform matures underneath it. I'd like to see the extjs codebase evaporate as parts of it get replaced by native code, until it's nothing but syntactical sugar on top of a rich base platform. That's going to be a while though.
Is he saying that a product failing is the fault of customers? That's simply ridiculous.
No matter how you put it, one way or another it is ALWAYS you fault, I don't even know what it might be the problem, but it's your fault.
Some front-end devs are technicians that need to generate value quickly, and most can't afford investing time in a new complex system that may disappear tomorrow. If there are no clear advantages on the business side that justifies the investment, then there is no pressure to the front-end devs to do it.
Good engineering also means optimizing technical designs for the usage of the technology in order to reduce costs. That includes factoring in the skills of the technicians that are going to use the tech (and the cost of training them).
My objection is right here. No need to mix in the Objective-J at all.
Microsoft's ASP.NET tried to do this thing, to a surprising amount of success. The context then ofcourse was "Web 1.0" pre-Digg internet and the only other "big thing" being PHP.
Microsoft managed to take the whole "Draw a GUI in Visual Studio and it's a done app" thing and take it to the web, much like it originally defined Windows-programming with Visual Basic. It was an immense success and very cool.
Then Web 2.0 (as much as I hate that term) came and changed the game.
Then not working on the raw metal became an obstacle to making ASP.NET do all those cool things which everyone else was doing. It's killer feature (not having to know HTML) became it's Achilles Heel. It's abstractions became a hinderance to all the things you actually knew how to do once the framework got out of your way.
I may be a tad pessimistic and cynical, but I doubt a framework whose main goal is to give you a non-webby workspace will be a long term success when you're actually working on the web.
Microsoft learned that (too late?) and have tried to remedy the situation with ASP.NET MVC, but by the time that became useful, it seems lots of .NET developers went off to find cool stuff elsewhere.
A new framework like that, right now, seems like an utterly dead end.
I'm joining OP's web haters club, if he starts one.
Every time I hear a programmer condescend towards other programmers for using a higher level language, I also die a little bit inside.
How is javascript not the "metal" of the web? It's a core part of the modern web experience upon which many libraries and frameworks have been built.
I don't understand why that analogy is bad and is worthy of your condescension.
Are you just being condescending to the entire web paradigm in general?
A language interpreted at runtime, by an application that runs inside an operating system (which may or may not be virtualized) that boots into protected mode. Let me get this straight, you're ostensibly describing this as being "bare metal"?
Have you ever heard the terms "kernel mode" or "ring zero"?
Oh wait, you qualified it as "the 'metal' of the web"... so it's an "analogy". Sorry to be pedantic, but when people say "bare metal" in the context of platform virtualiztion, "bare metal" literally means just that. The executable code is compiled into binary that directly correlates to the copper wires (and etched semi-conductors, or perhaps even vacuum tubes) of the specific, real, tangible machine intended to execute the code. JavaScript is nothing like this.
Maybe the packets and datagrams of transmission protocols are the "bare metal of the web", but JavaScript most certainly is not.
Check out the Communication Systems OSI Model.
http://en.wikipedia.org/wiki/OSI_model
I'd contend that nothing above Layer 4 could be considered analogous to "bare metal".
You do realize it's been a while time since the ostensible instruction set and corresponding assembly language of most modern CPUs translated directly to the bare metal execution model of the machine. http://en.wikipedia.org/wiki/X86#Current_implementations Even on RISCier architectures, virtual memory, deep instruction pipelining, super-scaler dispatch, branch prediction, multi-layer caching, inter-core cache coherency, etc. introduce a huge amount of abstraction between the instruction you write and the actual execution on "bare metal".
On current chips, x86 machine code is as much a virtual machine as java byte-code. It's abstractions all the way down, you just pick different levels for different classes of work and "bare metal" is now just a label for one below where you landed.
I understand what you're trying to say, but this is way off base. x86 instructions may not align exactly a processor's primitive operations, but that doesn't mean abstraction makes x86 similar to the JVM, at least not anymore than it is similar to a Bible printed on papyrus. But nobody cares if ancient Hebrew is just as much a virtual machine as Java, so stfu.
"Sometimes writing markdown feels like working on the bare metalloid"
But! IN THEORY You could still construct a processor out of electromagnetic relays (springs, contacts, leads and solenoids only), if perhaps your goal was to never exceed 100 Hz.
(...at first I was going to point out http://www.bigmessowires.com but it turns out that beyond the wire wrap connections, he's still using modern semi-conductor packages)
It also brought in some clueless people who had no idea how HTTP, HTML and JS work, with questions like "why my button.hover event does not work" (this was pre-ajax, the event code was on the server and had no ways of knowing the user is hovering over the button).
Maybe it was OK for CRUD and internal applications but not for ordinary websites or sophisticated web apps.
.Net MVC is seen as a success: clean HTML, predictable things under the hood, jquery.
Eventually, yes. Which I addressed. But prior to the whole Web 2.0-thing, it was actually pretty successful by lots of means.
I'm not saying ASP.NET MVC is superior in most respects. There's no doubt about that, but it was clearly a late-started initiative which should have started much earlier. ASP.NET already had lost its respect and was a waning star by the time they got the first version out the door.
These days it's actually fairly pleasant to work with. The only thing I can say I really dislike about it is that you can still find the traces of all the old ASP.NET warts there, if you go beneath the hood.
Edit: Thanks for being the only one replying to the actual topic at hand, as opposed to doing inane discussions about what "real metal" is these days. And that's coming from someone with a degree in electrical engineering and design of digital electrical circuitry.
Oracle are doing similar things these days too.
This style of thinking damages applications. Yeah you've made it easy to build a form with validation, but users don't need half the form fields, let alone the form itself. Also if you thought about it, you could have came up with a more innovative way to capture user data that would lead to more registrations, and thus more users.
Web frameworks happen because people try to leverage their existing knowledge, skills or codebase in a web domain.
i.e. GWT & Vaadin are web frameworks where you use java and there is literally no need to know JS/HTML/CSS to create some really nice web apps that perform well.
I don't want to say that you don't need JS/HTML/CSS knowlede to build web app. But those frameworks allow people to be productive with almost no such skills.
Or when a change of behavior asked that is not supported by the framework out of box?
Randy's passion for Cappuccino was blatant and his excitement at seeing the framework expand in the UK was admirable. The fact that someone so passionate has become so frustrated is a shame.
Best of luck at Google Randy and thanks for taking time out to help a stranger.
There are a huge number of frameworks out there. Pick one, and then hire people and have them spend a few days learning it.
Adding more and more frameworks leads to, well, relevant XKCD: http://xkcd.com/927/
Metaphorical "you" alert, not directed at parent:
You have a new-fangled thing for everyone to use. Scratch that, everyone who's been in your shoes, with your particular pains. Great, you solved a problem. Take some time to explain on your blog or in your GitHub README.md the context of your solution. "Because I can!" is a fine reason, but I don't spend time exploring something that was built because it was possible to build it.
So your new-fangled thing looks like it's a solution to a problem I'm having. I start to implement it and ... oh dear $DEITY, it's a mess. I don't mean it's ugly, I mean it's completely inextensible. It's a specific solution where a generic one would suffice. Or worse, you didn't think outside your little box to discover that this "fix" will debilitate 95% of the web servers on the planet if they were to try this solution.
My advice: if you build it, A) explain why, B) learn to build it well.
Couldn't agree more. While I do think that new technology should be intuitive and easy to use, you have to take the time to explore, learn and familiarize yourself with it. I think peoples' attention spans are way too short these days.
Using his off-the-cuff, totally subjective "a few days" estimate, and assigning 'few' at a conservative 2 days, that would mean my team would spend roughly 50 days doing nothing but learning this one very specific technology. That's 50 days of not producing revenue or otherwise addressing client concerns.
Now, I'm not saying that we shouldn't be able to take time to do things like this (learn and embed new tech), but to dismissively say "a few days" like it's trivial is severely underestimating the impact of dropping everything during that time to do nothing but learn about a tech that will most likely be obsolete or superseded in only a few years time.
While frameworks like AngularJS won because they tried to embrace web technologies instead of replacing them.
The desktop is not cool or hip, so the people doing it tend to be people who really want to be there, not chasing trends. It's a vast oversimplification of the situation, sure.
I'm pretty sick of the "I work with people without CS degrees" excuse. Good software design really comes down to experience, persistence, and taste.
There are definitely some valid points in the article, but at the end of the day, it's hard for me to accept that The Right Way™ to do web development is to completely abstract away HTML, CSS, and JavaScript.
I helped out Randy with this post because I think this perspective is both legit and underheard. Plenty of folks that work tirelessly to improve the web platform share frustration that many developers for the platform don't take it seriously as an application development platform, don't learn from past mistakes, and don't adopt the lessons learned from other platforms.
So honestly I think this painful truth needs to be heard if we expect the web to meet its potential.
"(Obviously these opinions are my own and of course do not represent the opinions of my future employer)"
He has no real world experience doing anything that matters so just chats about what he's witnessed from within his bubble.
I just read his 'about me' section and feel a tiny bit humbled..... not massively though.
The front end "developer" community is awash with web designers who know enough jQuery (not Javascript, jQuery) to sprinkle some woo-woo on "websites", but who have no software engineering skills to create genuine rich, immersive applications.
And they're resentful because rich, immersive applications that require some engineering power, and some necessarily complex APIs are the way things are going.
And these people are noisy and influential.
But I think that's changing. We are going to have properly engineered, web mediated rich UIs. Not a mess of cobbled together freeware.
Now on Cappucino's website I read this:
"Cappuccino is an open source application framework for developing applications that look and feel like the desktop software users are familiar with."
and I can't help but think this is all wrong. There are many (most ?) users who are now familiar with webapps, not desktop apps. And what they want is definitely not a webapp looking like an old, outdated, Windows or Java / Swing app (which is exactly how Cappucino looks like).
What many user wants is webapps that look like webapps and if they are "forced" to use a desktop app, then they want a desktop app looking like a webapp (I'm thinking about the client-side desktop apps embedding a browser + JavaScript engine).
I'm also pretty sure that devs who have done both advanced HTML + CSS to "customize" the UI of their app do much prefer that over, say, the total and utter madness that Swing is (I'm speaking of what I know).
Yes, HTML and CSS have their warts... But you'd have to a masochist to want to create a desktop app using Swing.
Users I'm sure they don't want apps that looks like desktop apps: they now have browsers, iPad, Android tablets, etc. They hardly remember what an old Windows desktop app was like.
Devs I don't know: I've done my fair share of Swing and the last thing I want is go back doing that.
I kinda like this "simple / straight to the point" webapp worlds that we have right now.
That said, this being butt-hurt about lack of adoption for your pet framework is just fucking overreacting. Yeah, I know, it's your shit, you made it, you're very proud, now it's personal. Bluntly: emulating a recognizable desktop interface in the browser is a shit idea. Your Mac OS emulation on a web browser over my Windows is the web equivalent of James Bond in pajamas. Not to mention that it completely destroys brand identification, and makes legal departments cry.
You wrote some cool stuff, it got you some fame and a job at Google. Stop whining.
> Objective-J
oh yeah
The web is designed for simple hyperlinked documents with some media elements. We've done a pretty good job of adding more stuff to it than that, but that doesn't mean it has proven wise or elegant.
Get off my lawn.