Launching NginScript

I can&#x27;t help but think this is a bad idea. Jamming more stuff into what is a great tool puts nginx on a slow path to a bloaty death.<p>Am I incorrect in assuming that you could implement your entire server-side js app now as an nginScript module? Do people think that is a good thing?<p>Not to mention that putting more interpreters and more end-user code into a system that has access to your service&#x27;s private key might not be terribly wise.<p>I&#x27;m sure many people will tell me I&#x27;m wrong, and I guess I can see some benefit to simplifying configuration and perhaps deployment.<p>But there&#x27;s a reason we&#x27;ve mostly moved away from deploying embedded PHP applications inside of mod_php.

I wonder why they didn&#x27;t use Duktape[1]. It seems like the obvious choice for this kind of effort (e.g., if the 2 main Lua implementations have any counterpart in JS, it&#x27;s probably Duktape).<p>It&#x27;s possible that Duktape was still too early in its development to use when Nginx started this project, but even then it seems like they could have collaborated and saved a lot of man hours.<p>I wonder if there a good reason why Nginx didn&#x27;t use Duktape, or could this be a case of NiH where some Nginx dev got excited about the opportunity to build a new superfast JavaScript implementation just for Nginx? Surely it would have been less work to integrate the two event loops and use Duktape&#x27;s (well-documented) API to build whatever features they wanted?<p>That said, although I&#x27;ve built significant async programs in other languages, I&#x27;ve never done anything in C on this scale, so take my words with a grain of salt.<p>1. <a href="http:&#x2F;&#x2F;duktape.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;duktape.org&#x2F;</a>

It&#x27;s sad to see lua get slowly replaced by javascript.

This seems like massive overkill. Instead of adding a limited domain-specific language which is tuned to nginx&#x27;s requirements, they&#x27;ve added the behemoth that is JavaScript, along with all its flaws. A turing-complete behemoth, at that.

I&#x27;m really happy with openresty and curious to put them side by side. betting on lua here.

This is a welcome improvement to me. I&#x27;ve spent many an hour trying to figure out how to put some logic in nginx but it was never very intuitive to me. I think a reverse proxy + ssl termination + web cache should be considered part of a normal web stack and developers should be proficient to use the full stack when they develop and implement sites. Rather than trying to do everything on the app server, once I started utilizing nginx my app design changed somewhat and of course the response times dropped and the app server load was reduced. I&#x27;m hoping nginscript just makes it all easier to do.

A web server with a JavaScript engine. What could ever go wrong?<p>My eyes start to bleed when I imagine what some cowboys will implement on top of that.

The post ends with &quot;We look forward to your feedback as you try out nginScript [...]&quot; but it doesn&#x27;t mention where we can test it out. Does anybody know more about that?

<i>We run a separate virtual machine for each request, so there’s no need for garbage collection</i><p>I&#x27;m curious to see the impact of this strategy on performance.

I think a countdown for a new &#x27;in vogue&#x27; webserver just started.<p>This is something I would&#x27;ve expected from a &quot;Show HN: Embedded JS in Nginx&quot; post, meaning it has potential to be a project done just to see what can be done, that everyone could say &quot;Hey, that&#x27;s cool&quot; and then never use, because it&#x27;s a terrible idea.<p>Instead, it&#x27;s presented as a reasonable way of moving forward, when they could&#x27;ve pushed for their own much more reasonable alternative. They&#x27;ve done more work for a worse idea, effectively out-competing their own feature with a much more popular but crappy alternative.

Adding Javascript support to high-performance reliable web server does not seem rational from the engineering point of view.<p>I&#x27;d rather added support for the safe subset of some statically-typed, high performance language compiled to LLVM. This language must be without asyncronous GC, so its memory use will be predicatable under high load.<p>Javascript on server side is so vogue-ish. Vogue will change soon but uglyness of architectural decision will stay with Nginx forever.

I think it&#x27;s a good addition. We have been using varnish on high traffic servers and one of the reasons was that it had &quot;vcl&quot;, a javascript-like language to define request handling logic. (With a lot smaller feature set and more domain specific. But powerful enough). Having javascript on nginx would provide a lot of config options for people familiar with it. I believe nginx already has Lua support so not a big deal anyway.

