The Future of Programming in Node.js

https://groups.google.com/forum/#!topic/nodejs/9afurRCTlOc

by Yakulu • 13 years ago

278 176 13 years ago

groups.google.com

leetrout• 13 years ago

We are done making breaking changes at the Node.js layer. If your
program runs today, we're doing everything we can to make sure that it
will run next year, albeit faster and more reliably.

I've yet to devote any significant amount of time to developing on Node but this is a big +1 for more serious consideration.

My memory is fuzzy (this was well over a year ago) but I remember building an app in express and it being completely broken by updates a very short time later (along with a good number of other modules that hadn't been updated either).

Anyone venture out a guess/opinion on how many things in userland will stabilize because of this? (Or perhaps things already have- I don't hear as many complaints about express' api changing lately).

treeform• 13 years ago

I remember that time too. Most of the modules I use are pretty stable now, which is nice.

driverdan2• 13 years ago

Userland has become a lot more stable over the past year or two as projects have matured. A lot of popular projects (like express) went through rewrites with breaking changes.

SimHacker3• 13 years ago

Didn't UserLand make Frontier? (It's a Dave Winer joke -- ha ha!)

mattyod3• 13 years ago

Working on a large scale & fluid Node project at the moment and we probably see at least a dozen dependency updates a week. Never caused a problem.

The community as a whole is pretty strict in it's respect for versioning conventions.

ilaksh4• 13 years ago

Well, I had an issue with Express going up a major version also to 3.0 but it was actually my fault because I didn't specify the major version in my package.json, i.e. 2.x. If I had done that the breaking changes would not have got me.

jchrisa2• 13 years ago

Node's module system is hands down the best module system I've worked with. I wish other new languages would stop trying to innovate and instead just copy what they've done.

nahname3• 13 years ago

Really? I think it is terrible when compared to other languages (C#, Java, Ruby, Python, etc...). I have only done a few applications on node, but my experience with including modules was painful to say the least.

RKoutnik• 13 years ago

Could you elaborate on that? What did you find difficult about `npm install $PACKAGE` and `var thing = require('thing')'`?

nobleach• 13 years ago

While I like using NuGet packages with C#, I'm not really wild about how they can get magically linked in to a project, and then required. I had nunit and fluent assertions become inextricable from a project I was working on even after all the tests were removed. Just a total mind-f*ck. Python when using pip is a whole lot better but I've had some issues finding things there too. Ruby... it depends. Are we talking Rails gemfile or "gem install $package"? Conflicting versions can become an issue. Java with Gradle has been pretty cool so far. NPM as a whole, has just worked. Packages are referenced in ONE place (package.json) I can do an "npm install $package --save" during development and it gets included automatically.

carrja992• 13 years ago

I'd have to say the biggest thing that npm has over module systems found in java, ruby, python etc. is the complete isolation of transitive dependencies. It is nice to use two dependencies and not waste a day or two because:

* module A depends on module C v1.0.2

* module B depends on module C v1.4.3

In all the languages you mentioned it becomes a pain because you can only use one version of module C, meaning either module A or B simply will not work until you find a way around it.

bungle• 13 years ago

Still that is the thing that Node.js lead developer regrets the most. Too late to change it, though.

bshanks2• 13 years ago

Do you have a link? I'd be interested to read what the Node.js lead developer has to say on this, thanks

clintonb11• 13 years ago

I agree. PIP in python is great, but has some extra overhead and difficulty with it, like having to setup virtual environments for each project. NPM by default installs to the local project only and with a quick --save will put it in package.json dependencies (similar to requirements.txt with pip). Node package management is awesome because it is so simple.

rhelmer• 13 years ago

Virtual environments are optional though, right? You could have one big virtualenv for all projects, or simply install things into the system path (although I wouldn't recommend either)

rafekett• 13 years ago

Have you used ML?

PuercoPop• 13 years ago

I should just probably say, clearly you haven't seen Common Lisp's defpackage, modules are actually first class objects there and are completely decoupled from the file system.

But most importantly as Barbara Liskov mentions in this video[1] we don't know what is a module exactly or how to use them yet. Which is an specific statement aligned with Alan Kay's famous "We don't know how to design systems so let's not turn it into a religion yet."[2]

tl;dr; 1) Innovation is good. 2) Javascript's module is a half assed implementation of Common Lisp's defpackage. (Don't get me wrong is still way better than Python's abhorrent ninja goto: import)

