6 ms·

Is JavaScript becoming a Ruby killer?

28 points by nreece 18y ago

qhoxie 18y ago
No. I won't attempt to refute claims that Ruby is a temporary hype language (though I don't personally agree), but to suggest that Javascript will be the language to dethrone it is ludicrous. What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. This, simply, is not the case.
- procrastitron 18y ago
  Can you give some reasons you think Javascript isn't good enough for server side programming? Certainly the language is pretty powerful, and with Rhino it's fairly easy to integrate with existing libraries.
  - iigs 18y ago
    Without a good platform there's not much to say about the validity of a programming language for a specific task other than it's Turing complete and it has features that might be nice someday if they could actually be used. Until Rails ruby wasn't a particularly nice language for coding server-side web applications. In 2002-2003 I worked for a company developing one, and had it taken off we would have had to rework it in another language very quickly.
    - jamesbritt 18y ago
      "Until Rails ruby wasn't a particularly nice language for coding server-side web applications. " Sure it was. You just had to know where to look for frameworks and libs and how to code in Ruby.
      - dasil003 18y ago
        Okay I'll bite... what were the Ruby web frameworks before Rails?
        jrockway 18y ago
        What $foo web frameworks were people using before Rails? Until Rails, people mostly wrote CGI-style applications. (Yes, there was mod_perl, which people mostly used to make their framework-less web apps run a little faster; and there were Java MVC frameworks. Those were the exception, though, not the rule. Most people just wrote CGI scripts.)
        jamesbritt 18y ago
        Iowa and Cerise were running production apps before Rails. Nitro came out at the same time as Rails. (There may be more, but I'd have to go look it up. They're described in The Ruby Way 2nd ed.) Rolling your own request-handler+template thing is not hard. Nor is using DBI. Having stuff all bundled up is a big win, but it's not something essential. Ruby's a clean, fun language. "Until Rails, people mostly wrote CGI-style applications." Well, maybe that was prevalent with Ruby (whose mod_ruby is/was iffy), but mod_php was damn near everywhere before Rails.
        jrockway 18y ago
        mod_php apps are cached sets of CGI scripts.
- briancooley 18y ago
  >Of course, having faster JavaScript on the client still leaves a lot of room for server-side frameworks, and I still think Ruby is well suited for that. Based on the above quote, I don't think he's suggesting that Javascript will eliminate the need for server side languages at all. He seems concerned about hype, so maybe he thinks that that the hype might be moving from Ruby to Javascript. FWIW, I don't think Ruby is going away anytime soon.
