With good PNG8+alpha quantization you can get compression in the same league as WebP (although WebP is still better) and basically 100% browser support (it degrades well in IE6).
Of course replacing Adobe lock-in with Apple lock-in would be dumb. HTML has 100% market share and CSS+JS are still ahead of Flash.
Jobs didn't block Flash on desktop, where Flash has high market share, so why quote that statistic? He refused to support it on mobile, where currently iOS has much higher market share than Flash.
> Because the bank is (presumably) chartered in the country you live in and heavily regulated, and you have recourse if they screw something up.
Indeed, Opera won't get trillion dollar bonus if they screw something up;)
Opera is publicly traded company regulated in civilised country. They're technologically very competent, which I can't say about my bank which has JavaScript-laden IE-optimized website in 640x480 popup window.
Apple forbids code interpreters other than Apple's own, BUT this is Opera Mini, not full Opera Mobile. Mini executes JavaScript server-side and only sends rendered result to the phone. There's likely no (turing-complete) interpreter on iPhone side, so it should be fine within terms of SDK.
Apple has already accepted number of WebKit-based browsers, so browsers in general aren't forbidden.
And for iPhone users, especially on EDGE, there is very good reason to use Opera Mini: it's going to be faster. iPhones before 3GS are also very low on RAM, and Safari only uses RAM for caching. Presumably Opera Mini would be able to keep many more tabs open and fully cached.
Remember that Opera proposed video element in the first place and they've chosen Theora from the start. They're not fond of patents, and may not want to choose H.264, especially if Mozilla doesn't.
> But how exactly do you go about doing unit tests of the front end of a web application?
Unit testing in PHP isn't different than in other languages. You split code into testable chunks and hammer them with PHPUnit.
> due to all the javascript stuff that lives on the browser these days.
How is that related to C++/PHP? And would you just run Facebook without unit tests? (good luck!)
Anyway, for JS there's Selenium and it can integrate with PHPUnit. UI testing is difficult, and browser-hosted tests are especially fragile and finicky, but that's not PHP's fault and C++ won't fix it.
If you have editor with auto-completion, misspellings are uncommon. Other kinds of errors are caught (and logged) as soon as faulty code is executed. With short edit-run cycle it's pretty quick.
It's not perfect, but OTOH C++ compiler won't tell you about all memory leaks, dangling pointers and buffer overflows at compile time.
C++ has runtime errors too, and you won't easily get logs with line numbers where your memory corruption happened.
Browsers' UI for HTTP authentication so far is absolutely awful, and there's no standard mechanism for logging out.
Although HTTP Digest authentication does offer slighly better security than cookies, HTTP authentication is helpless against any MITM attacks.
There have been proposals to give HTML forms front-end for HTTP authentication, but they haven't gone anywhere, since there is little to gain (same UI as cookie-based auth, negligible security improvement) and backwards compatibility is poor.
I agree that W3C's standards are often bent to appease their sponsors, but still you can't say that Microsoft didn't make things worse.
Even if CSS3 isn't perfect, that's still much much better than buggy CSS1-and-a-half that IE6-7 supports (notably lacking display:table-cell that at least gives basic vertical control).
The "messy" tags and features are non-conforming (AKA deprecated). They are in the spec only because they have to be documented somewhere for browser creators. If you wrote browser that doesn't support <font> & co., even google.com wouldn't render properly (try gaining market share with such browser).
DHTML is CPU intensive (mostly due to inefficiency of JS+DOM+CSS reflows).
Simple DB-lookup auto-completion sucks. If you have a lot of power to spare, you can do realtime static analysis of the code and e.g. use syntax highlighting to show dead code or use of uninitialized variables immediately, or have more useful auto-completion in languages with weak/dynamic typing.
Even video editing was around and quite usable back in 1993.
Not on "consumer" hardware. In 1993 on Amiga I could barely make short, low-resolution animations (and with help of dedicated hardware mix them with analog video input).
Even today I would like to have a few more cores to export H.264 video.
are you saying it's too hard for a programmer to have a freakin' integer variable that called (say) CurrentSubqueue
Yes. Simpler code has less opportunities for bugs. If you have 500 places where you have to use such variable and use it only in 499, you've got a bug.
"Hello World" is trivial. In everything else you need to care about reducing complexity and preventing errors to avoid ending up with unmaintainable buggy code.
You're suggesting it's easier to get accurate and meaningful data about three people when they're all randomly pulling movies from the same queue
No, I had in mind that it might be easier to get data about an account when it's always an account, not account-or-three.
* Sales department wants to see higher bars on 'accounts sold' chart
* Reduced code complexity - get rid of cases where code has to look for sub-accounts within account. When you forget that account sometimes is 1 account, sometimes many accounts, bugs creep in. It must be awful for reporting and data mining.
Slashdot Mirror
The original pngquant was quite bad indeed (it did support alpha, but poorly). It had lots quality trade-offs for MS-DOS era machines.
The modern rewrite is much better in terms of quality and it's especially tuned for good alpha channel support.
You don't have to save full 32-bit PNG. 8-bit PNG supports full alpha as well -- in all applications except Photoshop.
See http://pngmini.com/ or https://github.com/pornel/improved-pngquant
I'm working on it -- or rather squeezing every last drop of the existing format.
http://pngmini.com/vs-webp/
With good PNG8+alpha quantization you can get compression in the same league as WebP (although WebP is still better) and basically 100% browser support (it degrades well in IE6).
Cut out the middlemen and give it directly to recording industry lobbyists.
Of course replacing Adobe lock-in with Apple lock-in would be dumb. HTML has 100% market share and CSS+JS are still ahead of Flash.
Jobs didn't block Flash on desktop, where Flash has high market share, so why quote that statistic? He refused to support it on mobile, where currently iOS has much higher market share than Flash.
> Because the bank is (presumably) chartered in the country you live in and heavily regulated, and you have recourse if they screw something up.
Indeed, Opera won't get trillion dollar bonus if they screw something up ;)
Opera is publicly traded company regulated in civilised country. They're technologically very competent, which I can't say about my bank which has JavaScript-laden IE-optimized website in 640x480 popup window.
It could be accepted.
Apple forbids code interpreters other than Apple's own, BUT this is Opera Mini, not full Opera Mobile. Mini executes JavaScript server-side and only sends rendered result to the phone. There's likely no (turing-complete) interpreter on iPhone side, so it should be fine within terms of SDK.
Apple has already accepted number of WebKit-based browsers, so browsers in general aren't forbidden.
And for iPhone users, especially on EDGE, there is very good reason to use Opera Mini: it's going to be faster. iPhones before 3GS are also very low on RAM, and Safari only uses RAM for caching. Presumably Opera Mini would be able to keep many more tabs open and fully cached.
It is patented, and in exactly the same way as h264 will form a toll both on the internet
All known Theora patents have royalty-free license. Only thing that is "exactly same way" here is risk of submarine patents.
Remember that Opera proposed video element in the first place and they've chosen Theora from the start. They're not fond of patents, and may not want to choose H.264, especially if Mozilla doesn't.
> But how exactly do you go about doing unit tests of the front end of a web application?
Unit testing in PHP isn't different than in other languages. You split code into testable chunks and hammer them with PHPUnit.
> due to all the javascript stuff that lives on the browser these days.
How is that related to C++/PHP? And would you just run Facebook without unit tests? (good luck!)
Anyway, for JS there's Selenium and it can integrate with PHPUnit. UI testing is difficult, and browser-hosted tests are especially fragile and finicky, but that's not PHP's fault and C++ won't fix it.
> If there is so much PHP out there, why wouldn't/couldn't there be an efficient compiler
There is PHC and Roadsend.
However there are PHP-specific problems that make it harder than it should be.
PHP's "standard library" is heavily dependent on the interpreter, so you either lug it around and maintain its state, or rewrite 5000 methods.
And there's of course eval(), extract(), dynamic include/autoload and other magic that makes static analysis pretty hard or impossible.
Developers that are diligent enough to make only 1 memory-related bug/year can certainly spell variable names correctly.
If you have statically typed language, you rely on types. If you have dynamic, you rely on unit tests. Both are probably equally slow :)
This is not a problem in PHP.
If you have editor with auto-completion, misspellings are uncommon. Other kinds of errors are caught (and logged) as soon as faulty code is executed. With short edit-run cycle it's pretty quick.
It's not perfect, but OTOH C++ compiler won't tell you about all memory leaks, dangling pointers and buffer overflows at compile time.
C++ has runtime errors too, and you won't easily get logs with line numbers where your memory corruption happened.
They have 20 million Opera Mini users, 40 million desktop users, and very few desktop users will use Turbo.
That would be counter-productive and would drive away customers from an already troubled industry.
That argument never stopped RIAA and MPAA before.
It has been discussed recently on HTML5 WG.
Browsers' UI for HTTP authentication so far is absolutely awful, and there's no standard mechanism for logging out.
Although HTTP Digest authentication does offer slighly better security than cookies, HTTP authentication is helpless against any MITM attacks.
There have been proposals to give HTML forms front-end for HTTP authentication, but they haven't gone anywhere, since there is little to gain (same UI as cookie-based auth, negligible security improvement) and backwards compatibility is poor.
That's exactly what Sblam! does.
It's PHP-based filter for web forms that detects spam based on content (bayesian filter + specific rules), behavior and uses 3rd party blacklists.
It's absolutely transparent to the user (well, 99.8% of them).
I guess Gravatar.com will now have to ecourage proxying of avatars via sites' web servers.
Indeed it isn't DRM.
But why Microsoft is pushing it as a solution that protects web foundries' interests!? It makes no sense. It this regard it's no better than TTF.
And you could remove characters from TTF too.
I agree that W3C's standards are often bent to appease their sponsors, but still you can't say that Microsoft didn't make things worse.
Even if CSS3 isn't perfect, that's still much much better than buggy CSS1-and-a-half that IE6-7 supports (notably lacking display:table-cell that at least gives basic vertical control).
The "messy" tags and features are non-conforming (AKA deprecated). They are in the spec only because they have to be documented somewhere for browser creators. If you wrote browser that doesn't support <font> & co., even google.com wouldn't render properly (try gaining market share with such browser).
DHTML is CPU intensive (mostly due to inefficiency of JS+DOM+CSS reflows).
Simple DB-lookup auto-completion sucks. If you have a lot of power to spare, you can do realtime static analysis of the code and e.g. use syntax highlighting to show dead code or use of uninitialized variables immediately, or have more useful auto-completion in languages with weak/dynamic typing.
Not on "consumer" hardware. In 1993 on Amiga I could barely make short, low-resolution animations (and with help of dedicated hardware mix them with analog video input).
Even today I would like to have a few more cores to export H.264 video.
It's OK on Intel Macs, but absolutely crappy on PowerPC (my guess is that they've hand-optimized critical stuff in x86 asm only).
* Sales department wants to see higher bars on 'accounts sold' chart
* Reduced code complexity - get rid of cases where code has to look for sub-accounts within account. When you forget that account sometimes is 1 account, sometimes many accounts, bugs creep in. It must be awful for reporting and data mining.