The downvote clearly shows that someone here is lacking maturity. Downvoting because you don't like what was said is mindless censorship.

Also, I like your point about emotional investment. I am way too emotionally invested when it comes to drink driving. I lost both parents to a drunk driver and I would happily see hanged any drink driver. This is an emotional response rather than a logical one and this is why people with too much emotional investment shouldn't make the rules. Their input is definitely needed though.

My guess as to the reason for the downvote is that once he veered into making personal comments on my state of mind, he was engaged in ad hominem. No matter how good or bad his points, that behavior is discouraged.

On whether I am too emotionally invested, if my points had been imbued with excessive emotion, that would have been one thing. But they were not. My big point was, "This potentially addresses a real problem in trying to reach abused children, and we should collect data on whether it actually works." I believe that to be a fairly neutral point.

Once we have data, we can revisit this with information of the form, "We had 5 complaints and 2 children called our hotline because of a sign that was seen fairly regularly by an estimated 1000 children." At that point we can try to find a balance between people who had a mildly unpleasant conversation with their children, and children who no longer have absolutely horrible things happening to them.

But until we have that data, we can't productively have those conversations. Clearly abuse is orders of magnitude worse than being confronted with an unpleasant and possibly confusing sign. Clearly more normal children are going to be confronting that sign than are going to see abuse stopped. How do these opposing interest balance? Nobody can tell because we don't know what portion of people who see the sign are disturbed by it, and we don't know how many abused children will actually respond to it.

So we should run the experiment and collect data.

Of course, I go to a university that seems very biased towards practical engineering sorts of topics over theory, so your experience may vary.

Except for basic stuff like set theory and Boolean logic, math was for the required math classes.

I didn't get the background really necessary to really understand the type-theory parts of this notation until I took a graduate course in programming language theory.

Personally, I loved studying CS (my degree was in logic so I straddled the worlds of Math and CS). It's a topic I find infinitely interesting.

Having siad that, Engineering is also very interesting. All the CS theory in the world isn't going to save you when you're trying to complete a large system full of lots of moving parts - many of whom are developers :)

At least it was so when I graduated many many moons ago.

What's the point of my learning yetAnother.js?

Why the down vote? I'm asking serious questions that as a professional software engineer, I worry about. The two devs next to me have expressed similar feelings when I told them about this article.

Down voting me because you don't like what I said is against the HN guidelines.

> Is Ember.js actually worth learning? What's the point of my learning yetAnother.js?

You're a Java developer, so it may be harder for you to understand the productivity boon that frameworks like Ember.js and Angular.js provide than it is for people who have been dealing with jQuery spaghetti code on client-side javascript apps that have become increasingly more complex as browser javascript engines have become more capable. Ember.js, Angular.js, and other frameworks that offer two-way data binding are great because they take care of the dom manipulation details developers have typically had to manage by hand in the past. It frees people up to worry more about the business logic of their javascript apps. So if you're a javascript developer sick of writing boilerplate DOM manipulation code, Ember.js is definitely worth learning. I'm partial to Angular.js because it was built with testability in mind.

> Will it make me a better programmer (like learning Haskell will)?

Probably not, but it will make you a more productive programmer.

> Will it enable me to get a pay rise from my current £480 per day contracting fees?

If you're writing Java on your main contract, probably not. This is a bizarre question anyways and probably the source of your down-votes. I personally don't look at learning a new library or language in terms of how much extra money it will make me, but instead look at how much more productive it will make me as a programmer.

> Is there a more diverse and active job market than there is around my current main language (Java)?

I don't know much about the Java market, but I think it's safe to say that knowing Javascript cold and keeping up with the trends in that world will make you pretty darn employable these days.

Keep in mind that Ember.js and other frameworks like it are really only valuable to people who are writing single page javascript applications. If you aren't, or you are against the idea of building single-page applications, then these frameworks won't really do much for you. Although, you can still get some value out of them.

This is fairly true of ember specifically, but much less so for some of the other frameworks. Backbone and Angular, in particular, are very well suited for building "islands of richness" in otherwise traditional sites. Even if you're doing something relatively simple, like a form with live validations and inline error messages, you're going to have an easier time writing it with something to handle the DOM manipulation for you.