- SwellJoe 18y ago
  What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. I think it's obvious that JavaScript is as powerful a language as Ruby, on the "blub" spectrum, anyway. Where it fails is on connecting to the underlying OS--breaking out of the VM and doing something with the system, which is something that Ruby (and Perl, from which Ruby inherited most of this stuff) has in spades. That said, when (not if) JavaScript gets a reasonable FFI and good ties to the underlying OS, on the order of Ruby, Python, and Perl, it will be the obvious choice for implementing just about everything. Faster implementations (V8 and Tracemonkey are faster for many classes of problem than any of the current dynamic language kings, and on par with Smalltalk) mean that once the "plays well with others" problem is solved sufficiently, there will be little reason to choose Ruby/Python/Perl except "I like it better"...and, though I do happen to like Ruby, Perl, and Python a lot, I also find JavaScript a very pretty language with a lot of power. If it gets block scope (which Ruby also doesn't really have, I think?), and the previously mentioned FFI and OS integration, I will have nothing else to complain about (except the DOM).
  - Raphael 18y ago
    What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?
    - eyelidlessness 18y ago
      Well, it's not borrowing another language engine (I'm not sure what that would even mean), but server-side Javascript with OS integration is becoming more feasible: http://www.aptana.com/jaxer http://www.aptana.com/jaxer
    - SwellJoe 18y ago
      Couldn't it just borrow the engine of another language? What "engine" do you mean? I'm not sure one can point to a single chunk of code in any mainstream dynamic language and say, "There! JavaScript needs that!" libc is probably the place to start (it's where Perl started, anyway), though learning from the mistakes of prior languages that have solved these sorts of problems is also wise...while making it work the way a JavaScript programmer would expect. You couldn't simply take Perl's implementation and cram it into something else (though maybe you could on a Parrot-based JavaScript engine, or you could steal from JRuby on a JVM-based engine--I guess the Rhino folks have "solved" this by allowing access to the Java libs, but I'm not sure, as I've not yet used Rhino). It needs to work like JavaScript to be a "native" feature of the language, rather than consigned to the ghetto the way it has historically been under Lisp and Smalltalk. In Perl, for example, one can open a filehandle, similar to opening a file handle in C minus all of the icky stuff, and then work on every line in a "while" loop very concisely ( while <> ... ). So, the underlying code is talking to libc (or the Windows API, whatever it's called), but the user sees Perl. So, just connecting JavaScript to libc isn't going to solve this problem...someone has to decide what "JavaScript file I/O" ought to look like, and build it on top of libc (and whatever the Windows API is), preferably with a reasonable standard being defined sometime soon after. And that's just the beginning (though it's such an important, and challenging, beginning I'm having trouble thinking of what the other pieces are). In the end, before we can say "JavaScript is a Ruby/Perl/Python killer", it'll probably take a few smart people sitting down with Stevens' UNIX programming books and pretty much deal with all of the various things people do when programming on a UNIX (and whatever the Windows API bible(s) is/are) system. Signals and IPC, sockets, etc. Though the more I think about it, the more I realize that on UNIX, anyway, many of the "hard" things are just special cases of file I/O since most everything is a file anyway. So, really solving file I/O and providing a good FFI is probably a good 80% solution, and a CPAN-like library of code (JSAN, perhaps) could be developed by the community to fill the gaps. So, best case unless the JavaScript standards folks start thinking about these problems...one or more engines will start with a decent FFI, and someone will design clever OS wrappings for the most important bits and people will begin building ad hoc solutions to the various OS interaction problems via libraries. It'll take several years, perhaps, after server-side adoption begins to grow before a clear consensus on best practices appears. This, of course, means we'll have a lot of incompatible and ornery JavaScript OS interaction libs for a while...which is a big problem, similar to C on Windows before a standard API emerged (and even UNIX if you count the networking API schism and the BSD vs. SysV split), for many years. Looking a bit further into this, Mozilla has/had io.js (which talks to XPCOM), but I can't find it anywhere as all the links on Google are dead or outdated stubs that refer to the dead links, and Opera has file-io.js. Jaxer has some file methods, which seems to be a reasonable server-side implementation. All the APIs I could find seem somewhat ugly and lacking in the fun of working with files in Perl (which eats files like candy), though. Just not very "native" feeling. But, I guess it's a start...and given all of the other factors making JavaScript seem like a great idea on the server, it may be enough for many people. I know I'm leaning more and more towards JavaScript for my next server-side project.
- nikils 18y ago
  Did any one try to run javascript with llvm ? javascript without dom and with FFI might be interesting to use on server side.
  - jrockway 18y ago
    Why do you need LLVM for this? Just use any server-side Javascript implementation, port your foreign functions over, and ignore DOM.
aaronblohowiak 18y ago
uhhh, what? how does having faster, fatter client side effect the server side at all (in the m and the c.. the v may be data transforms from objects->html to objects->json.. meh) he isnt even proposing JS on the server side.
bprater 18y ago
Client != Server.
- mpc 18y ago
  I don't understand. I was actually writing server-side javascript before taking a break to read this site
  - r7000 18y ago
    http://almaer.com/blog/rotating-java-and-javascript-on-the-server http://almaer.com/blog/rotating-java-and-javascript-on-the-s...
- twism 18y ago
  Server side javascript runs ycfeeds.com
tlrobinson 18y ago
There's two possiblities here: - Will JavaScript displace Ruby as a server-side language? - Will developers push more and more of their application logic to the client, relegating the server to be a simple storage layer (with authentication, etc, thereby reducing the usefulness of server side frameworks like Rails. I could see both happening. JavaScript is the most widely deployed language to clients, and you can control what you deploy on servers, so it seems like the ideal language if you want the same across both clients and servers.
halo 18y ago
No. Lots of people don't actually like JavaScript much, especially its inheritance model, which is why you get obscene over-the-top technical solutions to stop people from writing it. The language has also been slow to evolve to fix core problems with it due to the fact that any changes need to be agreed with by the major browser vendors. It's likely the language wouldn't be popular if it wasn't for the fact it is the de facto in-browser programming language. FWIW, I actually /do/ like JavaScript.
shimi 18y ago
There are too many script languages and implementation as is
- jrockway 18y ago
  Yup, and every time a new language becomes popular, it will make your app written in the "old" language stop working. Oh wait, no.
