Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

Post reply on HN
Print view View original

101–110 of 235 posts

Re: Interview with Ryan Dahl, Creator of Node.js

#101

Post by badosu »

tree_of_item wrote: post #65
dasmoth wrote: post #29

Earlier quoted context omitted.

Potentially a better term is "isomorphic", a label which is specifically applied to setups where you run the same rendering code client-side and server-side. That's still a comparatively new concept, at least as something that's actively supported by frameworks and reasonably straightforward to implement.

That's an awful term because it has nothing to do with the actual meaning of the word "isomorphic".

Well, unless you're talking about a homomorphism with an inverse the term seems pretty good for me: the same (iso) shape (morphos) between server-side and client-side.

Re: Interview with Ryan Dahl, Creator of Node.js

#102

Post by gaius »

mbrock wrote: post #27
amasad wrote: post #24

Earlier quoted context omitted.

It means you take your client side JavaScript code and render it on the server for performance and SEO. Previously you had to either duplicate the code in different languages or pick one or the other (either use angular or rails).

Running the same language on the client and the server also has some deeper implications. Like, it becomes easy to imagine an app that runs in a hybrid way with computations shared between the client and server, i.e., "offline mode". This is a pretty big deal, and it's one of the major benefits mostly ignored by the vocal critics of "single-page apps," as seen in the latest article on the HN front page.

If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.

Re: Interview with Ryan Dahl, Creator of Node.js

#103

Post by sova »

gaius wrote: post #102
mbrock wrote: post #27

Earlier quoted context omitted.

Running the same language on the client and the server also has some deeper implications. Like, it becomes easy to imagine an app that runs in a hybrid way with computations shared between the client and server, i.e., "offline mode". This is a pretty big deal, and it's one of the major benefits mostly ignored by the vocal critics of "single-page apps," as seen in the latest article on the HN front page.

If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.

Make a native app for every independent platform?

Re: Interview with Ryan Dahl, Creator of Node.js

#104

Post by jdc0589 »

bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

> Since server-side JS didn't exist yet,

I'm being petty, but serverside JS did exist before node (e.g. Narwhal, which I believe is where jsgi and a lot of the commonjs stuff originated)

Re: Interview with Ryan Dahl, Creator of Node.js

#105

Post by brondeau »

sreque wrote: post #79
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

Node.js brings callback hell to the serverside world of threads and we're supposed to be grateful? It's like you don't know the history of computing. Callback-based code was the original programming model in UNIX dating back decades! Threaded code came about because it's far easier to write it than callback-based code. The ONLY reason to do callback-based code is for performance reasons: for network-IO-heavy apps the…

As with any tool, there is a right and wrong way/time to use it. Node.js would not be the monster success and influencer it is today if it was the 'worst of both worlds'. For example, using a single threaded environment can solve so many issues that are present in a multi-threaded environment, such as reducing possibility of race conditions (though you can still write crappy single threaded code that introduces race conditions). When used in the right way, it can be and is best of class. In other instances, it is a boat anchor. Just my 2 cents

Re: Interview with Ryan Dahl, Creator of Node.js

#106

Post by AgentME »

gshulegaard wrote: post #95
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

> Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. What? I am sorry but this is not true. Coroutines have been a concept for...well a long time: https://en.wikipedia.org/wiki/Coroutine…

>Coroutines have been a concept for...well a long time: ... Green threads also have been around for a while.

What web frameworks were built around using them? Was there a good ecosystem of libraries that were easy to use with the web framework without introducing blocking I/O?

>I am not sure how you can say this while using Python as an example. Python has the GIL which, typically viewed as a limitation, actually prevents the situation your assertion suggests. In fact, one of the largest barriers to removing the GIL is the wealth of libraries and C-extensions to Python that implicitly rely on the thread safety guarantees/limitations of the GIL (as covered by Larry Hastings as part of his first Gilectomy talk).

Aren't all python threads backed by OS threads? And pointing out that threading has been used by too many Python libraries to change supports the previous comment's assertion that non-blocking I/O was hard to use exclusively in languages like Python because too many libraries used blocking I/O.

>Edit: Heck, NGINX was an asynchronous, event driven web engine released in 2004 and written in C:

Nginx is pretty specialized. Not really sure it's useful to compare it to a programming language / web framework with an ecosystem of compatible libraries like PHP, Ruby on Rails, django, nodejs, etc.

Re: Interview with Ryan Dahl, Creator of Node.js

#107

Post by thomasz »

nulagrithom wrote: post #68
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

On that note, coming back from node.js has been a really frustrating experience for me. I want to scream every time somebody suggests threading as a solution to non-blocking database calls and HTTP requests. It's made me painfully aware of how often parallelism is suggested in place concurrency. C# in particular does a great job at conflating concurrency and parallelism. Both fall under the same Task namespace and it…

It's hardly the fault of the language if people are lying in their method signatures. I'm not aware of a mainstream PL with a type system that is powerful enough to avoid something like that.

Re: Interview with Ryan Dahl, Creator of Node.js

#108

Post by gaius »

sova wrote: post #103
gaius wrote: post #102

Earlier quoted context omitted.

If you need "offline mode" why not just write a native app? It will be far better in every way - looks, performance, battery drain, you name it.

Make a native app for every independent platform?

Windows, Linux, OSX - there just aren't that many platforms these days, it's perfectly do-able. If your core logic is in ANSI C (or equivalent) and you just need a GUI for each platform, even easier.

Re: Interview with Ryan Dahl, Creator of Node.js

#109

Post by pawelk »

jdc0589 wrote: post #104
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

> Since server-side JS didn't exist yet, I'm being petty, but serverside JS did exist before node (e.g. Narwhal, which I believe is where jsgi and a lot of the commonjs stuff originated)

There was also Rhino in the Java land (I remember working with Helma before Node came out), JScript on IIS, some projects embedding SpiderMonkey.

I think node.js finally made server-side JS take off because 1) it was based on V8 which was the new, performance-oriented JS engine powering Chrome, and 2) it was self-contained (i.e. didn't rely on Java on one hand, wasn't just a scripting layer of something larger on the other).

Re: Interview with Ryan Dahl, Creator of Node.js

#110

Post by coldtea »

stephenr wrote: post #32
amasad wrote: post #14

Earlier quoted context omitted.

The fact that Node survives as a platform for Fullstack JavaScript shows how serendipity works in invention: he set out to build a high performance network server and ended up building one of the largest platforms for building web applications. The reasons it ended being very big are clear in hindsight but are hard to predict: - Sharing code between server and client - Server side rendering - Lower barrier to entry t…

I wouldn't call npm "well designed". It's progres bar was the bottleneck causing slow downs. The size of node_modules directories is basically a meme now.

Both issues are irrelevant as to whether npm was well designed.

One is an implementation detail of a secondary part of its operation (progress indication), and the other is about packages having many dependencies, not about npm causing node_modules directories to grow itself.

Post reply on HN