If you're wanting to get into frontend JS, start with Backbone. It's much less powerful than the other frameworks, but is by far the easiest to grok, and having it under your belt will give you enough tools to start moving larger and larger chunks of functionality into the browser. Come back to Ember once you outgrow that.

This was largely thanks to the fact that once I climbed the Ember.js learning curve, certain kinds of features became ridiculously easy to implement, and I had enough time to plow through the remaining problems with brute force. I also learned that (a) the unreleased Ember Data library is actually pretty good, but (b) getting into fights with Ember Data is catastrophic and never ends well. When Ember Data wants something specific, I fix the server to provide it and I don't argue.

But no, there's no way you can go look at a job board and find Ember jobs. It's more like how I remember Rails 0.13—there's an opening for certain aggressive businesses to develop software more quickly than before, but the tools are immature and there's not really a well-established job market yet.

Asking because I might have some influence over what technologies our company might use in the near future.

So the idea is that Ember may serve to fix one particular problem in my company... I don't see how it's any better than anything else. Just because I can knock out a basic web app in less time doesn't mean it's worth learning, especially when you add learning time into the development time and compare it to the Java equivalent.

Seems to me the use case (and job market) is small.

I wish I was still 22 years old and didn't need to care about earning decent money...

> Is Ember.js actually worth learning?

Yes.

> Will it make me a better programmer (like learning Haskell will)?

That depends on whether you've learnt the concepts that Ember introduces before or not. If you're stuck in a Java shaped rut, then yes. It will make you a better programmer.

> Will it enable me to get a pay rise from my current £480 per day contracting fees?

That depends whether you find someone who wants an Ember app that is willing to pay more than £480 per day. If you don't bother looking, then you're unlikely to find it. That said, if money is what you're after, there are many better avenues to go down than learning Ember or doing Java contracting.

> Is there a more diverse and active job market than there is around my current main language (Java)?

JavaScript is growing in popularity very quickly. If you wanted to switch to it from Java you wouldn't have any problems finding an interesting job.

> So the idea is that Ember may serve to fix one particular problem in my company... I don't see how it's any better than anything else. Just because I can knock out a basic web app in less time doesn't mean it's worth learning, especially when you add learning time into the development time and compare it to the Java equivalent.

You don't see how it's better because you haven't bothered learning it. By comparing it to the Java equivalent, I assume you mean GWT. In that case, yes. It's much better.

Ember isn't really designed for basic web apps. It's designed for big complicated web apps. I wouldn't recommend Ember for really basic web apps at all - it imposes a lot of structure that you only really see the benefit of when your app becomes larger.

> I wish I was still 22 years old and didn't need to care about earning decent money...

Never wish for something out of the past. It's gone. Look to the future instead.

Is Ember worth learning? Let's see.

It adds no value over anything that we already use or what I see being used elsewhere. It's just another library that doesn't add any significant.

There is not liquid job market with good salaries or day rates with Ember at the moment, you may be able to find one or two roles in London that ask for it but it's certainly not liquid and therefore could not support a contractor.

Embers approach is not radical therefore there's not a lot to learn here. I'm not stuck in a Java rut. You can write modern, slim, fast, concurrent Java. You don't have to be stuck in the days of massive J2EE government projects. The buzz around modern Java in London is massive.

You're right in saying that I could do other things for money but I love software development and I love that people are willing to pay be quite large salaries and day rates to do it. My career isn't money focused but money is a part of it. Why shouldn't I have a big house and holiday often just because I love writing code?

Also, seeing Java devs as being 'stuck in a rut' shows massive ignorance as to what is actually happening in the Java world right now.

You asked for an opinion. I gave you one (I'm in the middle of a large Ember project at the moment). I didn't expand on it as you appeared to have already made up your mind and written the whole thing off on the basis that the Java world keeps you pretty happy already.

> It adds no value over anything that we already use or what I see being used elsewhere. It's just another library that doesn't add any significant.

It sounds like you know a lot about it already. Why bother asking if it's worth learning then?

It's not a radical approach sure (that's the main point in fact). The main difference with Java is that Ember all happens inside the browser, and you write it in JavaScript. I have no idea how much experience you have with those things, so have no idea how much you'd learn if you picked it up.