omouse 18y ago
No discussion of meta-programming? Can you duplicate the Ruby tricks in JavaScript?
- jrockway 18y ago
  the Ruby tricks? Why couldn't you? You have anonymous functions in JavaScript, that's as much metaprogramming capability as you get in Ruby. (Notably absent from both are macros.)
  - raganwald 18y ago
    Well, you are obviously right about JS having anonymous functions. In addition to anonymous functions, Ruby also has a very late-binding object and class system borrowed from SmallTalk that also--to the Java or C# programmer--looks like trickery. This can be built on top of JS, of course, but I also recall Object Assembler ;-)
  - tlrobinson 18y ago
    JavaScript doesn't have "method_missing" (but Objective-J does! It's called "forwardInvocation")
jhancock 18y ago
The promise JavaScript holds for server side web apps is that a programmer is far more productive with a tool he knows exceptionally well than with several tools he knows just enough. In this way, JavaScript can be used on both client and server and the programmer gets to be a real pro at just one language instead of two or more. This is real value. But...sea changes in IT happen for lots of unpredictable reasons. Just because you have nice rational for why it makes sense does not mean it will happen.
jacobscott 18y ago
Do people actually like javascript, or just like the fact that it is de-facto always present in browsers due to its prevalence on the web (I could ask the same question about flash). The vast majority of client-side js I look at is spaghetti. To be fair, I'm looking at random webpages, not jQuery tutorial websites.
- eyelidlessness 18y ago
  I like Javascript, and given the choice I'd use it server-side as well. It's an excellent language; very minimal, lends itself well to concise but powerful code, and can be made to do pretty much anything given a decent API. Most of the Javascript you look at is terrible because most of it is copypasted from tutorials dating back many years, when Javascript was, at best, not very well understood or known, and not the domain of serious applications. The modern libraries like jQuery and Prototype definitely exemplify how Javascript could be though.
  - jrockway 18y ago
    Actually, most JavaScript looks bad because of people cargo-culting bad DOM code. I don't really like Javascript, but I do agree that the core language is minimal but complete. I will stick with Lisp when I want that, though, because Lisp is nicer looking and has macros.
    - eyelidlessness 18y ago
      (Suit() )yourself)))))))))))))()((() Just joshin'.
    - PieSquared 18y ago
      Javascript is a nice language, but that won't decide much. I mean, look at Lisp. (Speaking of Lisp, I recently discovered reader macros. I mean, damn, but they're awesome.)
wayne 18y ago
Microsoft's had JScript and JScript.NET for server programming for a while and recently added Managed JScript: http://en.wikipedia.org/wiki/JScript http://en.wikipedia.org/wiki/JScript It's never really taken off, though Microsoft always pushed VBScript over JScript and C#/VB.NET over the managed JScripts. I used server-side JScript a little back in the old school ASP days and actually found it pretty confusing having both server and client code in the same language, though it sounded appealing in theory. More to wrap your head around. I do admit a second love with client-side JavaScript after the recent resurgence, but I definitely don't see it displacing Python, Ruby, or even Perl anytime soon. The core language is nice, but it's got a long ways to go.
jon_dahl 18y ago
To his Ruby 1.8 vs. 1.9 question: the difference isn't huge, and I don't think we'll see a split. You get fibers (coroutines); new hash syntax, like User.create(name: "David", address: "123 Fake St."), Enumerators, and lots of little changes. Ruby 1.9 programs should look pretty much like Ruby 1.8 programs for the most part. The more likely split would be on the implementation level: MRI/YARV vs. Rubinius vs. JRuby vs. Gemstone. The camps are working together pretty well right now and aren't looking to divide the community, but I would hate to see it turn into a Lisp-like situation. No offense to Lisp - I love it from the outside, and would enjoy using it professionally - but the fragmentation is definitely a barrier to entry.
khangtoh 18y ago
The browser is not the world.

28 points by nreece 18y ago

No. I won't attempt to refute claims that Ruby is a temporary hype language (though I don't personally agree), but to suggest that Javascript will be the language to dethrone it is ludicrous. What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. This, simply, is not the case.

