Then to get interactive content; you just pipe the content of each page to the pita daemon using UNIX sockets and write the output to a file descriptor in the /dev/screen directory (just compile and mount the "interactive-wp" filesystem on /dev/screen first, of course).
The only gotcha is to ensure compatibility between these components, but someone shared a compatibility matrix on IRC a while ago, Sio it's common knowledge at this point.
Really these companies "innovations" are a joke.
The web is what we make it. If we want apps running in browsers (say, email clients) then that's what the web will become.
> A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly.
They must be joking. Who runs a server in a browser?
As long as this stays in the browser, and is not also used server-side, I don't think there's much to worry about. Since it's designed to be Java like, I suspect most developers would opt to use server-side Java, and this in browser. This probably won't change.
[outside of kayfabe, Java was really first released in May 1995, only a few months before this press release, and was mostly used for applets and desktop applications (building a web browser!) - server side usage came a while later]
It looks like this is exactly what they intend to do at some point. From the article:
> A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly.
I don't see how this would work, tbh.
I’ve been playing around with this new language called Python. The indenting syntax takes a little getting used to, but the code is way more readable than Perl. Just be sure to set indent-tabs-mode: nil if you use Emacs.
If you figure out how to write an AppleScript program to munge the Unix and Windows scripts, let me know. Manually fixing them in BBedit is getting to be a real drag.
JavaScript is obviously meant as a glue language. Component-based programming is quickly replacing binary files as the method of deployment with technologies like CORBA and COM (the base technology for OLE 2.0). Java Applets are Java's answer to portable, client-side UI component. But in order to integrate them with a static web page or with each other you need some glue code, and this is where JavaScript stands: write reusable components that unleash the full power of Java, and tie them up together using JavaScript glue code.
I expect that in the near future Sun will introduce a server-side component model to accompany Java applets. It'd be cool if they use some coffee-related name for that, idk, maybe Java Beans? This is going to revolutionize servers and everybody is going to throw away their cgi-bin/ folder with hacky perl scripts and move to components. Think about it! Instead of writing your own code, you can wire up mature components developed, each developed by an industry leader:
- Advanced Forms Applet by Microsoft - Server components for converting submitted forms into Excel spreadsheets, also by Microsoft - Database client developed by Oracle - Automatic stock ticker from Bloomberg - Integrated website search from Lycos - News applet from CNN
Sun is graciously aware of the great danger posed by the first company on this list, but in their great foresight they are going to define generic interfaces for every common type of component, and insert clauses into their license that will allow them to sue companies which try to extend these interfaces in an anti-competitive manner. Now, if you want to switch from Excel to Lotus 1-2-3 or from Oracle to Sybase or Informix you're also free to do so. The same goes for your OS, as all Java components are fully platform-independent. This is truly the future!
It’s only $50,000 but surely everyone making real web apps can afford that. It’s a rounding error compared to what you’re paying Sun for your server hardware.
I looked at PHP/FI for my own homepage before, but it's really nothing more than a rudimentary template language, a slightly more powerful version of httpd's Server Side Includes. Rasmus (the developer) seems to be quite happy with keeping it simple. Perhaps you'll be lucky and he'll change his mind and convert it to a full scripting language. Heh, maybe we'll even get two frustrated undergrad students who hate Perl to rewrite the parser so they can use it to write their computer science project. Maybe you'll even be very lucky and somebody will decide to write a popular system for writing web journals in PHP/FI that would take over the world (but how many people would be so self-absorbed as to maintain a web journal anyway).
And you still don't have the database and hardware side covered. PHP/FI seems to support mSQL. mSQL is cheap for commercial use, but still not free, and it doesn't even support JOINs! And you also need a server. You also need a server. httpd used to be cool, but NCSA is no longer maintaining that. There's a serious of patches running around, so you could just run a patchy version of httpd, but how far will that take you? Next you need a proper OS to run that thing on, but while we're all waiting for GNU Hurd, there's a guy from Finland who made a free *nix OS that's been gaining quite some traction recently. These Scandinavian guys are full of surprises. Maybe you'll be lucky again and there's yet another guy in Finland waiting to unleash a free software SQL database with joins, who knows.
I don't know if you've heard of CPAN - it was introduced less than 2 months ago (October '95) and it's fantastic: you can browse and download modules off the world-wide web without hunting down tarballs on obscure FTP servers! The number of Perl modules on CPAN is growing daily! Any functionality a webmaster may want can be achieved using Perl CGI scripts - I highly recommend the latest CGI.pm (v2) whixhbyou can get from CPAN
Just put an animated mailbox icon on your home page that hyperlinks to a form page. Put the usual <INPUT> and <TEXTAREA> elements for "from", "subject", yada-yadda-yadda...
Then put in "hidden" type <INPUT> form elements for the "to" value. Totally make sure to make it hidden!
Add a submit button, and bada-bing, you're all set!
You can even send messages to your pager! Check the manual that came with it.
I'm kind of breaking the immersion here, but I'm quite sure at some point Netscape was selling a Javascript powered web server.
1. http://www.java.sun.com/products/archive/hotjava/index.html
I saw that link elsewhere in this thread after my reply, and I also thought that this might have been what was being referred to.
But why create a new language just for the browser? It clearly makes more sense to use Java in both the server and the browser. We could write little Java applications inside the browser; say we call them "applets"?
Source: I was there
As this has no relevance for serving and requesting pure documents there will be no need for us to use a java-script capable web browser if all we want is to read websites.
1) Introducing scripting to the web can introduce security concerns, but this is the wrong way to think about interconnected systems. By far the greater security concern is trust models built over anonymous connections. When you can eliminate anonymity or the security implications therein most of the security issues that arise from the availability of scripting are like wise mitigated.
2) The greatest difference between JavaScript and Java is that Java will force OOP on you, in JavaScript functions are first-class citizens, and the scope model is always lexical. I abhor OOP and completely avoid the ambiguity of inheritance and keyword pronouns when writing JavaScript. Always choose composition over inheritance. When I see people intentionally do otherwise I immediately assume they have no idea what they are doing.
This, when read using 2023 political correctness caused me to have to wipe coffee off of my laptop screen. I'm picturing HR paying me a visit because my last commit misgendered the Person object.
That sounds more like a marketing stunt to me.
Lisp is so obviously the future of the web, so this seems like a backward step to me.
Well, MDL has < > conses and ( ) conses. These have a different type tag, but are otherwise identical. MDL uses that to give the two different semantics, situationally.
JavaScript is a scripting language and therefore much easier to use. No slow compilation and build step, no complex and rigid type system yelling at you, no dependency hell. Just type the code in notepad and press f5 in the browser to see it run. You dont need to understand advanced concepts like classes or packages or exceptions. It is as simple to write as an Excel macro.
Java on the other hand requires professional programmers, which are a lot more expensive than web designers, and less fun.
You mean those graphic design people who try to make the whole page as a GIF, like they're making a print brochure, and just don't get hypertext?
Don't worry, they'll clue in or get left behind.
The power of a global distributed hypertext for free sharing of information is so superior that it can't be subverted.
The Internet sees these advertising-type designers as damage, and routes around them.
> Don't worry, they'll clue in or get left behind.
Time traveler here. People with this same mentality are still working in 2023, but instead of making the whole page an image, they're making the whole page a "web app". Almost three decades later, they still don't get hypertext.
There are already scripting languages available. Why not just use something like Tcl which is lightweight and easily embeddable? Why re-invent the wheel?
That (marketing) worked out pretty well. At least for me it took years to figure out what kind of language Javascript really was. Seeing jQuery for the first time was kind of revelation.
[1] https://auth0.com/blog/a-brief-history-of-javascript/ [2] https://2ality.com/2011/03/javascript-how-it-all-began.html
This just begs the question: why are there already multiple scripting languages available.
And this further begs the question: why are people still "re-inventing" the wheel by building new languages?
"There was once a dream that was Rome. You could only whisper it. Anything more than a whisper and it would vanish, it was so fragile. And I fear that it will not survive the winter."
Sounds like I can blame whoever translated to English in a 1581 text of Aristotle’s Prior Analytics, the wrong usage of “beg”.
At the same time, I intend to use the phrase correctly in the future!
These kinds of dual usages come up pretty often, but in that spectrum I find this one very interesting because it is somehow very good at scratching some sort of intellectual/elitist itch in all of us. Both usages are fine, but one is more rare (but not too rare) and "came first" so is ostensibly more "correct." Which makes it very satisfying to bring up in these kinds of conversations :-)
Anyone arguing that you can't use words to mean what they obviously mean and that everyone takes them to mean, but instead must only use them to refer to obscure logical fallacies is clearly nuts and should be ignored.
I hope Microsoft comes up with something like it, so we are not forced to learn java in order to add scripts to html pages.
It sounds like pure Java will get us part of the way there thanks to applets – which are also supported in Netscape 2.0 – but JavaScript gives much more control of the whole page. I played with it in an early beta when it was called LiveScript and wrote a crossword puzzle that didn’t need to reload the page at all. Amazing! Now if I can write the backend part in Java and have it work the same way…
I can’t wait for the Java and JavaScript syntaxes to unite and make web page development simpler. Netscape and Sun HQs are just a handful of miles apart, so come on folks, don’t drag it out! Could we get this before the end of the year?
I'm here from the future to tell you there's never been much difference between an app UI and a document.
> Adding scripting to it could cause security problem
Everyone eventually gets their shit together after witnessing the catasrophically bad security issues caused by idiots desperately avoiding javascript with even worse ideas and implementations.