In no way did I imply that you were stuck in Java rut. I said that if you were, you might learn something; if not, you might not. The things you'd learn about (unless you already know a lot about them already of course) involve things that you'd learn doing any front end development.

In no way should you feel bad for wanting to make a lot of money.

The answer to you is maybe, but it's not necessary yet.

In 3-4 years, 80% of greenfield web apps will be using a single page framework. Perhaps it won't be Ember, but something from the next generation. However, the results are better for the user, and as more developers learn it, the more it will be expected as common knowledge.

Increasingly, your contracts will end up being on the back end, and your full stack opportunities will dwindle. Look at the jobs today that say jQuery or javascript. Most of those will be out of your range.

That might be fine for you -- if you stick to back ends or maintenance programming, your jobs won't dwindle. Greenfield apps will slowly dwindle, or you get in with a client who expects you to learn it, or you decide to use it on a project because you see the direction the winds are going.

Me? I have an angular.js and knockout.js proof of concept on my resume now.

Good answer.

The problem I see is that the frontend models are not designed for internal apps in mind. Yet. They're not designed for a mediocre developer. I think we could do a lot better for that use case. Right Now, it's faster to do a server-generated app with no ajax. I don't think that has to be the case.

I've created my share of Java-based server-side generated web applications, and when it comes to writing applications that run well on the web, JavaScript MVC frameworks are the way to go.

I can't comment on how it might affect your career on either the short of long term, though. That said, I expect that the demand for these types of rich webapps will become larger as we move forward.

I'm turned 22 ten years ago myself, but I think making that statement you made is unfair.

How does Ember.js in the clients browser scale when you have a a lot of data that needs marshaling / unmarshaling or generally processing and moving around? Surely it's more performant to do this on the JVM on the server rather than relying on the clients computing power (or lack of). Ideally you wouldn't do a lot of data processing in the MVC part of an app anyway but it seems like you're telling me the whole web app needs to be client side?

You can definately go too far and implement too much on the client side, and this is generally a bad approach.

It's like with anything else. You need to figure out the balance between what you process on the server and what you process on the client.

There's plenty of reasons you might want to avoid this in some cases. For example, you might want your forms to be validated without waiting for the user to push submit. You might have rich content in some markup language (like markdown) and you want the user to have a live preview on the same page as they are editing. Or you might have an app with real time data that changes frequently and you don't want the user to sit there pushing refresh constantly.

You don't need to pull a whole page down to get new data and you can do the form validation on the client side although you need to redo the validation on the server side anyway to make sure the client JS hasn't been tampered with.

It's true that it doesn't give you any magical power that you didn't have before and you can do everything it can do with vanilla javascript or any of the other frameworks. However that's a bit like saying you don't see the point of rails because you can just use vanilla PHP for everything.

The simplest way to use AJAX with a server-side MVC is by fetching blocks of pre-rendered HTML. This is commonly known as AHAH. It's dead-simple to do, powerful and trivial to use via progressive enhancement. That is what you should treat as the server-side alternative to client-side MVC.

Instead of writing your own code to handle AJAX on top of jQuery, you write code that handles the real logic and let the framework handle the DOM manipulation. In that way, it's easier to test, easier to debug, easier to provide superior experiences.

Right now, writing AJAX in the browser is equivalent of the JSPs of yesteryear. Remember all that horrific logic that used to creep into your JSPs? That's what jQuery looks like, and this new crop of frameworks is getting us to JSTL or facelets at the minimum.

Which is non-semantic, so it cannot be progressively enhanced, does not benefit from browser updates and is pretty much not crawlable by anyone except Google.

Ember.js is a tool like many others. So it's sort of like asking "Will I be richer if I learn Django or if I learn Rails?". Nobody on HN can really give you a definitive answer.

It is a framework for building rich javascript client web apps and helps you keep your code structured in a certain way and takes care of a great deal of boilerplate heavy lifting for you, if you take the time to learn it's idioms.

So the question, "Is there a way in which I can leveridge the fact that such a framework exists in order to make more money as a consultant?" is one that only you yourself can answer.