procrastitron 18y ago
Can you give some reasons you think Javascript isn't good enough for server side programming? Certainly the language is pretty powerful, and with Rhino it's fairly easy to integrate with existing libraries.
- iigs 18y ago
  Without a good platform there's not much to say about the validity of a programming language for a specific task other than it's Turing complete and it has features that might be nice someday if they could actually be used. Until Rails ruby wasn't a particularly nice language for coding server-side web applications. In 2002-2003 I worked for a company developing one, and had it taken off we would have had to rework it in another language very quickly.
  - jamesbritt 18y ago
    "Until Rails ruby wasn't a particularly nice language for coding server-side web applications. " Sure it was. You just had to know where to look for frameworks and libs and how to code in Ruby.
    - dasil003 18y ago
      Okay I'll bite... what were the Ruby web frameworks before Rails?
      - jrockway 18y ago
        What $foo web frameworks were people using before Rails? Until Rails, people mostly wrote CGI-style applications. (Yes, there was mod_perl, which people mostly used to make their framework-less web apps run a little faster; and there were Java MVC frameworks. Those were the exception, though, not the rule. Most people just wrote CGI scripts.)
        jamesbritt 18y ago
        Iowa and Cerise were running production apps before Rails. Nitro came out at the same time as Rails. (There may be more, but I'd have to go look it up. They're described in The Ruby Way 2nd ed.) Rolling your own request-handler+template thing is not hard. Nor is using DBI. Having stuff all bundled up is a big win, but it's not something essential. Ruby's a clean, fun language. "Until Rails, people mostly wrote CGI-style applications." Well, maybe that was prevalent with Ruby (whose mod_ruby is/was iffy), but mod_php was damn near everywhere before Rails.
        jrockway 18y ago
        mod_php apps are cached sets of CGI scripts.
