|
Oh f*** yes, chuck the whole web stack and start again, do it right, machines are fast enough to render as you design (well almost). Give the poor bloody users a decent UI and the developers something that make a modicum of sense.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I have a different set of opinion. Although, I completely understand the pain as I am also going through the same as yours.
1. Let's keep HTML the same and work on better GZip/compression system while transfer via network.
2. W3C should force browsers to implement the standard.
3. Human readable HTML is good because it helped much while debugging via. Developer Tools, Fiddler, etc. It also helps to understand the request and response quite easily.
I think of 2 solutions:
We should have only ONE widely accepted browser for all purpose.
OR
all browsers should follow same W3C standards for HTML, CSS and JavaScript.
Life is a computer program and everyone is the programmer of his own life.
|
|
|
|
|
Anurag Gandhi wrote: Human readable HTML is good because it helped much while debugging via. Developer Tools, Fiddler, etc
So...you debug your C# (or VB) by looking at the native binary or IL code then? I use a specific tool for that which lets me produce the code at a high level and translate it to a more efficient low level for actual execution. I then debug it in the high level language and let the system sort out the low level for me.
Anurag Gandhi wrote: We should have only ONE widely accepted browser for all purpose
You want a monopoly? That doesn't help improvements: the poor quality of existsing browsers is what got us the much better ones we have today!
Anurag Gandhi wrote: all browsers should follow same W3C standards for HTML, CSS and JavaScript.
They do. Just they interpret it differently, because it isn't a "true" standard - it's an evolved, hacked, broken, extended mess that never intended to be what it has ended up as.
The only reason it was human readable at all was because it made it easy to write in a text editor!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: you debug your C# (or VB) by looking at the native binary or IL code then? I use a specific tool for that
Agreed, but debugging human readable code seems quite easier in client server architecture. I understand you are among the top developers, but I have seen people struggling even writing HTML. (I know thats a different story.  )
OriginalGriff wrote: You want a monopoly?
I really didn't mean that. I meant that all companies should use same open source browser and stop creating/continuing the crap versions of his own. Similar to JQuery which is widely accepted library for all companies/development organization. It might create a security breach but I am sure there should be a way to handle it.
OriginalGriff wrote: They do. Just they interpret it differently,
Agreed. But even some latest browsers have there specific CSS 3 code and they haven't implemented W3C yet.
Life is a computer program and everyone is the programmer of his own life.
|
|
|
|
|
Anurag Gandhi wrote: Agreed, but debugging human readable code seems quite easier in client server architecture
Why? Why not have a "debug browser" in the same way we have a "windows debugger"?
That way, the code is only visible to those who actually need it (and by preference have the source code handy as well) - security improves, execution speed improves, debug facilities improve, etc....
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
That's just polishing a turd.
Even Tim Berners-Lee had the decency to say that after he'd seen The Mother of All Demos (Doug Englebart) that he wished he was aware of it before starting to design HTML. It simply is not fit for purpose.
The browser should be more like an O/S, just give tasks an area to render into, and mediate all requests for services to ensure security. Ideally, like an O/S with a good object-capability model for security.
Nobody ever had any difficulties debugging GUIs in Smalltalk, and that was 30 years ago now. HTML was an enormous step in the wrong direction.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Would get my +5000, but only +5 is available... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
There's a good TED talk by Alan Kay (can't link yet - at work) in which he shows pictures of Einstein, Newton and Darwin to a room of programmers, who all recognise them, then shows them pictures of Englebart, John McCarthy (LISP), Jacob Goldman (Xerox PARC), Bob Barton (Invented bytecode at Burroughs) and other pioneers of computing, none of whom were recognised.
He summarised this situation as illustrating why computing isn't a science yet - nobody knows who these pioneers were, so are condemned not to learn from them. (You've probably guessed I'd include Alan Kay in my personal list).
Imagine a physicist who didn't know who Newton was.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
It's easy to change it now!
We can create a server that uses WCF net tcp (or even plain tcp socket) to handle requests. With Razor, we can compile exising asp.net mvc (cshtml) files on the server, get a string, perhaps use an in memory compressor, and then pass it to the client. We need a browser app on the client that can communicate over WCF, decompress and display in memory html.
With that in place, second version can start with sending objects to client instead of html or strings. Since objects have type, type-specific optimizations can be applied.
It's a cool project really! It can work with existing technologies. We just need to add few layers in between.
|
|
|
|
|
It may be cool, but all it's doing is adding further complication layers on top of an existing pile of steaming layers! 
If your car engine is smoking, you don't bolt an extra exhaust filter on the roof to remove the toxic stuff, you replace the piston rings or the valve stem seals to stop it burning the engine oil in the first place!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Agreed, version one I talked about above is that but version two isn't. Technically, there's a bit difference! I mean to use the good parts of exising technology. In your example, let's not throw away the entire car, but replace bad bad parts of the engine! :-P
|
|
|
|
|
Yes - but in this case the bad parts are HTML and Javascript!
To continue the car analogy, if you pull out the engine and find that it's not just the piston rings, but the bores, pistons, and big end bearings are made of chocolate, the cam is gold plated wood, the oil pump is missing, and there is a huge hole in the crankcase that has been covered with silver painted cardboard: then its time to get a whole new car!
And at the moment, that is what we have: a rotten core to the whole presentation system - HTML.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Never mind the fact that we would have just invented a browser and technology stack tied to a single platform/VM. Not exactly progress.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Why?
Is IL platform specific? Or does C# code work in Linux under Mono; on X86 or ARM processors?
The JIT compiles the IL to the native code, and if the browser was a "portable" OS shell (as it should be for security purposes) all that is needed is to produce the browser engine for Windows, iPhone, Android, etc. - just as they do with the Chrome core HTML/javascript engine, Mozilla, ...
(I'm not seriously suggesting IL as the solution, BTW - though C# on the client would be very nice.)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
IL isn't platform-specific, but I suspect strongly that elements of WCF are.
Regardless of that, adopting CLR as a VM in a browser would harm adoption on other platforms - if only due to resistance from developers.
I also don't think .NET, as it stands, is really up to the task. Unforgeable references are key to an object-capability system. I'd personally like to see non-nullable references too. Maybe something more like Rust (when its matured), but targeting bytecode. I strongly believe in managed languages, (in the general sense) for the protection they bring. There are limitations to the .NET/Java model, however, that could stifle innovation.
It's all pipe dreams anyway, but I do wish someone (hopefully more qualified than me), starts moving the Web away from its mistakes, instead of entrenching them further.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
At last . . . someone else who realizes that binaries are very specific critters.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Actually, .NET is quite portable. The issues I see are more political than practical.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Yes, it is progress. Potentially massive progress. I don't see how tying development to HTML and javascript is preferable to "avoiding" a standardised VM. You may be pleased that Google for example looked like it wanted to go down the VM route but there was no agreement and even dissent within their own ranks. We are stuck with HTML and brain-dead javascript.
|
|
|
|
|
OriginalGriff wrote: and we would stand a chance of getting "browser independence"
Oh Mighty One! Explain how binaries will help produce browser independence? I've always considered the opposite to be true.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I hope Griff doesn't mind me answering on his behalf, but bytecode has been around for decades now (first by Burroughs machines in the 1960s if my sources are correct), as have the concepts of VMs. Both of these could be used to achieve platform-independence.
I don't care about browser-independence - the whole HTML+CSS+JS stack disobeys all good principles of software engineering. Each component should do just one thing, and do it well.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
The little endians and big endians will not hear of it!
I noted your stack didn't include PHP. When I do webdev, it generally includes all four - and a bunch of SQL on the back end to keep all things in balance.
In some ways, I haven't had this much fun since I found out about inline assembly block for C.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Luckily, the back end is something entirely different - a variety of technologies are available there.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
"The little endians and big endians will not hear of it!"
As for Unicode, simply add a byte order mark.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
the IE and its design and "machine" are legacy code of Windows 95 stuff. On old legacy project trowing all in the trash can is the only solution, and make a new start. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I'm a web developer, and as most (maybe all) of us, I don't use it for development, but the truth is that if you target IE as your main browser, you have 99% chances that things will work everywhere.
If on the other hand, you target other browsers (any), chances are that it will only work properly on that browser.
Also the IE dev tools improved A LOT!
Also, if we're here today we have to thank a lot to IE.
Actually the torture is IE8, which according to wikipedia was released in March 2009. It's not MS fault that companies/people froze in time and we still have to target this version.
Go and develop for the Chrome version that was released at that time
Also, try to work for a customer that requires Opera...
Bottom line, don't blame IE for this inconsistency between environments, it's the same pain that native developers feel when developing for different devices and platforms.
Live with it and ENJOY!!!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