Browsers have come a long way. It's now possible to develop web applications that offer comparable user experience to say iOS/Android/Windows etc. As with those other platforms, to get the full user experience, the developer usually has to learn and use their native libraries and languages (Object-C for iOS, Java for Android, etc). For the web, the language is JavaScript and the library is HTML5 (the DOM manipulation that is).

Unlike those other platforms, plain JavaScript + DOM manipulation can get out of hand pretty quickly. It works when to create 'web application' means adding a few jQuery DOM manipulations here and there, backed by your favourite server framework. But when the amount of JavaScript you have to write grows, you need a way to structure it (design patterns, modules, etc). GWT, if I remember correctly, tried to address the issue of unmanageable JavaScript by allowing you to use Java on the server side and then it will compile and serve JavaScript to the client. This seemed like a good idea but the problem still remained: You're essential writing software in one platform to run in another. There will always be a penalty somewhere (do you remember how long it took to get the first JavaServer Faces framework with HTML5 render?).

The basic driving force of MV* JavaScript framework is to address the issue of writing clean, manageable and performing JavaScript code targeting the browser itself and not some intermediate platform. With the end goal being to provide a better user experience.

Is this worth learning? Well, do you think applications built using client-side JavaScript provide better user experience? Think Twitter, Gmail and the likes. Do you think your clients will appreciate such kind of applications?

The op should have just started an insurance industry disrupting medical insurance startup rather than get paid to work at an already established insurance company where he's somewhat guaranteed(by law) to get paid......

I used to work at a telecommunications company. Maybe I should have created my own telco company so consumers could get cheaper mobile phones instead!?!?!?

You sound like a kid.

Bitcoin is not ready for prime time yet. I can't wait for some malware to empty everyone's wallets...

I'm guessing most USA based commenters here know nothing about Spain.

In that view, keeping most of your money in a non-seizable currency (Bitcoin or not) and just some "hand money" in the bank makes perfect sense. As a Portuguese, I'm considering it myself.

Well, it's not exactly a conspiracy theory, it's all over the news about Cyprus that the Parliament voted (and rejected) that measure[1], which was proposed by the Eurogroup (and others, IIRC).

why wouldn't they try and take some sort of legislative control over BTC? Why wouldn't they make it illegal or do some other thing with the law to make it harder to use without running the risk of a knock on the door? No country is just going to stand by and let a new currency disrupt them.

My argument wasn't just about Bitcoin, but in any case, I certainly wasn't suggesting a situation where half the population or so would suddenly turn to BTC.

That said, while they could illegalize Bitcoins, preventing people from actually using them would be much harder than just telling a few banks what to do. To buy Bitcoins you just need to make an online payment to some exchange (e.g. Mtgox) - you don't even need to run the Bitcoin client.

So to enforce that illegalization, it would take up much more time and effort to implement the technical and legal counter-measures, and it would either be largely ineffective (see "fight against file sharing") or politically hard to implement (e.g. very large number of arrests).

Finally, this is all mostly irrelevant, because the real reason this measure was proposed wasn't because the money from Cypriots, but because there's a lot of money from wealthy Russian business men which would get seized as well, and which definitively won't be using Bitcoins.

[1]: http://www.washingtonpost.com/business/plan-to-seize-deposit...

That said, you are probably right that the technical education and trust needed to embrace bitcoins is much less common in Spain. I first heard of bitcoins in, of all places, an episode of "The Good Wife" couple years ago, and have only found a handful of people who know about them. I imagine this will be changing rapidly in the following months, just like it's doing everywhere else.

What do you mean with 'A lot of places didn't even take credit card'? Are you sure you've been in Spain?.

I guess YOU know nothing about Spain.

http://en.wikipedia.org/wiki/List_of_countries_by_GDP_(nomin...

The GDP of the country has little to do with credit card use. I was surprised when I went to Australia and discovered that Debit cards are a new thing that required marketing to spread. Credit cards were in wide use but paying for things directly out of your bank account with a card is still relatively new.

Are you one of the many Americans that don't even have a passport never mind exploring anywhere that doesn't take your cheap money?

http://www.theexpeditioner.com/2010/02/17/how-many-americans...

Oh, and that was certainly true of Lloret de Mar as well, just a few years ago. Supermarkets and such all accept cards, but the bazaars (run mostly by easterners, from what I could tell) mostly didn't.