briancooley 18y ago
>Of course, having faster JavaScript on the client still leaves a lot of room for server-side frameworks, and I still think Ruby is well suited for that. Based on the above quote, I don't think he's suggesting that Javascript will eliminate the need for server side languages at all. He seems concerned about hype, so maybe he thinks that that the hype might be moving from Ruby to Javascript. FWIW, I don't think Ruby is going away anytime soon.
SwellJoe 18y ago
What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. I think it's obvious that JavaScript is as powerful a language as Ruby, on the "blub" spectrum, anyway. Where it fails is on connecting to the underlying OS--breaking out of the VM and doing something with the system, which is something that Ruby (and Perl, from which Ruby inherited most of this stuff) has in spades. That said, when (not if) JavaScript gets a reasonable FFI and good ties to the underlying OS, on the order of Ruby, Python, and Perl, it will be the obvious choice for implementing just about everything. Faster implementations (V8 and Tracemonkey are faster for many classes of problem than any of the current dynamic language kings, and on par with Smalltalk) mean that once the "plays well with others" problem is solved sufficiently, there will be little reason to choose Ruby/Python/Perl except "I like it better"...and, though I do happen to like Ruby, Perl, and Python a lot, I also find JavaScript a very pretty language with a lot of power. If it gets block scope (which Ruby also doesn't really have, I think?), and the previously mentioned FFI and OS integration, I will have nothing else to complain about (except the DOM).
- Raphael 18y ago
  What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?
  - eyelidlessness 18y ago
    Well, it's not borrowing another language engine (I'm not sure what that would even mean), but server-side Javascript with OS integration is becoming more feasible: http://www.aptana.com/jaxer http://www.aptana.com/jaxer
  - SwellJoe 18y ago
    Couldn't it just borrow the engine of another language? What "engine" do you mean? I'm not sure one can point to a single chunk of code in any mainstream dynamic language and say, "There! JavaScript needs that!" libc is probably the place to start (it's where Perl started, anyway), though learning from the mistakes of prior languages that have solved these sorts of problems is also wise...while making it work the way a JavaScript programmer would expect. You couldn't simply take Perl's implementation and cram it into something else (though maybe you could on a Parrot-based JavaScript engine, or you could steal from JRuby on a JVM-based engine--I guess the Rhino folks have "solved" this by allowing access to the Java libs, but I'm not sure, as I've not yet used Rhino). It needs to work like JavaScript to be a "native" feature of the language, rather than consigned to the ghetto the way it has historically been under Lisp and Smalltalk. In Perl, for example, one can open a filehandle, similar to opening a file handle in C minus all of the icky stuff, and then work on every line in a "while" loop very concisely ( while <> ... ). So, the underlying code is talking to libc (or the Windows API, whatever it's called), but the user sees Perl. So, just connecting JavaScript to libc isn't going to solve this problem...someone has to decide what "JavaScript file I/O" ought to look like, and build it on top of libc (and whatever the Windows API is), preferably with a reasonable standard being defined sometime soon after. And that's just the beginning (though it's such an important, and challenging, beginning I'm having trouble thinking of what the other pieces are). In the end, before we can say "JavaScript is a Ruby/Perl/Python killer", it'll probably take a few smart people sitting down with Stevens' UNIX programming books and pretty much deal with all of the various things people do when programming on a UNIX (and whatever the Windows API bible(s) is/are) system. Signals and IPC, sockets, etc. Though the more I think about it, the more I realize that on UNIX, anyway, many of the "hard" things are just special cases of file I/O since most everything is a file anyway. So, really solving file I/O and providing a good FFI is probably a good 80% solution, and a CPAN-like library of code (JSAN, perhaps) could be developed by the community to fill the gaps. So, best case unless the JavaScript standards folks start thinking about these problems...one or more engines will start with a decent FFI, and someone will design clever OS wrappings for the most important bits and people will begin building ad hoc solutions to the various OS interaction problems via libraries. It'll take several years, perhaps, after server-side adoption begins to grow before a clear consensus on best practices appears. This, of course, means we'll have a lot of incompatible and ornery JavaScript OS interaction libs for a while...which is a big problem, similar to C on Windows before a standard API emerged (and even UNIX if you count the networking API schism and the BSD vs. SysV split), for many years. Looking a bit further into this, Mozilla has/had io.js (which talks to XPCOM), but I can't find it anywhere as all the links on Google are dead or outdated stubs that refer to the dead links, and Opera has file-io.js. Jaxer has some file methods, which seems to be a reasonable server-side implementation. All the APIs I could find seem somewhat ugly and lacking in the fun of working with files in Perl (which eats files like candy), though. Just not very "native" feeling. But, I guess it's a start...and given all of the other factors making JavaScript seem like a great idea on the server, it may be enough for many people. I know I'm leaning more and more towards JavaScript for my next server-side project.
nikils 18y ago
Did any one try to run javascript with llvm ? javascript without dom and with FFI might be interesting to use on server side.
- jrockway 18y ago
  Why do you need LLVM for this? Just use any server-side Javascript implementation, port your foreign functions over, and ignore DOM.

aaronblohowiak 18y ago

uhhh, what? how does having faster, fatter client side effect the server side at all (in the m and the c.. the v may be data transforms from objects->html to objects->json.. meh) he isnt even proposing JS on the server side.

bprater 18y ago

Client != Server.

mpc 18y ago
I don't understand. I was actually writing server-side javascript before taking a break to read this site
- r7000 18y ago
  http://almaer.com/blog/rotating-java-and-javascript-on-the-server http://almaer.com/blog/rotating-java-and-javascript-on-the-s...
twism 18y ago
Server side javascript runs ycfeeds.com

tlrobinson 18y ago

There's two possiblities here: - Will JavaScript displace Ruby as a server-side language? - Will developers push more and more of their application logic to the client, relegating the server to be a simple storage layer (with authentication, etc, thereby reducing the usefulness of server side frameworks like Rails. I could see both happening. JavaScript is the most widely deployed language to clients, and you can control what you deploy on servers, so it seems like the ideal language if you want the same across both clients and servers.

halo 18y ago

No. Lots of people don't actually like JavaScript much, especially its inheritance model, which is why you get obscene over-the-top technical solutions to stop people from writing it. The language has also been slow to evolve to fix core problems with it due to the fact that any changes need to be agreed with by the major browser vendors. It's likely the language wouldn't be popular if it wasn't for the fact it is the de facto in-browser programming language. FWIW, I actually /do/ like JavaScript.

