5 ms·

I am optimistic though. We are still in the early days of server-side javascript. It took 20 years for the greater php community to coalesce around a handful of

by moojd 4y ago

I am optimistic though. We are still in the early days of server-side javascript. It took 20 years for the greater php community to coalesce around a handful of quality libraries, frameworks, and solutions to things like user management instead of everyone rolling their own or using things like '$_GET["pass"] == "foo"' they they grabbed from a google search. Node is barely over a decade old. We are already seeing patterns mature in the node ecosystem and I hope things keep progressing that way.

lowercased 4y ago
> It took 20 years ... Node is barely over a decade old. We are already seeing patterns mature in the node ecosystem and I hope things keep progressing that way. But... much of the earliest web work (PHP, etc) occurred in the early days of search. Example of quality code, best security practices, etc all were fairly .. rudimentary and hard to find. Just because it took 20 years starting 20 years ago doesn't justify 20 years starting from 10 years ago. There are infinitely more and better resources for just about everything these days.
tannhaeuser 4y ago
> early days of server-side javascript Err ... Netscape's LiveWire introduced server-side Javascript in 1996 even before Java became widely used on the server side. The module convention, the (synchronous) core modules of Node.js, and its canonical http middleware API and express.js/Connect/JSGI is from the CommonJS initiative, a co-op of 2000's SSJS framework developers [1]. [1]: https://www.commonjs.org/ https://www.commonjs.org/
- Cyberdog 4y ago
  This is an "um ackshually" reply. Nobody used LiveWire and it died a swift death. And don't "um ackshually" me about saying "nobody." You know what I mean.
  - rileymat2 4y ago
    Classic asp also supports JavaScript, it is old and wide spread in the bowels of legacy sites. I thought of node as a victory for async more than anything else.
    - Cyberdog 4y ago
      > I thought of node as a victory for async more than anything else. In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. I can see the application for something like websockets but I presume most Node sites aren't using those. I figured its success was due to V8 being reasonably fast, plus a generation of front-end-centric developers coming along who had learned to use JS quite heavily on the front end and didn't realize or didn't care that better options already existed on the back end.
      - eyelidlessness 4y ago
        > In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. This is precisely why async (well, cooperative concurrency generally) is useful, whether on a server or otherwise. Blocking for things you can’t do yet is a waste of idle resources. There are plenty of other concurrency models which are also useful, but yielding/suspending when idle is almost always better than not. And the cases where it’s not generally have other problems.
        Cyberdog 4y ago
        I don't understand. What can a Node app do in between making a database request and when the response arrives?
        eyelidlessness 4y ago
        Make other database requests, or return the responses derived from prior requests. Or just anything else waiting in the event loop queue, including queueing more work. You can think of the concurrency model like green threads with only one thread available, or actors in a single system process. Edit to elaborate: yield/suspend is key here. The way it works is yielding/suspended calls have their outstanding work put behind the extant queue which proceeds until each next queued routine suspends or returns, and once that set of blocking work completes the routine which suspended can proceed until it yields again or returns. The obvious pathological case is long running work which doesn’t suspend. Which if it’s I/O or idle-heavy should be refactored to yield, if it’s compute-heavy it should be treated as an optimization or scaling target.
bdcravens 4y ago
Many frameworks or languages were fairly well developed by a decade's time. Node is 13 years old; compare it to Rails circa 2018. I don't think PHP makes for a great comparison, because the web ecosystem was still growing. Node was birthed in the age of Github, social media, Stack Overflow, and Google. PHP was released in 1995, when search engines were still stuck in their infancy and only a small percentage of the world was even using the WWW. 20 years in PHP's time is like maybe 5 years from 2009.
- bdcravens 4y ago
  Another point about PHP: Wordpress, the largest deployed PHP app, was released in 2003, PHP's 8 year mark.

by moojd 4y ago

lowercased 4y ago

> It took 20 years ... Node is barely over a decade old. We are already seeing patterns mature in the node ecosystem and I hope things keep progressing that way. But... much of the earliest web work (PHP, etc) occurred in the early days of search. Example of quality code, best security practices, etc all were fairly .. rudimentary and hard to find. Just because it took 20 years starting 20 years ago doesn't justify 20 years starting from 10 years ago. There are infinitely more and better resources for just about everything these days.

tannhaeuser 4y ago

> early days of server-side javascript Err ... Netscape's LiveWire introduced server-side Javascript in 1996 even before Java became widely used on the server side. The module convention, the (synchronous) core modules of Node.js, and its canonical http middleware API and express.js/Connect/JSGI is from the CommonJS initiative, a co-op of 2000's SSJS framework developers [1]. [1]: https://www.commonjs.org/ https://www.commonjs.org/

Cyberdog 4y ago
This is an "um ackshually" reply. Nobody used LiveWire and it died a swift death. And don't "um ackshually" me about saying "nobody." You know what I mean.
- rileymat2 4y ago
  Classic asp also supports JavaScript, it is old and wide spread in the bowels of legacy sites. I thought of node as a victory for async more than anything else.
  - Cyberdog 4y ago
    > I thought of node as a victory for async more than anything else. In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. I can see the application for something like websockets but I presume most Node sites aren't using those. I figured its success was due to V8 being reasonably fast, plus a generation of front-end-centric developers coming along who had learned to use JS quite heavily on the front end and didn't realize or didn't care that better options already existed on the back end.
    - eyelidlessness 4y ago
      > In terms of server-side development? Async is rather useless on the server side. Can't generate a web page or JSON blob with the results of a database query until you actually get those results from the database. This is precisely why async (well, cooperative concurrency generally) is useful, whether on a server or otherwise. Blocking for things you can’t do yet is a waste of idle resources. There are plenty of other concurrency models which are also useful, but yielding/suspending when idle is almost always better than not. And the cases where it’s not generally have other problems.
      - Cyberdog 4y ago
        I don't understand. What can a Node app do in between making a database request and when the response arrives?
        eyelidlessness 4y ago
        Make other database requests, or return the responses derived from prior requests. Or just anything else waiting in the event loop queue, including queueing more work. You can think of the concurrency model like green threads with only one thread available, or actors in a single system process. Edit to elaborate: yield/suspend is key here. The way it works is yielding/suspended calls have their outstanding work put behind the extant queue which proceeds until each next queued routine suspends or returns, and once that set of blocking work completes the routine which suspended can proceed until it yields again or returns. The obvious pathological case is long running work which doesn’t suspend. Which if it’s I/O or idle-heavy should be refactored to yield, if it’s compute-heavy it should be treated as an optimization or scaling target.

bdcravens 4y ago

Many frameworks or languages were fairly well developed by a decade's time. Node is 13 years old; compare it to Rails circa 2018. I don't think PHP makes for a great comparison, because the web ecosystem was still growing. Node was birthed in the age of Github, social media, Stack Overflow, and Google. PHP was released in 1995, when search engines were still stuck in their infancy and only a small percentage of the world was even using the WWW. 20 years in PHP's time is like maybe 5 years from 2009.

bdcravens 4y ago
Another point about PHP: Wordpress, the largest deployed PHP app, was released in 2003, PHP's 8 year mark.