181–190 of 301 posts
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.
Earlier quoted context omitted.
node.js is the new PHP for hip web developers who read HN. It's still a relatively unheard of platform to most people and mocked by a lot as well. I love it though.
Disagree. It seems half the industry is moving to node in NYC. All the major publishers (NYC tech's bread and butter) are using it or switching to it.
Also try talking about node on proggit, you'll get mocked and told how dumb and shitty it is.
Earlier quoted context omitted.
I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.
I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could u…
Earlier quoted context omitted.
> It is possible to build extremely dynamic websites that are not SPAs Possible, but not easier.
Highly debatable. I've had great success developing highly dynamic websites using progressive enhancement and directive/web component like approach. People often smirk when I mention progressive enhancement these days. But the same people often claim that something is "impossible" to do using PE, while it's not only possible, but downwright easy. This makes me think most of them never even tried this approach serious…
To put it another way, when you design transactional first, you actually design a very good approach to your business layer public interface. If you do that step right, you can do the next two with minimal effort:
1. An application API;
2. Client side javascript for improving the UI of common operations.
Single page applications often smell like the Windows Forms applications of old: A convoluted spaghetti of application states linked by insignificant events and event handlers, where the boundary between business logic and user interface is fuzzy or non-existent.
Earlier quoted context omitted.
Well, if you are like me, who worked with PHP for years, node.js feels nicer to use. Npm alone makes it better than PHP ever was.
NPM is great, haven't used PHP but it blows Python's pip out of the water IMO.
Earlier quoted context omitted.
Writing something in PHP made sense in 2004. Although Erlang was around at the time, it wasn't at all well known. And no, you are not absolutely right, Facebook is not a PHP (only) shop. Their chat backend is in Erlang and that's a much bigger tell-tale than their legacy code. Also, a lot of us Erlangers speculate that Facebook bought WhatsApp (not only but also) because of their huge infrastructure know-how and (Erl…
> Their chat backend is in Erlang Not true anymore. They switched away from Erlang because of reliability and scaling problems. So saying that mega-user server side is a solved problem because of Erlang feels like a stretch.
Earlier quoted context omitted.
All of these are valid points except 1. Node's async IO is one of its strengths. Contrast with Rails, for example, where the standard practice for concurrency is to spawn multiple processes (or, less commonly, threads). How many Rails processes can you fit on one machine? 5-10? Node can handle thousands of concurrent connections, all on a single thread. And when you hit those limits, you can always continue scaling w…
> All of these are valid points except 1. I have another counter-point for this as a rails developer tinkering with golang recently. I think Go got this correct in many ways. Having light weight goroutines that can scale well; having good IO which does epoll/libuv style wait in the background transparently when you read/write. Easy to understand multiprocessing language in general. I have no idea why it's not taking…
Why on Earth people who aren't merely enthusiasts of "cool async JavaScript with V8" or those who began as a webdevs and knows nothing better than JS and PHP, could choose a single-threaded solution, which blocks the whole app if a single function blocks, and forces programmers to write spaghetti wrappers around asynchronous call-back hells in a non-functional but GC'ed language? I am really too stupid to get it. "Si…
One argument for one language everywhere is the benefits you get from an "isomorphic" app ( http://nerds.airbnb.com/isomorphic-javascript-future-web-app... ) 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…
Earlier quoted context omitted.
I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.
I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time. Weak types: Check out Facebook Flow or TypeScript. Global namespace: Not true with require/modules. Ambiguous/unexpected behavior... please explain? You could u…
You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least.
I echoed other comments: JS ecosystem is unstable and confusing at the moment.
Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.
I've been a Javascript and Node skeptic for years now but I think the tide is finally turning. So much time and energy has been poured into making JS better that it's finally starting to pay off. Javascript with all the ES6 enhancements is really not a bad language. The runtime performance is already very good and continually getting better. Tools like Typescript and Flow make dealing with larger code bases much easi…
I'm not sure if this is a troll, or if you actually think any non-web developers would volunteer to learn Javascript just to write application code.
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.