7 ms·
Yes by web I mean HTML5, JS and CSS3, REST and HTTP/SPDY. Yes I can snapshot everything if I want but the problem with the web is that it is a general purpose
by csmithuk 13y ago
Yes by web I mean HTML5, JS and CSS3, REST and HTTP/SPDY.
Yes I can snapshot everything if I want but the problem with the web is that it is a general purpose tool. It should be a single portal into everything both local and remote sites and applications.
Unfortunately, the rate of change is incredibly large for Internet-facing applications. Intranet-facing applications are left behind. As browsers evolve, which they do rapidly, unpredictably and without compromise[1] a disparity grows until you need two browsers. This is not a situation an enterprise wants to or can afford to maintain, simply because it's below the watermark of concern for 99% of users. This is my point.
The difference between the CLR/JVM and a web browser is that they have a predictable shelf-life and can be maintained separately as they are separate portals into each world. To be fair (I exclude the CLR from this as it's too integrated into the OS), I can ship a JVM with a Java app and it'll run quite happily for another 15-20 years.
And yes I have tried running a 16-bit VB4 (!!) app lately - one of our clients uses one. On 32-bit Windows 8.1, it still works absolutely perfectly (Windows Vista 64-bit+ has no 16-bit subsystem).
[1] Apart from IE.
- TheZenPsycho 13y agoYou've come to exactly the wrong conclusion. web sites from 1992 still work on browsers today. it's IE proprietary activex stuff that's broken and changing rapidly.
- csmithuk 13y agoActually no they don't unless they are a really small subset of HTML/CSS. The box model was broken for years, don't even get me started on tables, JavaScript is the most loosely defined language to have ever existed, there have been several different document parser models (HTML, XHTML, HTML5) it's unreal. At best, most browsers these days estimate what they are doing, diving into some wierd mode full of edge cases purely by accident if you step on the wrong stone. As for proprietary extensions, they are the most stable in IE. The IE8 change was the first since IE4 and it was primarily a security model change. Now we have NaCl on the horizon (ActiveX v2) and every vendor fighting their own extensions into the "standard" by buddying up for a new "standards" group. It's a minefield which throwing critical applications into is a bad move both from a logical and risk perspective. I'm not saying it lacks utility, but it's a risky proposition for a product that needs a defined lifecycle.
- Skinney 13y agoThe problem has been that IE contained alot of proprietary extensions, which were never a part of the standard. Since IE had most of the marketshare, people used IE, and thus things break when other browsers don't support the same extensions. Sites following standards should still work. While we have different parsers, they should all be supported today. NaCl is not a standard, and only works in Chrome, which I can't see changing. ActiveX is a proprietary IE extension, and will never work outside IE. Same with VB script, same with Dart etc. I had to port an application to IE7 last week, and it works fine in all browsers that has come out since. And this is a EmberJS app using ajax heavily. The web is a great place, as long as you stick to the standards and nothing but the standards. Luckily, the standards are evolving, meaning you can do more and more within the standards, without tying yourself to browser-specific extensions which was the problem in the early IE days.
- TheZenPsycho 13y agoThis is very confused thinking. I'm not sure where to start here. Browsers are really the most stable backwards compatible platform you'll find provided you: 1. stay away from proprietary extensions, applets, plugins, and what have you. 2. stay away from the new features that aren't standardised yet. The different parser models are there, and are STILL there. they will be there forever. Why? because DON'T BREAK THE WEB. "At best, most browsers these days estimate what they are doing, diving into some wierd mode full of edge cases purely by accident if you step on the wrong stone." Evidence or it didn't happen. "As for proprietary extensions, they are the most stable in IE. The IE8 change was the first since IE4 and it was primarily a security model change. " IE's proprietary extensions are the most stable, except they aren't, at all? Are you reading what you're writing before you send it? By popular demand IE has been forced to expunge the worst of it, and support standards. The ones that don't change every browser release. "Now we have NaCl on the horizon (ActiveX v2) and every vendor fighting their own extensions into the "standard" by buddying up for a new "standards" group." Well then don't use those. "It's a minefield which throwing critical applications into is a bad move both from a logical and risk perspective." It's only a minefield if you go into it with extremely misguided and confused thinking like you apparently have. There is a huge, rich, extremely stable platform here that you missed out on because you ironically are only interested in the whiz bang new shiny feeding frenzy going on. Just don't use those parts that are changing rapidly. they are easy to spot. Use the old parts that haven't changed since 2004. If they've been around for 10 years they'll be here for 10 more years.
- davb 13y agoI agree. We live in an unfortunate age of extreme technological instability. I think this is typified by the rolling updates we're seeing in many browsers, package-managed applications and operating systems. I do enjoy the new functionality continuous upgrades bring, but in general they usually result in breaking changes or disagreeable UX changes that users must endure in order to remain compatible with the ever-moving target of modern distributed/web applications. Some days I feel that I really am alone in the desire to see technology slow down, stabilise, become more predictable and be long-term (10+ year) dependable. The HN echo chamber of fast-moving cloud/social apps and flavour of the month programming languages feels like it can, in some ways, be harmful to our industry and its reputation. I don't mean this in a derogatory way, but it's easy to forget that 95% of the software out there needs the stability and long-term predictability that "modern", SaaS services just can't offer. I want my software to remain usable for more than three {browser version increments, Android versions, day job successors;}.
- robinwarren 13y ago"Unfortunately, the rate of change is incredibly large for Internet-facing applications. Intranet-facing applications are left behind. As browsers evolve, which they do rapidly, unpredictably and without compromise[1] a disparity grows until you need two browsers." This could be an argument for buying in cloud services (which you expect to be updated and maintained as technology evolves) rather than building solutions internally. Not always an option but where it is this seems like a good argument to buy rather than build, and if possible buy from a company which seems keen to move with the times and allow you to upgrade your browser in future without fear of breaking something
- csmithuk 13y agoYes and no. So far cloud services have proven themselves too risky for a lot of people as they suffer from availability problems (Azure), data retention problems (Atlassian data loss), security problems (NSA anyone?), churn and inconsistency (Google apps), data protection and regional law (Amazon S3). I could go on all day. This isn't really an option for a lot of people.
- nirvdrum 13y agoMy larger issue is that the UI gets tweaked constantly. To the point where the app you originally purchased and the one you're currently using may not longer resemble each other and there's nothing you can do about it when it's hosted.
- csmithuk 13y agoThis is a big problem - you are right. Users don't like things changing either. It ranges from a few minutes to adapt to throwing toys out of the pram and having to be retrained on something minor. This is an unfortunately reality.