Yeah, I am a known Apache fanboy, and so I&#x27;m sure that what I say will be discounted. But, imo, this just shows what happens when an open source project becomes the sales initiative of an Open Core model company. Instead of the design and future being under the control and guidance of the community, it is instead in the hands of the VCs and whatever &quot;promises&quot; future revenue growth. Believe me, I know; I used to work at Covalent which was billed as the &quot;Red Hat of the Apache web server&quot; so I know how hard it is to resist the push of VCs and those nasty quarterly numbers. And Covalent wasn&#x27;t the only Apache shop around, unlike nginx.com today.<p>The combination of FUD and marketing $$$ is being used to &quot;encourage&quot; more people to migrate (or use) nginx, as an &quot;open source&quot; alternative, when it&#x27;s obvious that &quot;open source&quot; is being used mostly for the PR aspect and not so much for the community-focus and community-led aspects which is really core to &quot;true&quot; Open Source.

nginx is driving very fast down the road to firefox.

Should Greenspun&#x27;s Tenth Rule be updated with a note that &quot;they might try adding javascript before they add common lisp&quot;?

I can understand the appeal, marketing Javascript to CIO&#x2F;CTO is much easier than marketing Lua today.<p>(Which obviously is sad as in my humble opionion for various reasons Lua is the better embedded language. I hoped it could become a widely adopted standard, we had great success with Lua in Redis in the past).

as long as I can compile --without-nginscript, go nuts

For anyone interested, it looks like it&#x27;s available as a module on <a href="http:&#x2F;&#x2F;hg.nginx.org&#x2F;njs&#x2F;" rel="nofollow">http:&#x2F;&#x2F;hg.nginx.org&#x2F;njs&#x2F;</a>

I&#x27;ve recently been leaning towards not using web servers like nginx or apache at all. There are non-blocking server platforms like node.js or vert.x that let you code your web server instead of configure it. I find that ou frequently hit a wall of opaque redirect rules that become unmaintainable for any complex project. Having your server written in testable code makes it more predictable. It looks like nginx is trying to meet in the middle.

I think that most people missed the point here.<p>The basic idea is a DSL that &quot;happens&quot; to have the same syntax than Javascript. I guess that this VM has a lot of optimisations related to its purpose toward nginx (.e.g. no GC overhead, since each JS context is supposed to be short lived and tied to a unique request).

so it&#x27;s mod_perl, but javascript and nginx instead of apache and perl. seems like they&#x27;ve ignored history here, as mod_perl turned out to be a bad thing in the end, people messing with bits they really shouldn&#x27;t leading to massive amounts of unmaintained legacy spaghetti code messing with all parts of apache.<p>bearing in mind mod_perl&#x27;s original use was not for writing applications, it was for messing with apache, for doing the things you can&#x27;t easily do in the config. but where there&#x27;s a way, abuse will follow, and before you know it whole apps will be written with this<p>ah well, those who don&#x27;t learn from history are doomed to repeat it.<p>so, while it may seem like a good idea now, you can bet in 5-10 years it will no longer look so clever

I wonder if they&#x27;ll have an &quot;&#x27;nginscript&#x27; is evil&quot; section in their wiki, like their &quot;&#x27;if&#x27; is evil&quot; one...

I wonder if this has anything to do with the call for a new maintainer for LuaJIT recently

As long as they add a --disable-js config flag i guess i&#x27;m okay with it

If you need that flexibility I think Go is much better solution.

Why not write a JavaScript to Lua transpiler instead?!

Why did not they use Golang?

Dislike.

<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rX7wtNOkuHo" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rX7wtNOkuHo</a>

I think Nginx is open source crippleware. All the goddies are in the closed Nginxplus. Http2, load balancing with monitoring with application health checks. Do you get the source code of the closed features?<p>Nginx already has LUA scripting support.

HN and it&#x27;s predictable level of antipathy is a constant disappointment. Hating is the norm, do better. Put more thought into your opinions.<p>Personal feelings of Javascript aside (not my favorite either!), I think this is a great business move (adoption, excitement, blog-o-sphere marketing, even if some users shoot themselves in the foot), and I think it opens up exciting possibilities, including creating Nginx+ features fo&#x27;free.