That said, you're still free to develop your API using your favorite technologies. To be honest, this is where the heavy lifting is, anyway, so it makes sense to have stronger typing, richer data types, etc. at this level.
I've had the opposite experience with the SPA projects I've worked on, one of them pretty large.
With the possible exception of authorization/authentication, the API for all my projects has been pretty straightforward, whereas the client-side app has been where I've missed stronger typing and rich data types most acutely, to the point where I've been actively evaluating compile-to-js alternatives with a better/safer type system.
However, with the advent of Facebook's Flow, I might just stick with JS.
Then I found out about ReactJS.NET [0] which allows for server-side rendering of ReactJS components from ASP.NET. I haven't had a chance to try it out properly yet but my preliminary test of it made it seem plausible for creating isomorphic apps in ASP.NET. Have you given it a shot? If so, what are your thoughts?
It is possible to build extremely dynamic websites that are not SPAs. It is possible to do it in a relatively straightforward fashion. (Using something similar to web components.) So why move?
I love it though.
No,it's way too low level to be "the new PHP",and frankly async programming is hard,way harder than writing sync code by default.
Most of all to me node is fun which is especially important when you have to conquer problems in un-fun environments (most Bigco systems).
(This is the best link I can find quickly: https://www.paypal-engineering.com/2013/11/22/node-js-at-pay... I am sure there are more.)
Slides: http://www.slideshare.net/jeharrell/9-antipatterns-for-nodej...
Related: https://news.ycombinator.com/item?id=6784967 http://venturebeat.com/2012/01/24/why-walmart-is-using-node-...
http://www.joyent.com/blog/walmart-node-js-memory-leak
Eran's recounting of the issue: https://www.joyent.com/developers/videos/walmart-node-js-mem...
It's interesting to note despite the memory link, the incredible amount of traffic WalMart was handling with its Mobile apps running on NodeJS. That's what was more impressive to me.
While there are definitely dedicated server-side and client side JS people, speaking the "same language" helps within teams and allows for some shared responsibilities.
That's appealing to large organizations with decent turnover.
Server side rendering takes time, even 10 ms. On an single event loop, that is terrible. You can only server 100 request/second due to the 10 ms limit. While it is nice that you can move a request into the backing queue while waiting for the data, you're capped at 100 requests/second.
Where I think Node shines is low level network management. Netflix could use it to pipe video data from one of its boxes out to a user. It's got that kind of work built right into it. As a result, I think that storage, spooling and possibly even sending would be best in Node. Those are largely I/O bound, schlep data from port to port operations.
My understanding of PHP is that it's really hard to have really global variables. Compare this to Node.js where Javascript naturally does this. I can't find it now, but I remember back when Node was young a guy had an issue with his shopping cart system. People's orders were screwed up. Turns out that he missed a `var` in a function. PHP, I don't think, could do this easily since the widest screw up scope is file. So you're still limited to request scoping.
Why??
... badly written JS, sad, unfortunately that's the fact.
I am really too stupid to get it. "Single language for a whole stack" is a pretty stupid Java-sque argument, a naive assumption that one single language is good for all kinds of tasks.
Sharing code between client and server lets reduce duplication and use the same templating/rendering on both sides. Fits very well with complex single-page apps.
That said, I'm not sure there are that many apps that really need this vs. the tradeoffs you have to make going all-in on JS and the complexity this can bring.
I'm writing apps from the ground up using React and I've found the isomorphic bits take <10 lines of code as long as you design for it from the start.
As for blocking, it's something you deal with. Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution. However, if you're doing tasks that are IO oriented then Node is fantastic.
Here's the answer:
Spawn $(nproc) more Node processes, use IPC if you need to.
Good luck seizing the theoretical performance gains one might see from threading (while not falling victim to diminishing returns related to context switching) in another comparable language.
For stateless web requests (solving the C10x problem), this is not inherently bad for most applications.
> which blocks the whole app if a single function blocks
This is behavior you'll see in many other languages.
Management of execution time is very prevalent in lower-level languages. The only languages not susceptible to this problem are high-level, preemption-capable, and possess some form of green threading/scheduler e.g. Erlang/Elixir.
IMO, if you need to rely on a scheduler to help ensure that blocking doesn't occur in a disruptive fashion, you're in no position to deride those who "began as a webdevs and knows nothing better."
> asynchronous call-back hells
This is a matter of taste, opinion, and necessity.
I personally hold the opinion that "callback hell" is a symptom of poor design, and properly managed callbacks are not unpleasant to work with (I may be subject to Stockholm Syndrome).
Also, try implementing an equivalent non-blocking webserver around an event loop in a lower-level language and let me know what non-callback strategies you come up with for the coalescence of asynchronous events.
As an aside, there are hundreds of different ways to improve or eliminate the composition of callbacks in JS: emulated coroutines via generators, C#-style implementations of async/await, promises, the list goes on.
> non-functional but GC'ed language
Which functional programming languages in common use aren't garbage collected? (again: in common use)
Which other common, productive, high-level programming languages (often tasked for C10K web servers) aren't garbage collected?
What does "non-functional but GC'ed" actually mean? What does the language's programming paradigm have to do with its memory management model in this context?
> I am really too stupid to get it
- People are productive and enjoy JavaScript. - Browsers, by and large, only run JavaScript code. - JavaScript on the server-side is a very capable, battle-tested building block for performant web software. - Admittedly: JavaScript is not a great language when compared to other modern programming languages. - Aforementioned opinionated gotchas aren't enough to dissuade communities from using JS.
If you have broken your code up into small enough modules and functions, and you know which tasks depend on other tasks, you will not have callback hell.
If you are unclear on the logic of your code, you can often make it work in a messy way with the "laundry list approach". This involves formulating a sequence of tasks that happens to work, without needing to understand the actual dependencies. Many synchronous languages facilitate a laundry list approach, as their inefficient blocking paradigm removes the need to formulate the laundry list as a sequence of nested callbacks. It's still messy code.
No. It's an indication that you're using a FOTM runtime environment. There's a reason why no production-ready runtime uses continous passing / callback models.
Weak types: Check out Facebook Flow or TypeScript.
Global namespace: Not true with require/modules.
Ambiguous/unexpected behavior... please explain? You could use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.
As for blocking, if you are doing something that is blocking in your main event-loop, you're probably doing something wrong. Break it off into a req/res queue and let it flow.
Regarding call-back hell... you have next-generation tooling like co/koa as well as ES6 Promise patterns you can use. Not to mention the async library.
You can readily follow functional patterns in JS and Node... just because there is prototype based inheritance doesn't mean you need to use it, and most of the time, I don't.
Also, Node itself isn't really single-threaded... the main event loop is, which is where your JS code runs. The underlying platform calls are running against a thread pool.
I have worked with javascript for years but it was always for DOM manipulation. When it comes to building an app with javascript, i feel like it is too fragile to depend on.
Anyone can help me to get rid of this feeling?
The core language (syntax, available directives) hasn't changed much since the time everyone deservedly hated it. Its performance was optimized, it got many more libraries and it is still the only language supported by browsers. But the question is, why all of this applies to JavaScript and not Python/Ruby/whatever?
A lot of its benefits people claim simply weren't around when they chose to stick with it. It's like saying you chose IIS over Apache because of features of C# 5.0 and ignoring the fact that you chose IIS in 2004, where C# 5.0 was not around. It's a dishonest argument.
Speaking of which. How can people claim that JS benefits from the same language running on client and server when 90% of server-side libraries do not work on the client and there are potentially major differences even in core library (e.g. forEach)?
Also, a huge part of JS ecosystem are kludges, crutches and workarounds that make the stack way, way more complex that it should be. (E.g. source maps. Imagine someone minifying PHP for faster parsing and then asking everyone to use some source mapping technology for debugging. They would be laughed out of any conference or discussion.) This mentality permeates everything. I mean, seriously, require directives need to be implemented as a library? Namespace isolation is a closure-based hack? Can you imaging stuff like that being tolerate for any other language?
Source maps or debugging symbols have been accepted for compiled languages for a long time.
1. Cooperative multitasking. Really? In 2014? Hello?
2. Weakest of weak typing. undefined is not a function? Anyone?
3. Everyone can override everything.
4. Conventions, that's the only way you can build software in JS. Anyone know of a person who doesn't break conventions?
Having programmed in something like Erlang, which IMHO is the sanest technology available today for doing web, JS feels horrible.
Software development is one part creation, one part understanding existing software, and one part changing existing stuff. Javascript has proven a bit difficult on the last part.
I don't think you can necessarily overcome the deep-seated knowledge that the language is hot garbage. You can learn to use tools to reduce it and understand the language enough to realize where its truly horrific spots.
I don't think the other "scripting" languages like Ruby, Python, and PHP stand much of a chance against it in the longer term. They just don't have the resources to compete.
Have you checked out the Computer Benchmarks Game? Here are some benchmarks they provide, comparing the JavaScript V8 to Python [1], Ruby [2], and PHP [3].
Looking at statistics such as these, I'm left thinking, "1. This is awesome! 2. Is there something about these other languages that prevents V8-like performance, or is this more a matter of browser performance being highly invested in by Google, Mozilla, etc.?"
[1] http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
[2] http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
[3] http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
A somewhat more fair comparison would be V8 vs. PyPy, Rubinius/RuJIT, HHVM, and LuaJIT. LuaJIT and V8 would likely still come out on top due to the amount of work and sheer excellent engineering put into the compilers (and in LuaJIT's case, also the interpreter), but PyPy's performance should be a lot better than CPython's for these benchmarks.
I also imagine (though am mostly speculating) that a benchmark involving a full-stack frontend framework like Angular or Ember, with hundreds or thousands of JS objects and lots of DOM manipulation, should put V8's performance a bit closer to CPython's.
The comparisons they do is not of idiomatic code... for example in python they do a lot of array programming and don't use numpy (http://www.numpy.org/). So for most languages the results in there are completely meaningless.
1. Bluebird with longStackTraces, [1] to get complete stack traces for an entire chain of async operations with minimal performance penalty, and
2. node-debug from node-inspector [2] as a debugger (same UI and features as chrome dev tools)
[1]: https://github.com/petkaantonov/bluebird [2]: https://github.com/node-inspector/node-inspector
As the companies I work(ed) for evolve from JS => jQuery => Backbone.JS => Backbone.JS + Marionette => EmberJS, so does my skill have to evolve. I also have to write some JS code on top of PhantomJS + CasperJS (not for automation testing but instead for performance monitoring) to support enterprise product at the moment.
I used to hate JS with passion but now after seeing Chromebook, Chrome Apps, NodeJS, and my current favorite: MeteorJS. I just have to suck it up and learn JS to be honest...
Would I bet an enterprise app to use NodeJS if it was using my own money? Probably No. Would I bet my weekend projects and ideas on NodeJS/EmberJS/JS? Yes.
I think the JS ecosystem is still unstable and a big mess but let's hope it moves to a better direction.
File under "damning with faint praise", methinks. Not sure what it means if the "not all that bad" version is one that doesn't run natively anywhere yet...
(edited for clarification)
And those who say Yahoo! are just jumping onboard the React hype train or Node.js hype train, you have it all wrong. Yahoo! have been using Node.js for the last few years, in-fact early 2010 is around the time Yahoo! engineers started playing with Node.js, long before it was considered mainstream cool or being used really in any high-profile scale environment.
It is rare that a company the size of Yahoo! truly ever embraces moving at this kind of pace and embracing new open source technologies, languages, frameworks and libraries. Now that Yahoo! have openly declared their use of React on such a large scale, expect it to explode even more so in 2015. For an open source project that is a little over a year old, React is getting the kind of user-base and adoption that most open source projects can only dream of having.
This news excites me. I honestly cannot wait to see how it all turns out.
PS. I have noticed a few people in the comments section getting confused. Yahoo! Mail is NOT using React just yet. The current mail product is still using YUI and plain HTML/Javascript. If you read through, it mentions 2015...
Another option (albeit currently an undocumented one) is to use contexts to obviate the need to pass things down manually: http://davehking.com/2014/11/15/introduction-to-contexts-in-...
They're joining the likes of Facebook, Netflix, Square, Microsoft, Instagram, Khan Academy, SoundCloud, Trello, New York Times, and others in adopting reactive extensions.
[1] http://www.reactivemanifesto.org/What exactly do you mean by reactive here? As one of the other posters said, react's 're-render the virtual dom' concept doesn't have any direct relationship with the reactive manifesto, though flux might be a better candidate.
https://github.com/yahoo/dispatchr
Reflux is a great solution when you need to coordinate between multiple components.
But seriously you're on HN and you're upset about people arguing/discussing a web technology? I don't even see one mention of "m'lady"
On the topic of JavaScript - I love Node as a glue. For larger applications - I just don't know how to structure (architect) a large application on a language like JS. Maybe that's just my ignorance.
The Clojure + ClojureScript approach has many more batteries included. You get all the benefits of reusing the codebase on both sides of the fence while the language is solving the "Transactional Store", efficient dirty checks, nice server-side concurrency primitives and many unrelated problems for you.
I've been using and enjoying React and am excited to learn more about Reagent. It seems like Clojure + Reagent will make development quicker and more enjoyable.
https://medium.com/code-adventures/farewell-node-js-4ba9e7f3...
Anyone experience the same?
He also says that node isn't moving fast anymore, which is unfortunately true. The node core team was stuck trying to release 0.12 for quite a while because of some significant changes to internals (V8, AsyncListener). Once 0.12 is out, things should be much easier. On the plus side, the ecosystem is still moving at the same speed which is pretty great, and JS gets new advanced tooling every day: typescript, flow, 5 (!) es6 compilers...
I think Javascript is fun and easy to use. That's good enough for me.
That it helps preserve balance with iOS and Android in the "software eating the world" conversation, is a bonus.
In the last years JavaScript has exploded with new frameworks and "compile to JS languages". But I have yet seen anything close to usable. Maybe it's because I've become "speed blind" after coding JS for over 15 years. I do not see all the problems ppl see in JavaScript, until I look at code written by beginners that seem to use every framework out there, and over-complicate the code, and naming everything with one letter variables and the name of their favorite pizzas.
Boy oh boy do I wish that were the case.
It seems that every job, even backend positions, require Angularjs or Backbone.js knowledge. Having largely ignored the two and hoping they would die, I am ready to learn React + Flux to accelerate to this cause.