[1] http://www.infoq.com/presentations/programming-abstraction-l... [2]: https://www.youtube.com/watch?v=oKg1hTOQXoY

coolsunglasses2• 13 years ago

You have not used a good module system. Clojure's namespace system for example is really nice.

bshanks2• 13 years ago

What do you like about Clojure's system?

zekenie• 13 years ago

This is the kind of open-source leadership that made me move from PHP to Node. Node knows what it is.

SimHacker3• 13 years ago

At least we can trust the node developers not to check in untested code that breaks crypt.

lelf• 13 years ago

I hope that the future of Programming is not in Node.js

AndyKelley3• 13 years ago

You could make this comment useful and worth reading by explaining why.

CmonDev• 13 years ago

I think that's obvious: forces you to stick with one specific legacy dynamic weak-typed language.

camus• 13 years ago

This is not a democracy.

I agree 100%. But still, a lot of people are complaining about some of the Node.js API choices.

They are complaining because it makes programming more difficult , and the truth is , async programming is hard when it relies on callbacks.

hvs• 13 years ago

Wasn't that the original selling point of Node? That it used callbacks for async and that it was easier that way?

wmf• 13 years ago

No, the original selling point was that Node forces all code to be async and Erlang is too weird.

drderidder• 13 years ago

Not the original point perhaps, but its come around to that. A couple years ago they settled on callbacks after a fairly active debate, as the least ambiguous option for continuation passing. As more people explore Node, callbacks are one level of abstraction too deep or just too tedious for some people. Fortunately there's a great selection of asynch modules to help them.

jchrisa2• 13 years ago

I thought the original point was that it is JavaScript that can do stuff.

dragonwriter2• 13 years ago

The main selling point of Node was that it was JavaScript, and since you are going to have to use that on the front-end anyway, you might was well use it on the backend.

I've never seen anyone argue that callbacks are one of the easier ways of doing async.

arxpoetica3• 13 years ago

I've personally never had issues with the callback pattern. To the contrary, it forces me to have well-organized code, which is a ++.

CyruzDraxs4• 13 years ago

It was easier until we discovered even cleaner ways, and most of the Javascript community began to adopt them. But node chose to stick to the "old" ways. (Not really old, but not as shiny and new as the alternatives)

I feel like promises don't need to be part of core though. It's easy enough to wrap the standard library in userland and just have other things depend on the wrappers.

olegp• 13 years ago