shimi 18y ago

There are too many script languages and implementation as is

jrockway 18y ago
Yup, and every time a new language becomes popular, it will make your app written in the "old" language stop working. Oh wait, no.

omouse 18y ago

No discussion of meta-programming? Can you duplicate the Ruby tricks in JavaScript?

jrockway 18y ago
the Ruby tricks? Why couldn't you? You have anonymous functions in JavaScript, that's as much metaprogramming capability as you get in Ruby. (Notably absent from both are macros.)
- raganwald 18y ago
  Well, you are obviously right about JS having anonymous functions. In addition to anonymous functions, Ruby also has a very late-binding object and class system borrowed from SmallTalk that also--to the Java or C# programmer--looks like trickery. This can be built on top of JS, of course, but I also recall Object Assembler ;-)
- tlrobinson 18y ago
  JavaScript doesn't have "method_missing" (but Objective-J does! It's called "forwardInvocation")

jhancock 18y ago

The promise JavaScript holds for server side web apps is that a programmer is far more productive with a tool he knows exceptionally well than with several tools he knows just enough. In this way, JavaScript can be used on both client and server and the programmer gets to be a real pro at just one language instead of two or more. This is real value. But...sea changes in IT happen for lots of unpredictable reasons. Just because you have nice rational for why it makes sense does not mean it will happen.

jacobscott 18y ago

Do people actually like javascript, or just like the fact that it is de-facto always present in browsers due to its prevalence on the web (I could ask the same question about flash). The vast majority of client-side js I look at is spaghetti. To be fair, I'm looking at random webpages, not jQuery tutorial websites.

eyelidlessness 18y ago
I like Javascript, and given the choice I'd use it server-side as well. It's an excellent language; very minimal, lends itself well to concise but powerful code, and can be made to do pretty much anything given a decent API. Most of the Javascript you look at is terrible because most of it is copypasted from tutorials dating back many years, when Javascript was, at best, not very well understood or known, and not the domain of serious applications. The modern libraries like jQuery and Prototype definitely exemplify how Javascript could be though.
- jrockway 18y ago
  Actually, most JavaScript looks bad because of people cargo-culting bad DOM code. I don't really like Javascript, but I do agree that the core language is minimal but complete. I will stick with Lisp when I want that, though, because Lisp is nicer looking and has macros.
  - eyelidlessness 18y ago
    (Suit() )yourself)))))))))))))()((() Just joshin'.
  - PieSquared 18y ago
    Javascript is a nice language, but that won't decide much. I mean, look at Lisp. (Speaking of Lisp, I recently discovered reader macros. I mean, damn, but they're awesome.)

wayne 18y ago

Microsoft's had JScript and JScript.NET for server programming for a while and recently added Managed JScript: http://en.wikipedia.org/wiki/JScript http://en.wikipedia.org/wiki/JScript It's never really taken off, though Microsoft always pushed VBScript over JScript and C#/VB.NET over the managed JScripts. I used server-side JScript a little back in the old school ASP days and actually found it pretty confusing having both server and client code in the same language, though it sounded appealing in theory. More to wrap your head around. I do admit a second love with client-side JavaScript after the recent resurgence, but I definitely don't see it displacing Python, Ruby, or even Perl anytime soon. The core language is nice, but it's got a long ways to go.

jon_dahl 18y ago

To his Ruby 1.8 vs. 1.9 question: the difference isn't huge, and I don't think we'll see a split. You get fibers (coroutines); new hash syntax, like User.create(name: "David", address: "123 Fake St."), Enumerators, and lots of little changes. Ruby 1.9 programs should look pretty much like Ruby 1.8 programs for the most part. The more likely split would be on the implementation level: MRI/YARV vs. Rubinius vs. JRuby vs. Gemstone. The camps are working together pretty well right now and aren't looking to divide the community, but I would hate to see it turn into a Lisp-like situation. No offense to Lisp - I love it from the outside, and would enjoy using it professionally - but the fragmentation is definitely a barrier to entry.

khangtoh 18y ago

The browser is not the world.