Look, no client! Not quite: the long road to a webbified Vim The most revolutionary aspect of all the changes that have taken place in web development over the last two decades has been in the web browser. Typically we think of web browsers as driving innovation on the web by providing new features. Indeed this is the major source of new features on the web. For example, Microsoft …
" I'm not aware of any other development platform in which you can look at the code behind the app with the simple click of a menu "
HTTP-induced myopia strikes again. Not a menu-click, but off the top of my head: Perl*, anything written in shell script, 8-Bit BASICs and Spreadsheets (you don't have to be online to be an application).
I'm sure other people will chip in...
* for Perl, no, that actually is the sourcecode. Yes, someone really did type that.
"Perl pwned my eyeballs. It took a bloody good surgeon two days to unscramble my retina."
Heh. Although, more likely a really bad Perl coder pwned your eyeballs - it always did give you more than enough rope to hang yourself with in the readability stakes.
I always understood Perl to be write-only? ;-)
Sigh... yeah, Perl "golfers" have a lot to answer for. Like any language (well... maybe not COBOL), it's possible to write readable, well-commented code in Perl.
For that matter, I seem to recall the write-only charge being leveled at C (not surprisingly, this was usually said by Pascal's adherents -- back in the day, they were quite numerous).
I just saw an oblique reference on folklore.org, but Smalltalk was a graphical environment where everything on the screen was an object, and you could trigger a menu on any object to display its code. You didn't have to dig through the page's code to find the object of your interest.
I was sad when the object-oriented dreams of the 1980's degenerated to the stream-of-text model of Unix and Windows. And Java is a very poor imitation of an object-oriented language. We're gradually rebuilding, but it's so slow compared to those days, and it's an uncomfortable fit on the Unix base.
I remember Smalltalk, but not at the time (I'm too young). A nice idea, but it was a bit too free-form for large applicaitons, and it made zero concessions to performance.
Edsger Dijkstra's scathing comment about OOP ("an exceptionally bad idea which could only have originated in California.") was more about Smalltalk's approach of "just sit down and start coding until something looks like it's working" than the very clever ideas of data encapsulation and separation of function that it included.
As for stream-of-text, isn't Microsoft PowerShell basically a command-line environment that uses objects instead of text streams? I've never used it, but the concept appeals to me (especially as about 40% of my shell-script code revolves around parsing the text output of other tools and scripts)
Just because you can do anything in JavaScript doesn't mean you should.
One of the things you can do in JavaScript is make it behave a little like a well-thought-through and usable language, but the effort is non-trivial. This is one reason I find Node so baffling- why are we taking the one of the most irritating languages around and putting it on the server rather than dedicating some effort to picking one of the many excellent languages that exist already and making it run in the browser?
...why are we taking the one of the most irritating languages around and putting it on the server rather than dedicating some effort to picking one of the many excellent languages that exist already and making it run in the browser?
Because Ryan Dahl got there first. Less flippantly, because it's easier to write a language for a server than it is for a browser, and even if you manage it, there's still the question of getting the browser makers -- a dwindling number, but still more than one -- to adopt your language.
We're sort of approaching your scenario -- if you view js as something to compile to, instead of a language to develop in, then emscripten is doing good work, and my current programming interest, coffeescript, has cleaned up a lot of js flaws (although not the '+' operator flaw, alas).
Very exciting, deeply cool, so much you can do with the new toys.
Now, how do you do the really boring stuff like protect the user from browser-delivered malware? Sorry to be so dull but this stuff matters.
(oh, and BTW gmail works fine without jscript. And any reason to call web front-end for email a 'complex web app'?)
I really, really don't get this.
The web browser is a client application for viewing web pages. The vast majority of users of web browsers don't want or need development tools built in, and it just adds to the bloat and slows the browser down.
Firebug is a great diagnostic add-on tool for tweaking CSS or finding obscure errors, but why try and use it as a development tool?
If you're a developer, then either use an IDE, of which there are hundreds (why only mention two of the worst, Dreamweaver and FrontPage?) or just use a text editor (with syntax highlighting if you want), a browser and a local instance of a server.
Is that really too complicated for the modern web developer?
You can't see any benefit, at all, for providing these debugging tools directly in the applications that are used to deliver the content?
Not when it turns what should be a client application into a full-fat development environment, no.
As I said, Firebug is useful, but I wouldn't want it switched on all the time, or built into the browser without being able to disable or remove it - which is what the OP seems to be suggesting.
You wouldn't expect a desktop or mobile app to also include there own debugging environment would you? so why hinder a web browser with it?
Essentially, because the browser is also the runtime.
Now I don't agree with the assertion that the browser should always be the entire development environment, but you certainly need development tools in it. The reason for that is because the browser also runs the client side code, so the only way to debug the code is inside the browser. Therefore you need a debugger inside the browser, or you need to have the ability to run the browser's Javascript engine outside of the browser in such a way that you can debug it using the IDE of your choice.
Anyway - it's kind of a moot point. Modern browsers have development tools built in, and the vast majority of users have absolutely no idea that they're there since you typically need to actively do something to access the tools.
because breaking into and stepping through code examining variables etc etc is the fastest way to debug any code ...
and a personal rant about a valuable feature missing from all the current in-browser debuggers - visual studio (but not the free express versions) also allows changing the "current" line to step from a different line. this enables much richer debugging of tricky issues by allowing restepping through code, say after changing local variables, without having to restart from the beginning
A little back to front compared to the gist of this article but Visual Studio's Browser Link lets you push changes from your source code directly to your browser under test and push changes made in the browser's dev tools back to the source code.
The demo is impressive, though to be fair I've yet to find a reason to use it.
http://vswebessentials.com/features/browserlink
I want to try some of the examples linked to, but i was told that they were not *WEB* apps, but Chrome Apps. tat I was told I would need a **special** interpreter (Chrome) to run these apps and that I should _NOT_ expect these "web apps" to run on any other web-platform (FF, Palemoon, IE, etc...).
So how are Chrome-specific apps Web-Apps?
You'll need better examples of web-apps than simply those that are Chrome-only.
Reminds me of the "good-old-days" of MS having their own web-standards that only worked in IE...
Lovely. Certainly don't need another monopoly with Google replacing MS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