You can use fibers. We are doing that via common-node (https://github.com/olegp/common-node/) and are very happy with the choice at https://starthq.com

nadaviv• 13 years ago

ES6's generators and the `yield` keyword plays very nicely with callback-based code, doesn't require any changes to the underlying libraries and gives you a much nicer syntax to work with.

See https://github.com/visionmedia/co

JoshGlazebrook• 13 years ago

I've been looking at another library like the one you linked. Essentially the "yield" keyword can be compared to "await" in C#.

https://github.com/bjouhier/galaxy

9999• 13 years ago

A lot of short node.js code snippets you run into on the web use anonymous callbacks, and I agree, that gets ugly very quickly, but if you bind callbacks to methods on prototypes the code remains pretty readable.

dclowd99012• 13 years ago

I don't understand. Can you not just roll in a promises library (like Q)and call it a day?

mattyod3• 13 years ago

Why would you when someone already rolled a promises library like Q?

driverdan2• 13 years ago

As the post said, there are plenty of libs that add additional functionality in place of callbacks. Let everyone choose the way that works best for them.

ilaksh4• 13 years ago

Take a look at ToffeeScript https://github.com/jiangmiao/toffee-script

kailuowang• 13 years ago

Callbacks will remain the de facto way to implement
asynchrony. Generators and Promises are interesting and
will remain a userland option. "

I am seeking for a comparable alternative to node (or something on top of node) in which Promises are the de facto way to implement async. Any suggestions?

halayli• 13 years ago

Checkout C++11. It has lambda callbacks, promises/futures and async with threading.

usea2• 13 years ago

I don't think C++11 is a comparable alternative to node, personally. Although I understand that's a subjective judgment on my part.

uniclaude• 13 years ago

Is the fact that they use callbacks instead of Promises outside of userland a real problem for you (as an application developer)?

You can totally write your node applications using only Promises using something like Q if you feel like it.

bryanlarsen• 13 years ago

It probably would be fairly straightforward to write a generator that wrapped every function in a module with Q.nfcall.

abecedarius• 13 years ago

The E language http://erights.org/ works that way. It's unfortunately been inactive for years; its BDFL moved on to the Javascript committee.

fizx• 13 years ago

Scala+finagle is comparable in use cases, but scala isn't very close to javascript. Perhaps still worth looking into though.

agilord• 13 years ago

Dart. Look for Future and Stream.

spankalee• 13 years ago

Dart is very Node-like is that it's event based, but almost all async APIs are based on Future and Streams, including all IO, and therefore any other packages that do IO, like database drivers. This makes things very consistent and composable.

On top of that you get to use a much nicer language than JavaScript.

ilaksh4• 13 years ago

Take a look at CoffeeScript (cleaner callbacks) and ToffeeScript (callbacks hidden, just look like sync code). Those are much better solutions that promises.

domenicd• 13 years ago

You may find https://npmjs.org/package/pr useful.

dustingetz• 13 years ago

node + clojurescript. you can do better than promises.

http://swannodette.github.io/2013/07/12/communicating-sequen...

dpweb• 13 years ago

Sound good on all those. Completely dropped PHP for Node, no regrets.. Good because those breaking changes in Express v2-3 were annoying..

CyruzDraxs4• 13 years ago

That's what semantic versioning is for. Node modules should continue to move forward, and reinvent themselves to improve how we write our apps. Otherwise it'll just turn into another PHP.

gkoberger• 13 years ago

Only tangentially related, but the "rant" by Ryan Dahl (node creator) when he left Node day-to-day is worth a read:

https://gist.github.com/cookrn/4015437

palvaro• 13 years ago

sorry, why did you say that was worth a read? it doesn't appear to have any content.

lhnz• 13 years ago

You could possibly draw a connection between Ryan Dahl pleading for simplicity in that gist, and Isaac Schuetler claiming that they would not be adding extra complexity to Node.JS.

By the way, your post comes off as unnecessarily rude.

javis• 13 years ago

I thought it was good.

z0r• 13 years ago

I wonder if Ryan Dahl is following in Chuck Moore's footsteps now.

http://www.ultratechnology.com/forth.htm

aroman2• 13 years ago

To use his language, I agree that the "whole thing fucked", but I also think it's fun. I enjoy the fact that things are a challenge and sometimes quirky.

Sure, down in the trenches it makes you want to pull your hear out. And the world would probably be more productive if software interfaces and programming languages were completely frictionless. But it would also make programming, to me, less fun, challenging, and enjoyable.

We are imperfect beings living in an imperfect world, and I don't think changing the status of either or the former or the latter would create the nirvana ry is alluding to.

coldtea3• 13 years ago

To use his language, I agree that the "whole thing fucked", but I also think it's fun. I enjoy the fact that things are a challenge and sometimes quirky.

The problem is that the wrong things are fucked and that's neither challenging nor fun.

E.g configuring some system so you can get your software built correctly is neither fun not challenging. It's merely tedious busy-work. Actually solving problems, that's the fun part.

enobrev• 13 years ago

I certainly appreciate Ryan Dahl's opinion and absolutely agree with the conclusion (which has done incredibly well for me in my career), but these things are not mutually exclusive. One can put user experience above all and still hone their tools and habits while working towards that goal.

grannyg00se2• 13 years ago

"The only thing that matters in software is the experience of the user."

Hell no. Software comes from software development. And software development is a process. My editor, programming style, directory structures and other personal organizational behaviours do matter. This is work we do, and while the end user's experience may be identical regardless of very different personal development style options, the one which gives me the most comfort and work satisfaction is superior. So yes, I will configure my editor so that I don't have to keep repeating the same keystrokes dozens of times throughout the day. I will align things the way I see fit, and I will endeavour to study and improve my skill with the language. Not only so that I'm more efficient, but because it will bring increased contentment to the process of development.

coldtea3• 13 years ago

Hell no. Software comes from software development. And software development is a process. My editor, programming style, directory structures and other personal organizational behaviours do matter. This is work we do, and while the end user's experience may be identical regardless of very different personal development style options, the one which gives me the most comfort and work satisfaction is superior.

Only nobody cares about you.

As in a restaurant, people care about the food, not the cook.

And even if you (and I) mattered, developers of a piece of software are N, where users are 1000N or 100000000N. They matter massively more.

Oh, and there will always be programmers as long as there are money to be made, so the "without me [in particular] there would be no software" argument doesn't hold much either.

mythz• 13 years ago

Technology is just a tool, for the purpose of solving end-user's problems.

Spoiler: Most software you create wont be around in 10 years: http://www.youtube.com/watch?v=zut2NLMVL_k&feature=youtu.be

What matters is the value it delivers in the meantime, which is ultimately the end-user result - not how you got there.

jdub• 13 years ago

Software developers are users who experience software. Might be a different category of software, but user experience is still king.

dictum• 13 years ago

The only thing that matters in software is the experience of the user.

That is true, but the experience of the people developing the software matters too, as it informs the care that will be put into creating a better user experience.

Let's say you're creating an application and you're the sole developer and designer of that application. When you have a predictable and reliable development environment that emphasizes good, well defined practices, you reach a state of flow with more ease when you're coding, and your project gets developed faster. Faster development allows you to iterate quickly and better test your assumptions about the user interface and the overall user experience. It gives you more time to design the application. All in all, with a better development experience, the developer gets more time to create a better experience for the user.

I bet Ryan's frustrations—all the abstractions and crappy interfaces—come from years of legacy technologies and the need for compatibility and integration with other systems, and sometimes as preemptive measures to avoid security issues. When they were made, there was a reason for their existence.

chrisrogers• 13 years ago

Consider systems like the GDS infrastructure backing the travel industry. These systems are long-lived (50y+) and are the backbone of all travel booking and scheduling. The only thing that matters for them is not the end user experience, it's the stability of the system, and society's reliance upon its operation. It's robust and it was produced at the right time to carry an industry into the efficient monster it needed to be to succeed. A whole industry was built on it layer by layer, and what we now have is a complex beast composed of ancient IBM hardware, crazy nested and disparate schemas, greenscreen scrapers, and probably more than a few dashes of COBOL. One can't expect the system to stop evolving while we take a 5 year breather to rewrite it all.

100983• 13 years ago

This guy is either pretending to be an idiot or really does not appear to understand just how complex everything is. The whole "thing" that is "fucked" is there to manage that insane complexity. If you don't have good tools, good libraries or don't know how to use them, you won't be able to deliver on your promise of "solving the problem", because you will be overwhelmed by the complexity monster.

I'm sorry, I just can't get over it. "Just solve the problem" - I hate that attitude. That's how shitty software is born. Incompetent schmucks give birth to unholy, unmaintainable, monolithic code because they think it's okay to not know your shit as long as you "solve" the problem.

ulisesrmzroche6• 13 years ago

Ryan Dahl created Node. He's not just some schmuck.

msutherl2• 13 years ago

Yo, the point is that the complexity is there because the well-intentioned and simple underlying systems were not properly scaled to meet the demands of modern applications. At no point does he suggest that you should eschew the tools that are in place to maintain the current complexity – that would be nonsensical, as you pointed out. He's arguing that we should use the system as it was designed, if that's at all possible, or re-architect the system to handle modern application complexity without increasing system complexity unnecessarily. Achieving this would be near impossible – see Plan9, Minix, VPRI, and Squeak for "failed" attempts – hence this being a rant and not a serious proposal.

Note also that Ryan is a mathematician. Mathematicians hate engineering because there's nothing to protect real-world systems from little accidents that compound over time. No proof, no piece of code, no matter how elegant, can reverse the thousands of bad design decisions that have resulted in the modern Linux ecosystem.

e12e3• 13 years ago

This seems to parallel some of the work VPRI is doing, eg from:

http://www.vpri.org/pdf/tr2010004_steps10.pdf

STEPS Toward Expressive Programming Systems, 2010 Progress Report Submitted to the National Science Foundation (NSF) October 2010 Alan Kay et al

"If computing is important—for daily life, learning, business, national defense, jobs, and more — then qualitatively advancing computing is extremely important. For example, many software systems today are made from millions to hundreds of millions of lines of program code that is too large, complex and fragile to be improved, fixed, or integrated. (One hundred million lines of code at 50 lines per page is 5000 books of 400 pages each! This is beyond human scale.) What if this could be made literally 1000 times smaller — or more? And made more powerful, clear, simple, and robust? This would bring one of the most important technologies of our time from a state that is almost out of human reach—and dangerously close to being out of control—back into human scale.

(...)

Previous STEPS Results

The first three years were devoted to making much smaller, simpler, and more readable versions of many of the prime parts of personal computing, including: graphics and sound, viewing/windowing, UIs, text, composition, cells, TCP/IP, etc. These have turned out well (they are chronicled in previous NSF reports and in our papers and memos). For example, essentially all of standard personal computing graphics can be created from scratch in the Nile language in a little more than 300 lines of code. Nile itself can be made in a little over 100 lines of code in the OMeta metalanguage, and optimized to run acceptably in real‐time (also in OMeta) in another 700 lines. OMeta can be made in itself and optimized in about 100 lines of code."

http://www.vpri.org/html/writings.php

woah• 13 years ago

did this stuff actually work?

tipiirai• 13 years ago

He is so right! No wonder why he wrote such beautiful and useful piece of software. A sort of genius. Thank you, Ryan!

avolcano3• 13 years ago

There will be no changes to the module system. None. It's finished. It's been finished for over a year. Any proposed changes must come with a clear reproducible bug that cannot be worked around or addressed with documentation.

This seems short-sighted, with ES6 modules now being used in production (through transpilers) and slowly making its way into SpiderMonkey and, more importantly, V8.

jlongster• 13 years ago

It is a shame, but I just don't know how node would migrate to ES6 modules. I'm sure someone smarter than me could think up of a plan, but it seems like a huge amount of work. One of the strongest points about node is the amount of small reusable libraries available. They aren't about to ditch that.

avolcano3• 13 years ago

Some thought has definitely been put into this problem:

https://gist.github.com/domenic/4748675

https://gist.github.com/wycats/51c96e3adcdb3a68cbc3#importin...

(both of those are slightly out of date, syntax-wise, but are still conceptually current, IIRC)

callmeed2• 13 years ago

Can someone please explain Node.js's relationship with Joyent? I like what I've seen/done with Node but I've had less-than-stellar experiences with Joyent in the past. I'm hesitant to devote additional time to it if they are very tightly coupled.

Is it similar to Go or Angular @ Google?

One thing I love about Rails is that it exists quite separately from 37signals or any other company. I don't get that feeling with Node/Joyent, but maybe I'm wrong.

CyruzDraxs4• 13 years ago

Node is not really tied to Joyent. Actually, a good amount of the core team is at StrongLoop.

Joyent has basically got it as far as they needed it to get for their own uses. Now they are just sitting on it and keeping it stable while letting userland modules cover future expansion.

IsaacSchlueter• 13 years ago

Joyent owns the trademark and copyright on the IP related to Node.js. (Logo, "Node.js" mark, etc.) They also are involved with marketing, legal, etc.

The active core committers over the last month, and their employers, in order of whether or not they're me:

- Isaac Z. Schlueter (npm author/admin, lead gatekeeper, stream maintainer, javascripter), Joyent

- Ben Noordhuis (issues list champion, most opinionated C++ developer, libuv unix guy), StrongLoop

- TJ Fontaine (build owner, C shim author, tracing afficianado, Master of Robots), Joyent

- Trevor Norris (performance perfectionist, master of dirty hacks), Mozilla

- Fedor Indutny (russian ninja rockstar, TLS tamer), Voxer

Also very important to the project are Bert Belder (Windows guy, libuv co-author) at StrongLoop, and Scott Blomquist (Windows bug-chaser, Microsoft liason) at Microsoft.

Honorable Mention to Ryan Dahl (Node.js creator, BDFL) who is currently off being a professional hipster somewhere in NYC, and not involved with the project. When he did work on Node, he was paid by Joyent, and he got some money for selling the copyright to the company as well.

The Node.js community experience would be much less pleasant if not for Nodejitsu's continued support of the public npm registry. (Nodejitsu acquired IrisCouch a few months ago.)

Node would continue on even if Joyent bit the dust. (Depending on who assumed ownership of the mark, it may or may not have to change name/logo.)

If you've had a bad experience in the past with Joyent, it probably has nothing to do with the experience you might have with Node.js. I am given free reign here to manage the project free of any overt Joyent influence. Joyent is a big Node user, and a lot of really smart people, so I do take it seriously if they have something to say. Especially considering that most of the time when Joyent engineers have a problem with Node, it's related to other users hosted on their platform (Walmart, Voxer, etc.)

callmeed2• 13 years ago

Cool, thanks for the thorough reply.

jenius• 13 years ago

Synchronous child process execution is being added, at long last.

Thank the jesus. This will be nice to have, especially for some command line and filesystem operations.

swang• 13 years ago

Yes, best part since the node module we are currently using does not work in v0.10 and the author is very adamant about not supporting it anymore.

asaarinen2• 13 years ago

I applaud the Node developers for their effort. While recent "competitors" like Go are fascinating and in some ways even arguably better, the fact that every device on earth runs JavaScript makes me bet that Node will prevail.

Computing will need to move fluently between the cloud and the terminal, and JavaScript is the only language which allows you to use a single codebase for both (in the foreseeable future). As developer time will stay the biggest expense when developing software, I am bullish on Node and JavaScript.

tikhonj• 13 years ago

These days virtually every language can be compiled to JavaScript in a very usable manner. For example, I've had a lot of success with js_of_ocaml[1], not really running into any of the problems people like to harp about regarding compiled-to-JS languages.

[1]: ocsigen.org/js_of_ocaml/

The argument for developer time--as well as decreased maintenance cost--is exactly why I went with OCaml over pure JavaScript. And so far it's certainly paid off!

asaarinen2• 13 years ago

Sure, but the language that _every_ developer will need to know is JavaScript, not OCaml or some other of the dozen alternatives that can be compiled to JS.

Besides, the ability to compile to JS is not enough; you will need to read it in JS, debug it in JS and let other developers work on it in JS (because they don't know OCaml).

rubyn00bie• 13 years ago

I disagree with the idea that "[...] every device on earth runs JavaScript makes me bet that Node will prevail."

Because Node does not strictly equal Javascript-- V8 is not Javascript, nor is spider monkey. Most node applications, without some modification, do not run in the browser. They are missing tons of libraries and cannot interact with the file system.

I do appreciate the ability to have a single codebase, but over the past few years, I've pivoted and hope to someone's god that it is NOT javascript. Mostly because, in my experience, Javascript itself, even with a great focus from the beginning, is incredibly difficult to maintain.

Even then, is having a codebase in one language the best idea? There are some things that are much better to write in Erlang than they are C, and vice versa. It depends on the problem you're trying to solve.

The bigger the project, the less Javascript I want in it.

I think ASM.js, or something similar, will be the death of writing Javascript. Then it won't matter what language it's written in, we can use source maps to debug and it'll be faster than we could've ever written by hand*

*single one off functions don't count. Try writing a webapp in pure x-86 assembly.

bfrog• 13 years ago

So callbacks are annoying enough that they have to mention its a non-fixable in the mailing list.

Awesome.

_random_2• 13 years ago

"TypeScript and CoffeeScript will not be added to core." "As new language features are added to V8, they'll make their way into Node."

Sigh... Let's leave this "future of programming" to the future then. I hope someone needs it.

pcunite2• 13 years ago

I'm new to web programming but I got the impression that C++ for web work was silly ... use PHP, use Rails, use this, blah, blah, everyone said. Now it seems that Node.js is just C++ style programming in JavaScript, expect that you get "packages" that manage the HTTP headers (and other things of course) for you.

It would be cool if someone makde a Node.C++. I would have less of a learning curve.

ricardobeat4• 13 years ago

You mean this https://github.com/d5/node.native? Godspeed.

oscargrouch• 13 years ago

i hit "casablanca" the other day from microsoft.. what impress me is that is open source and it also runs in linux. (not even in my wild dreams o would predict this to happen one day)

anyway.. looking at the source its pretty decent, and go right to the point.. of course its focused in HTTP/REST..

theres a bultin IO scheduler and a concurrent task system.. from microsoft.. who would say so :)

pcunite2• 13 years ago

Wow ... thanks for the info!

mark242• 13 years ago

I still, still, still don't understand why Node hasn't done in-line server-side Javascript.

Give it a snazzy name. Maybe.. "Livewire".

http://www.datacraft.com/livewire.html

jeffasinger• 13 years ago

I think the reason for this is that the industry in general has moved more to a MVC approach than this. No one wants to mix their server side code with HTML anymore. In fact, more and more, people want to delay the rendering of HTML until it hits the browser.

I don't think it would be very hard to to rewrite livewire as node module though, if you were really interested in it.

ilaksh4• 13 years ago

Of course its not part of core but certainly there are a number of modules for that although that's not especially popular these days.

https://github.com/visionmedia/ejs

ubershmekel• 13 years ago

You have PHP for that.

DonGateley• 13 years ago

My, god. Could they have possibly created any more or any more inscrutable jargon? Must have had whole teams dedicated to doing just that. Keeps out the riff raff I suppose.

The Future of Programming in Node.js

Related Stories