5 ms·

I don't see what's wrong with embedding a programming language in the browser. It's light weight, and rather simple. As long as this stays in the browser, and

by icepat 3y ago

I don't see what's wrong with embedding a programming language in the browser. It's light weight, and rather simple. 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.

jaggederest 3y ago
I don't know, Java is such a new untested language, I'm not sure anyone will choose it for CGI programming over C, or maybe something like Perl. [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]
- Sharlin 3y ago
  I've taken a look at Java and its standard lib and it's really bad at the kind of text processing that 99% of CGI programming is. Hell, it doesn't even have regexps! To be fair, C is even worse, but that's why we have Perl.
withinboredom 3y ago
> As long as this stays in the browser, and is not also used server-side 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.
- icepat 3y ago
  Yes, this does not make much sense to me. I will stick with Java and Perl until I see a viable reason to Go to something else. Maybe someone will create an improved version of C++ (though my skills there are rather Rusty).
  - LadyCailin 3y ago
    I know a guy Rasmus, working on this server side bit called Personal Home Page. Maybe worth checking out.
  - marcus0x62 3y ago
    Yeah, you’d have to install yet another runtime on all of your nodes to support server-side JavaScript. 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.
    - gruntled 3y ago
      Perl is the only way to go for serious CGI scripts. It’s so powerful, Python is limited and clunky by comparison. And a new language with syntactically important whitespace? Seriously? It will never displace Perl!
      - marcus0x62 3y ago
        Eh, maybe. well, nice talking. I'm going to go back to writing CFML. My boss bought a bunch of licenses with our last funding round, so I have to use it. I don't think it's going to make it any easier to write our reverse auction site for pet food discount coupons (don't tell anybody - we're still in stealth,) but whatever.
    - bazoom42 3y ago
      Python will never work on the web since different platforms use different characters to indicate line break.
      - marcus0x62 3y ago
        Not true. For your Unix hosts, you just need to write a perl script to strip carriage returns before running a script written on Windows, and substitute LF for CR for scripts written on a Mac and for your Windows hosts write a Visual Basic program to add CRs to Unix scripts and add LFs after CRs for Mac scripts. 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.
- ghayes 3y ago
  I think it’s fine so long as they come up with a consistent way to package this JavaScript code into modules. It would be crazy to have 3-4 competing standards.
unscaled 3y ago
> With JavaScript, an HTML page might contain an intelligent form that performs loan payment or currency exchange calculations right on the client in response to user input. A multimedia weather forecast applet written in Java can be scripted by JavaScript to display appropriate images and sounds based on the current weather readings in a region. A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server. On the server, the scripts might dynamically compose and format HTML content based on user preferences stored in a relational database, and on the client, the scripts would glue together an assortment of Java applets and HTML form elements into a live interactive user interface for specifying a net-wide search for information. 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!
pavlov 3y ago
You could just buy WebObjects from NeXT and build amazing dynamic web applications with the best GUI tools and a true object-oriented language. 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.
- Cockbrand 3y ago
  I’ve seen an interesting approach for a lightweight, Open Source server side scripting language by a Danish programmer. It’s called PHP/FI and has been created specifically to make handling forms and dynamically generated Web pages easier. It might even evolve to be an alternative to buying WebObjects.
  - unscaled 3y ago
    I don't see how it's going to beat Perl, which already lets you do the same things, but inside a full-fledged programming language. Many webmasters and server admins have already learned some Perl, and it's considered very easy to use (and even easier when you try to read other people's code). 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.
deleted 3y ago
[deleted]
oblio 3y ago
> 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. I'm kind of breaking the immersion here, but I'm quite sure at some point Netscape was selling a Javascript powered web server.
- kagevf 3y ago
  I recall a web browser[1] written in /Java/ ... I don't remember any servers using javascript back then. 1. http://www.java.sun.com/products/archive/hotjava/index.html http://www.java.sun.com/products/archive/hotjava/index.html
  - oblio 3y ago
    https://dev.to/macargnelutti/server-side-javascript-a-decade-before-node-js-with-netscape-livewire-l72 https://dev.to/macargnelutti/server-side-javascript-a-decade...
    - kagevf 3y ago
      That's definitely server side JS, but I thought the person I was replying to meant a web server that was written in JS, but I suppose "powered" could mean that it just runs JS. 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.
