HTML5에 관한 11가지 냉혹한 진실
11 Hard truths about HTML5
HTML5 heralds some nifty new features and the potential for sparking a Web programming paradigm shift, and as everyone who has read the tech press knows, there is nothing like HTML5 for fixing the Internet. Sprinkle some HTML5 into your code, and your websites will be faster and fancier -- it'll make your teeth white, too. But the reality of what HTML5 can do for those seeking native-app performance on the Web falls short of the hype.
After several years of enjoying HTML5's sophisticated new tags and APIs, the time is ripe to admit that there are serious limitations with the model. Not only are there reasons to grouse about HTML5 failing to fulfill our Web nirvana dreams, there are even reasons to steer away from HTML5 in some cases.
[ Find out which 10 apps are pushing HTML5 to the limit. | Also on InfoWorld: "HTML5 in the browser: Canvas, video, audio, and graphics" | "HTML5 in the browser: Local data storage | "HTML5 in the browser: HTML5 data communications" | "HTML5 in the browser: HTML5 forms" | "HTML in the browser: Geolocation, JavaScript, and HTML5 extras" ]
The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem. Its additional features are compelling and will help make Web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchonization challenges, and politics should have us all scaling back our expectations for the spec. After all, every technology has its limitations.
What follows is a list of 11 hard truths Web developers must accept in making the most of HTML5.
HTML5 hard truth No. 1: Security is a nightmare
The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of Web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.
With a JavaScript debugger like Firebug, anyone who is curious about what Facebook, Google, or any other website is doing can just start inserting breakpoints and watch the code. This is great for debugging and learning how websites operate, but it's a nightmare for security.
Suppose there's a variable that holds a value you'd like to change; well, Firebug or any of the other browser debuggers is happy to help you tweak the data to be anything you desire. Do you want to trick your friends into thinking you're in another geographic location? It's easy to edit the variables that hold latitude and longitude to place your browser anywhere in the world. All the neat features of your Web app can be modified, and the browser environment makes it easier than it would be normally with native code.
There are limits to the security problems that can be incurred. Some JavaScript tools such as Google Web Toolkit are nearly as complicated as standard compilers. Their output can be fairly inscrutible. Luckily tools like the JavaScript Deminifier can help.
The danger depends, of course, on the nature of the application. It's one thing when someone edits their latitude and longitude to play tricks on their friends by checking into a website while pretending to be halfway around the world. The trouble begins when someone qualifies for all of the rights, privileges, and free beers accorded by being crowned the mayor of some location. When money gets involved, the games can only get worse. All of this means that client-based HTML5 apps can't be trusted with serious data collection, and it's better for everyone to be aware of their capabilities.
HTML5 hard truth No. 2: Local data storage is limited
The local databases buried in your browser are one of the neater features that make it simpler for Web apps to cache data on your computer. But for anyone hoping to offer desktoplike data functionality in the browser, these databases can save bandwidth and improve performance. However, they won't give users the same power over their data that they're used to enjoying with desktop apps.
HTML5 data storage capabilities are certainly an important addition, but you still can't move stored data to another machine, make copies, back it up, or open it with a different app. It's all buried deep where the browser hides it.
In a sense, these databases are the worst of both worlds. You get all of the responsibility for hosting the database but none of the control.
Some of the latest browsers allow you to see which databases have been created on your machine, but this information is limited. Safari even lets you delete the database. But you can't browse the information or move it to another machine. The files aren't designed to move easily, although you can do it if you know where to look.
Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They're not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.
HTML5 hard truth No. 3: Local data can be manipulated
The user may not have control over the data, but the central website is also hampered when dealing with client data. Did the user switch browsers? Did the user switch machines? Many Web developers just toss up their hands and use the local data storage for caching short-term content. They can't let the user create much because of the problems of synchronization.
Web developers also need to worry about the security of the local database. While there are no tools that make it easy for a user to edit the local data and upgrade their privileges, there's no way for the central server to prevent it. All of the security holes introduced by letting the user tweak the JavaScript code affect the databases, too. They're wide open and waiting for someone to write a Greasemonkey script or some native code to change the data.
HTML5 hard truth No. 4: Offline apps are a nightmare to sync
HTML5 local data storage is vastly improving the ability to use Web apps offline. The only trouble is data synchronization.
If a Web app is connected to the Internet, it can continually save data to the cloud. When it's offline, changes aren't always stored in the cloud. When someone switches browsers or uses a different machine, copies begin to proliferate and the difficulties of synchronization rear their head. To make matters worse, clocks themselves may be unsynchronized, making them unreliable for finding the latest saved data.
Of course, this has always been a problem with native apps, but the difference is that the native model makes it obvious who is responsible for synchronization: humans, who manage synchronization troubles by looking at file names and change dates. But because HTML5 doesn't give users control over the databases stored deep inside their browsers, developers must provide the user interface and piping to handle synchronization. The specification doesn't offer any help.
This isn't a completely intractable mess. Programmers manage these headaches by using version control systems, which have become increasingly more sophisticated to handle such problems. Yet just having the technology doesn't mean it's an easy solution for programmers to use. Merging the various GIT repositories can take time. HTML5 developers will need to master these issues if they're going to manage the synchronization of HTML5 Web apps.
HTML5 hard truth No. 5: The cloud owes you nothing
It's not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, which leverages the cloud to fix all of the headaches for installing software and backing up data.
Given the limitations of HTML5 local data storage, the bulk of Web app data storage will remain in the hands of servers, and there are moments when this approach can be devastating. Just recently Facebook decided it didn't like one Linux-based plug-in for uploading photos. With a wave of the caliph's hand, the plug-in was gone, along with all of the photos that were uploaded using it.
These stories aren't common, but they're appearing more and more often for many reasons. Are you sure that the cute Web startup promising free everything with their HTML5 app is going to be there in a few years or even a few months? You'd better be.
It gets worse. As the terms of service for many Web apps make clear, it's not your data, and in most cases, you have no legal recourse to recover the data. Some of the more outrageous service agreements insist that the data can even be deleted for "no reason at all."
Not only does HTML5 avoid fixing this issue in any way, its structure practically ensures that any of the local data cached on your browser will be stored in the cloud, out of your reach and control. The HTML5 hype says this is a feature, but it could easily turn against the model.
HTML5 hard truth No. 6: Forced upgrades aren't for everyone
One story, perhaps apocryphal, tells of a person who used a Gmail account for casual hookups with people in bars. When Google+ came along, all of the memories came flooding back, because Google+ linked those old addresses into the discussion forums. Every day, the old names and old faces are there asking to be put into discussion circles.
When the Web app companies need to upgrade, they must upgrade everyone at the same time. While this is said to relieve users of having to manage the software installation, it can be a nightmare for anyone who doesn't want the new features. This isn't just a problem for people's privacy, as in the case above. New software can often crash other packages that relied on the old features being where they were supposed to be.
HTML5 hard truth No. 7: Web Workers offer no prioritization
Web Workers are among the more intriguing additions to HTML5. Rather than depend on copious JavaScript wait, delay, and pause commands, Web developers can now split apart their code and segregate the CPU hogs into Web Workers. In other words, HTML5 Web Workers make the browser operate more like an OS.
Alas, they do not duplicate all of the features of the OS. While they do provide a way to fork the workload and separate it, there is no way to manage the workload effectively or set priorities. The API just allows messages to be passed into and out of Worker objects. That's all -- the browser handles the rest.
Will CPU-rich applications like code crackers sneak their way into the background running on popular websites? Will people begin luring users to cycle-stealing websites? Malware already piggybacks with useful software, so it's likely just a matter of time before this functionality is exploited. There is little users can do about it because they have no way to watch for the creation of Worker objects or track what they do. Their computer will just get slower after navigating to the targeted Web page.
HTML5 hard truth No. 8: Format incompatibilities abound
HTML5 heralds the introduction of <audio> and <video> tags, which at first blush look as easy to use as image tags. Just plop in a URL, and the browser streams the data. Yet, if it's so easy, why have I wasted two weeks trying to get basic audio files to play in all of the major browsers?
It's not really the HTML5 committee's fault that individual browser builders decided to implement some but not all of the various audio and video formats out there. People are human, and humans fight for dominance. But the developers have to deal with the fallout when a file that works perfectly well on one browser fails to do anything on another. How does one test for this? API developers were smart enough to include the function canPlayType, but even that function is not supported by all browsers.
HTML5 hard truth No. 9: Implementations are browser-dependent
The idyllic vision of HTML5 is one thing; the grungy reality of its implementations is another. True, programmers are trying their hardest to build the architects' dreams, but some of the tags and objects don't work correctly.
For instance, there are many things to like about HTML5's geolocation API. It offers some protection for privacy and a bit of control over its precision. If only it worked consistently -- one browser always times out, even though it should be smart enough to know that the desktop doesn't have a GPS chip.
Ultimately, this is more of a complaint about how browsers fail to implement the feature consistently, as opposed to being one aimed at the structure of the API itself. This hard truth highlights the browser-dependent challenges that Web developers face in making the HTML5-based Web app nirvana a reality.
HTML5 hard truth No. 10: Hardware idiosyncracies bring new challenges
It also seems unfair to complain about how some browser builders are going above and beyond the call of duty to provide much better performance, but no good deed goes unpunished. As the new Ferrari owner finds out after wrapping their car around a light pole, sometimes extra power isn't always a blessing.
Microsoft has done a great job of increasing the Canvas object performance of its IE browser by integrating it with low-level hardware drivers. The company has even commissioned neat games like pirateslovedaisies.com to show off the power.
But now programmers must pay attention to whether these additional features are available, and it's not clear how to find out how fast your code is running.
The game designers at pirateslovedaisies.com, for instance, included a switch to turn on and off the features that IE enables. Is there an API that makes it possible to guess about these features? Not really. The simplest thing is to test for the browser name and try to estimate the frame rate. Yes, I know that native game developers have been dealing with the wide range of available hardware for years and the only real solution is to ban innovation, but this is yet another wrinkle for Web developers to come to terms with.
HTML5 hard truth No. 11: Politics as usual
Some folks call Ian Hickson, the main drafter of the HTML5 standards, the Supreme Dictator for Life. They're joking, I guess, but the title doesn't match. The standard writer is just making suggestions, and the coding geniuses at the browser companies are the ones who make the real decisions. They may or may not choose to implement a feature, then the Web developers get to decide whether the results are stable. After a few years, the standards are often changed to match the implementation.
Many JavaScript developers have left the issue of compatibility to those who create the libraries, such as jQuery. These layers insulate us from the cross-browser differences. Will they be strong enough in the future to smooth over the differences? Only time will tell.
This issue highlights the fundamental problem for the field. We want the freedom, creativity, and cornucopia of features that come from pitting many browser companies against each other in a tough competition. The pace of innovation is great, but it creates even more differences, as the browser developers rush to add new features to gain an edge.
But we also want the stability that comes from putting one central dictator in control of the platform. Alas, the world has never found an ideal solution for the battle between authoritarianism and democracy. Instead of grousing too much about the headaches that come from the differences, we might want to adopt the attitude of Winston Churchill, who told the House of Commons, "Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time."
===========================================================================
-번역본-
Infoworld의 기고가 Peter Wayner가 밝히고 있는 HTML5의 11가지 문제점을 간단히 번역해 본다.
HTML5에 몇가지 강력한 기능들이 추가됨에 따라 웹프로그래밍의 페러다임이 변화할 것이라는 호들갑에도
불구하고 실제로는 Web상에서 Native-App의 퍼포먼스를 아직 따라가지 못하고 있다. HTML5의 강력한
성능에도 불구하고 그것이 모든 문제를 해결할 수는 없다. HTML5에 추가된 매력적인 기능들로 인해
Web App이 Native App의 강력한 경쟁자로 부상하고 있으나, 보안문제, Local Data Storage의 한계,
동기화 문제, 브라우저 벤더간 정치싸움으로 우리의 기대에는 한참 미치지 못하고 있다.
1. Security is Nightmare ( 보안에 취약 )
클라이언트 사이드 컴퓨팅의 근본적인 문제는 User가 궁극적으로 머신에서 동작하는 Code를 통제할 수 있다는 점이다. Web App의 경우 당신의 브라우저는 뛰어난 디버깅 툴이 될수 있으며, 이는 곧 코드를 악용하기 쉬워짐을 뜻한다.
Firebug와 같은 Javascript Debugger를 사용하면 Facebook이나 Google같은 사이트가 어떻게 동작하는지 알고 싶은 사람은 누구든지 Breakpoint들을 삽입해 넣고 코드를 볼 수 있다. 이로 인해 웹사이트의 디버깅과 동작방식을 쉽게 이해할 수 있게 되지만 "보안"의 관점에서는 너무 나도 취약하다.
Firebug를 비롯하여 브라우저 디버깅 툴을 사용하면 특정 변수의 값을 당신이 원하는 대로 조작할 수 있다. 즉 당신의 브라우저가 지구상에 위치해 있는 위도와 경도값 등 위치 변수를 쉽게 편집해서 친구들에게 당신의 위치를 속일 수 있다. Web App이 제공하는 모든 기능들 역시 수정이 가능하다는 말이다.
Web 환경은 정상적인 Native Code에서 보다 훨씬 더 쉽게 조작이 가능하다.
보안문제가 발생되는 경우에는 한계가 있다. Google Web Tool Kit이나 JavaScript Tool같은 툴은 표준 컴파일러 만큼이나 복잡하고, 이러한 툴들의 아웃풋은 측정하기가 어렵다. 그러나 다행스럽게도 JavaScript Deminifer같은 툴을 사용하면 보완이 가능하다.
물론 보안상의 위험은 어플리케이션의 본성에 달려있다. 당신은 위도와 경도값을 편집해서 친구들에게 당신이
지구의 반대편에서 체크인한 것처럼 보이게 만들 수 있다. 만약 누군가 우치 조작에 의해 특정 장소의 최고 권한을 취득하고 이것이 돈과 관련이 된다면 게임은 훨신 더 복잡해 진다.
이러한 이유로 중요한 데이터 수집을 위해 Client Based HTML5 App 들을 신뢰하기는 어렵다.
2. Local Data Storage is Limited ( 로컬 데이터 스토리지는 한계가 있다 )
당신의 브라우저에 심어져 동작하는 로컬 데이터 베이스는 HTML5의 가장 똑똑한 기능들중에 하나인데, 이것을 사용하면 Web App으로 당신의 컴퓨터에 데이터를 쉽게 캐싱할 수 있게 된다. 누군가 브라우저에서
Desktop과 유사한 기능성을 기대한다면, Local Database를 사용함으로써 Bandwidth를 절약하고 퍼포먼스를 개선할 수 있다.
그러나 Desktop App 과 달리 User들은 브라우저의 Local Database에 캐싱된 데이터를 거의 통제하기 어렵다. HTML5 Data Storage 성능은 매우 중요한 추가사항임에는 분명하지만
1) 저장된 데이터를 다른 머신으로 옴기거나
2) 데이터를 카피하거나
3) 데이터를 백업해 놓거나
4) 다른 App에서 접근할 수 없다.
이 데이터는 브라우저가 감추어 놓은 곳에 깊숙하게 심어져 있다. User는 데이터를 호스팅하는 책임만 있고,
그것을 컨트롤 할 수 없다는 점에서 최악이라고 할 수 있다.
최근의 몇몇 브라우저들은 어떤 데이터베이스가 당신의 머신에서 생성되어 있는지를 볼 수 있게 하고 있으나,
이 정보들은 매우 제한적이다. 사파리를 사용하면 이 데이터베이스를 삭제할 수 있으나, 이 정보를 브라우징
하거나 다른 머신으로 옮길 수는 없다. User가 어디를 보아야 하는지 인지한 상태에서 이것을 옮기려 시도한다 해도 파일들은 쉽게 옮길 수 없도록 설계되어 있다.
User들은 파일들을 분석해서 무엇이 저장되어 있는지 찾아낸다 하더라도 볼 수는 없다. 물론 프로그래머들은
그것을 분리해 낼 수 있으나 이것조차도 포멧을 먼저 공부하거나, 해킹한 후에야 가능하다.
Desktop App과 달리 Local Storage에 저장된 데이터는 스프레스시트나 텍스트문서 처럼 쉽게 어떤 에디터로든 열람할 수가 없다.
3. Local Data is Manipulated (로컬 데이터는 조작되어질 수 있다)
User는 데이터에 대한 통제력이 없지만, 중앙의 웹사이트 역시 클라이언트 데이터를 처리하기 어렵기는 마찬가지다. 만약에 User가 브라우저나 머신을 변경한다면 어떻게 될까?
많은 웹 개발자들은 이 문제에 손을 들고 단기적인 컨텐츠만을 캐싱하기 위해 Local data storage를 사용한다.
개발자들은 동기화문제 때문에 User들이 많은 컨텐트를 생산하지 못하도록 꼼수를 쓴다. 웹개발자들은 Local
Database의 보안에도 신경을 써야한다. 적잘한 툴이 없기 때문에 User들이 Local data를 편집하거나 권한을
업그레이드하기는 어렵지만, 중앙 서버가 데이터 조작 자체를 방지할 방법은 없다.
User에게 Javascript를 변경할 수 있도록 허용함에 따라 데이터베이스 자체가 변경될 수 있는 보안의 치명적
약점도 존재한다. Local data는 폭넓게 개방되어 있기 때문에 누구든지 Grassmonky 스크립트나 Nativecode를 짜서 데이터를 변경할 수 있다.
4. Offline Apps Are Nightmare to Sync ( Offline 앱은 동기화에 취약하다 )
HTML5 Local Data Storage로 인해 Web App을 오프라인 상태에서 쓸 수 있게 되었다. 여기에서 유일한 문제는 Data Synchronization이다. 만약 Web App이 인터넷에 연결되어 있다면, 계속해서 데이터를 클라우드에 저장 할 수 있다. 그러나 오프라인인 경우 변화가 항상 클라우드에 저장되지는 않는다.
만약 누군가 브라우저를 변경하거나 다른 머신을 사용한다면, 복사본이 증식되어 데이터 동기화가 어려워 진다. 만약 시계가 불일치할 경우 가장 최근에 저장된 데이터가 무엇인지를 판단하기 어렵기 때문에 문제가 더욱
심각해진다. 물론 이러한 문제는 Native App에서도 언제나 발생하지만, 데이터 동기화의 책임 주체가 누구인지가 명확하다. 즉 사람이 파일이름과 날짜를 보고 Synchronization 문제를 해결할 수 있다.
그러나 HTML5는 브라우저 깊숙이 저장되어 있는 Database에 대한 통제권한을 User에게 허용하지 않기 때문에 개발자들은 동기화를 핸들링할 수 있는 User Interface를 제공해야만 한다. 이것은 완전히 통제할 수 없는 문제는 아니다. 프로그래머들은 Version Control System을 사용하여 이 골칫거리를 관리하고자 한다.
이러한 문제를 해결하기 위해 버전 관린 시스템은 더욱 정교해지고 있다. 그러나 기술이 존재한다고 해서 그것이 개발자들이 쉽게 사용할 수 있는 솔루션이라는 의미는 아니다. 다양한 GIT 저장소를 머징하는데는 시간이 필요하다. HTML5 Web App의 동기화를 관리하고자 한다면 HTML5 개발자들은 이러한 이슈들을 마스터해야만 한다.
5. The Cloud owes you nothing ( 클라우드가지고는 아무것도 소유할수 없다 )
데이터를 클라우드에 저장할때 구조적인 문제가 발생한다고 해서 HTML5를 비난하는 것은 온당치 않으나,
클라우드는 HTML5가 꿈꾸는 비전의 근본적인 부분이다. HTML5는 클라이언트 소프트웨어의 설치 및 데이터 백업 등 모든 골칫거리를 해결하기 위해 클라우드를 적극 활용하고 있다.
HTML5 Local data Storage의 한계가 존재하는 상황에서 대용량 Storage가 필요한 Web App Data를 서버에 맡기는 방식으로 접근할 경우 이는 치명적일 수 있다.
최근에 Facebook은 사진을 업로드 하는데 사용했던 Linux기반 의 플러그인을 제거하기로 결정했다. 최고 전문가들의 면밀한 검토가 있은 후 플러그인은 제거되었으나, 이 플러그인을 사용하여 업로드된 모든 사진들도 함께 사라졌다. 이러한 사례는 일반적이진 않으나 어떤 이유로든 점점 더 자주 발생하고 있다.
HTML5 App으로 모든 것을 무료로 제공하겠다고 약속하는 소규모 Web 선두주자들에게 이런 문제가 몇 달 또는 몇년 후에 발생할까? 아마도 이렇게 생각하는 편이 나을것이다. 이 문제는 점점 더 악화되고 있다.
많은 Web App들이 이용약관에서 명확히 하고 있듯이, 데이터는 User들의 것이 아니다. 오히려 대부분의 경우
User들에게는 데이터의 복구를 요청할 수 있는 법적 수단이 존재하지 않는다. 심지어 데이터가 아무런 이유없이 삭제될 수 있다는 것을 강제하는 보다 뻔뻔스러운 이용약관도 존재한다.
HTML5는 어떤 방식으로든 이 문제의 해결을 회피할 뿐만 아니라 구조적으로 당신의 브라우저에 캐싱되어 있는 모든 Local data는 클라우드에 저장되도록 되어 있기 때문에 User들은 이것에 접근할 수도 없고 통제할 수도 없다. HTML5 예찬론자들은 이것을 기능이라고 부르고 있으나 오히려 자신의 모델과 상충되기 쉽다.
6. Forced Upgrades aren't for everyone ( 강제 업그레이드는 모든이들이 원하는 것은 아니다 )
어떤 사람이 바에서 만난 사람들과의 Casual Relationship을 위해 가끔씩 Gmail로 연락을 주고 받곤 했는데,
Google+ 출시 후에 이런 사람들과의 오래된 기억들이 홍수처럼 밀려오는 경험을 한 적이 있다.
Google+는 이런 낡은 주소들을 Discussion Forum에 연결시키기 때문이다. 매일 오래전에 잊혀진 사람들의 이름과 얼굴이 나타나 토론 사회로 들어올것을 요청한다.
(User 가 원치않는 방식으로 웹 업데이트가 이루어지는 것을 뜻함)
Web App을 업그레이드할 필요가 있을 때, 그것은 모든 사람에게 동시에 적용되어야 한다. Web App을 사용하면 User들이 소프트웨어를 굳이 인스톨할 필요가 없지만 새로 추가된 기능을 원하지 않는 User들에게 이것은 원치 않는 선택일 수 있다. 새로운 소프트웨어는 이전의 기능들에 의존하는 다른 패키지들과 충돌을 일으킬 수도 있다.
7. Web Workers offer no prioritization ( Web Workers는 우선순위를 제공하지 않는다 )
Web Workers : HTML5의 API중 하나. 백그라운드에서 자바스크립트를 실행하기위한 API
백그라운드에서 실행한다는 것은 Document를 배제하고 독립적으로 자바스크립트 코드만
실행하는 것을 의미하며, 이를 워커(Workers)라 칭한다.
일반 프로그래머들은 Web Workers == Thread 라고 생각하면 되겠다.
Web Workers는 HTML5에 추가된 좀더 매력적인 기능이다.
Web 개발자들은 묵직한 Javascript의 wait, delay, pause commands에 의존하기 보다는 코드들을 쪼개고 CPU 점유율을 Web Workers로 분리시킬 수 있게 되었다. 다시 말해 HTML5 Web Workers로 인해 브라우저가 보다 OS처럼 동작할 수 있게 되었다.
그러나 불행하게도 Web Workers는 OS의 모든 기능을 복제해서 가지고 잇지는 않다. Web Workers는 워크로드를 Fork 하고 분리해서 처리할 수 잇는 방식을 제공하고 있기는 하지만, 워크로드를 효과적으로 관리하거나 우선순위를 정하는 방법은 전혀 없다. API를 사용하면 메세지를 Worker Object로 입력하거나 출력해줄 뿐이다. 이것이 전부이다. 나머지는 브라우저가 알아서 처리해야 한다.
만약 CPU의 자원을 많이 잡아먹는 code-cracker와 같은 어플리케이션이 인기 웹사이트의 백그라운드에서 몰래 동작한다면 어떻게 될까? User들이 웹사이트의 Cycle-Stealing도 할 수 있지 않을까? 악성코드는 이미 유용한 소프트웨어에 기생하고 있기 때문에, Web Worker의 기능적 약점이 악용되는 것은 시간 문제이다.
Worker Object가 생성되거나 그것이 무엇을 하는지 트랙킹 할 수 없기 때문에 User들을 이러한 악성코드에 대해 아무것도 할 수 없다. 그저 악성코드의 공격대상인 특정 웹페이지에 접속한 후 그들의 컴퓨터가 느려지는 현상을 경험할 뿐이다.
8. Format incompatibilities abound ( 중구난방적인 Format Type의 불일치 )
HTML5는 <audio> <video> 태그를 도입, 이미지 태그처럼 쉽게 사용할 수 있고 브라우저가 데이터를 스트림해 주게 될 것이라고 자랑해 왔다. 그러나 이것이 그렇게 쉽다면 왜 내가 모든 메이저 브라우저에서 동작하는 기본 오디오 파일을 찾는데 2주나 소모 했을까? 이것은 HTML5의 잘못이라기 보다는 브라우저 개발자들이 모든 오디오, 비디오 포멧을 지원하지 않기로 결정했기 때문이다.
사람들은 인간이고, 인간은 지배를 위해 싸운다. 그러나 개발자들은 어떤 브라우저에서 완벽하게 동작하는 파일이 다른 브라우저에서는 동작하지 않을 때 이 문제를 다루어야만 한다. 이것을 어떻게 테스트 할까? API 개발자들은 canPlayType이라는 함수를 개발할 정도로 충분히 스마트 했지만, 이것조차도 모든 브라우저가 지원하는 것은 아니다.
9. Implementations are browser-dependent ( 브라우저에 종속적인 개발방식 )
HTML5가 꿈꾸는 이상은 그것을 구현해야하는 지저분한 현실과는 큰 차이가 존재한다. 프로그래머들은 최선을 다해 구조적 꿈을 실현하고자 하나 어떤 태그와 오브젝트들은 잘 동작하지 않는다. 예를 들어 HTML5의
Geo Location API와 같이 작동하지 않는 것들이 많이 있다. Geo Location API는 Privacy 보호와 정확성에 대한 통제수단을 제공한다. 이것이 지속적으로 잘 동작할 때 조차도 어떤 브라우저에서는 타임아웃이 걸린다.
심지어 Desktop에서는 GPS가 존재하지 않다는 것을 알고 있을 때 조차도 그렇다.
궁극적으로 이것은 API 자체의 구조적 문제에 대한 불만이라기 보다는 브라우저가 특정 기능이 일관성있게
동작하도록 지원하지 못하고 있다는 사실에 대한 불만이다. 웹 개발자들이 HTML5 기반 Web App의 이상을
현실로 만들고자 할 때, 브라우저 의존적인 문제점들에 직면하게 된다는 것이 냉혹한 진실이다.
10. Hardware idio syncracies bring new challenges ( 하드웨어 성능을 관리하기 어렵다 )
몇몇 브라우저 개발자들이 성능 개선을 위해 원래 스펙 이상을 구현했거나 덜 구현했다고 해서 불평하는 것은 불공평하지만, 아무리 좋게 개선했다 하더라도 부작용이 다르기 마련이다.
MS는 low-level의 Hardware driver들과 그것을 통합시킴으로서 IE 브라우저의
Canvas Object의 Performance를 개선하는 위대한 일을 했다. MS는 이것을 과시하기 위해 pirateslovedaisies.com과 같은 게임들을 지원하기도 했다.
이제 프로그래머들은 이러한 새로운 기능을 사용할 수 있는지의 여부에 대해 면밀히 살펴 보아야 하겠지만 우리가 짠 코드가 얼마나 빨리 동작하는지를 확인할 방법이 명확하지 않다. 예를들어 pirateslovedaisies.com의 디자이너들은 IE가 제공하는 기능들을 킬지 끌지를 스위치로 선택할 수 있게 만들었다. 이러한 추가기능들을 짐작해서 사용할 수 있는 API가 현실적으로 존재하지 않는다. 가장 간단한 방법은 브라우저 네임별로 테스트를 진행하고 Frame Rate를 측정하는 것이다. 나는 많은 Native Game 개발자들이 수년동안 폭넓은 범위의 하드웨어를 다루어 온 것을 잘 알고 있다. 여기서 유일한 솔루션은 혁신을 금지하는 것이지만 그렇게 된다 하더라도 웹 개발자들은 이런 상황에서 적응해야만 할 것이다.
11. Politics as usual ( 정치가 판을 친다 )
어떤 사람들은 Ian Hickson이 HTML5 표준의 창시자 라고 부르지만, 이것은 농담에 불과하다.
Standard Writer들은 제안을 할 뿐이고, 실질적인 결정은 브라우저 회사의 코딩 천재들이 내린다. 그들이 어떤 기능을 구현할지 구현하지 말지 선택하면 웹 개발자들은 결과가 안정적인지 결정을 내린다. 그리고 몇년 후
표준 자체가 구현된 결과에 맞게 변경되는 일도 종종 발생한다.
많은 Javascript 개발자들은 호환성의 문제를 jQuery와 같은 라이브러리를 생성한 사람들에게 떠 넘긴다. 이런
Layer들로 인해 우리는 브라우저간 차이 에 대해 크게 개의치 않고 지나가지만 , 이러한 차이가 미래에도 별 문제가 안될지에 대해서는 지켜봐야 할 것이다.
이러한 이슈들은 브라우저 업계의 근본적인 문제이다. 우리같은 웹 개발자들은 브라우저간 치열한 생존경쟁의 결과로 탄생하는 풍요로운 기능과 자유, 창의성을 원한다. 브라우저 개발자들이 앞서 나가기 위해 앞 다투어 새로운 기능들을 개발함에 다라 혁신의 속도가 빨라지고 있으나, 대신 브라우저간 차이가 점점 더 커지고 있다.
그러나 우리는 중간에서 플랫폼을 통제하는 독재자가 제공하는 안정성도 원한다. 세계는 권위중의와 민주주의 전쟁을 해결하기 위한 이상적인 솔루션을 아직도 찾지 못하고 있다. 차이로 인해 발생하는 골칫거리에 대해 불평하기 보다는 하원(House of Commons)에서 다음과 같이 연설한 윈스턴 처칠의 태도를 취하는 것이 더 나을 것이다.
"실제로 사람들은 민주주의가 최악의 제도라고 말한다. 단, 이제껏 시도된 모든 정치제도를 제외하고."
- 윈스턴 처칠 -
대중이란 것은 감정적 소구에 약하고 어느 쪽으로든 깊은 생각과 성찰없이 휘둘리기 쉬운 존재인것 같다.
민주주의는 그러한 대중에의해 지배되는 체제이고 대중의 의사결정에 따라 굴러가는 정치체제 이다.
다수에 의한 선택과 지배, 어쩌면 가장 좋은 선택일 수도 있겠지만 어쩌만 가장 나쁜 선택일 수도 있다.
위의 글은 저자의 개인적인 생각이나 마인드가 많이 담겨 있는듯 하다. 같은 글을 읽어도 받아들이는 사람에 대한 태도가 다르듯이, 각자 필요하거나 느끼는 바에 대한것에 참고했으면 좋겠다.
중요한 사실은 HTML5는 아직 발전중이라는 사실이다.
'Data' 카테고리의 다른 글
| Node.js ??? (0) | 2012.05.21 |
|---|---|
| About Local storage in HTML5 (0) | 2012.03.29 |
| Mobile Web _ HTML5 Performance Optimization (0) | 2012.03.14 |
| How to Browsers Work..!!! (0) | 2012.03.05 |
| Webkit (0) | 2012.03.05 |