david-gpu 3y ago
> I suspect most developers would opt to use server-side Java, and this in browser 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"?

by icepat 3y ago

jaggederest 3y ago

I don't know, Java is such a new untested language, I'm not sure anyone will choose it for CGI programming over C, or maybe something like Perl. [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]

Sharlin 3y ago
I've taken a look at Java and its standard lib and it's really bad at the kind of text processing that 99% of CGI programming is. Hell, it doesn't even have regexps! To be fair, C is even worse, but that's why we have Perl.

withinboredom 3y ago

> As long as this stays in the browser, and is not also used server-side 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.

icepat 3y ago
Yes, this does not make much sense to me. I will stick with Java and Perl until I see a viable reason to Go to something else. Maybe someone will create an improved version of C++ (though my skills there are rather Rusty).
- LadyCailin 3y ago
  I know a guy Rasmus, working on this server side bit called Personal Home Page. Maybe worth checking out.
- marcus0x62 3y ago
  Yeah, you’d have to install yet another runtime on all of your nodes to support server-side JavaScript. 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.
  - gruntled 3y ago
    Perl is the only way to go for serious CGI scripts. It’s so powerful, Python is limited and clunky by comparison. And a new language with syntactically important whitespace? Seriously? It will never displace Perl!
    - marcus0x62 3y ago
      Eh, maybe. well, nice talking. I'm going to go back to writing CFML. My boss bought a bunch of licenses with our last funding round, so I have to use it. I don't think it's going to make it any easier to write our reverse auction site for pet food discount coupons (don't tell anybody - we're still in stealth,) but whatever.
  - bazoom42 3y ago
    Python will never work on the web since different platforms use different characters to indicate line break.
    - marcus0x62 3y ago
      Not true. For your Unix hosts, you just need to write a perl script to strip carriage returns before running a script written on Windows, and substitute LF for CR for scripts written on a Mac and for your Windows hosts write a Visual Basic program to add CRs to Unix scripts and add LFs after CRs for Mac scripts. 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.
ghayes 3y ago
I think it’s fine so long as they come up with a consistent way to package this JavaScript code into modules. It would be crazy to have 3-4 competing standards.

unscaled 3y ago

> With JavaScript, an HTML page might contain an intelligent form that performs loan payment or currency exchange calculations right on the client in response to user input. A multimedia weather forecast applet written in Java can be scripted by JavaScript to display appropriate images and sounds based on the current weather readings in a region. A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server. On the server, the scripts might dynamically compose and format HTML content based on user preferences stored in a relational database, and on the client, the scripts would glue together an assortment of Java applets and HTML form elements into a live interactive user interface for specifying a net-wide search for information. 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!

pavlov 3y ago

You could just buy WebObjects from NeXT and build amazing dynamic web applications with the best GUI tools and a true object-oriented language. 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.

Cockbrand 3y ago
I’ve seen an interesting approach for a lightweight, Open Source server side scripting language by a Danish programmer. It’s called PHP/FI and has been created specifically to make handling forms and dynamically generated Web pages easier. It might even evolve to be an alternative to buying WebObjects.
- unscaled 3y ago
  I don't see how it's going to beat Perl, which already lets you do the same things, but inside a full-fledged programming language. Many webmasters and server admins have already learned some Perl, and it's considered very easy to use (and even easier when you try to read other people's code). 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.

deleted 3y ago

[deleted]

oblio 3y ago

> 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. I'm kind of breaking the immersion here, but I'm quite sure at some point Netscape was selling a Javascript powered web server.

kagevf 3y ago
I recall a web browser[1] written in /Java/ ... I don't remember any servers using javascript back then. 1. http://www.java.sun.com/products/archive/hotjava/index.html http://www.java.sun.com/products/archive/hotjava/index.html
- oblio 3y ago
  https://dev.to/macargnelutti/server-side-javascript-a-decade-before-node-js-with-netscape-livewire-l72 https://dev.to/macargnelutti/server-side-javascript-a-decade...
  - kagevf 3y ago
    That's definitely server side JS, but I thought the person I was replying to meant a web server that was written in JS, but I suppose "powered" could mean that it just runs JS. 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.

david-gpu 3y ago

> I suspect most developers would opt to use server-side Java, and this in browser 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"?