Seldaek

The only ties to Symfony are the 3 small Symfony components we used to build Composer, instead of reinventing the wheel. We're trying to build a package manager that promotes code reuse and to keep everyone happy we'd be supposed to write everything from scratch? With mentalities like that, we don't even need a packaging system in PHP, everyone just writes their own everything and that's that.

Just give it a shot, forget how it's built, use it and please give us feedback/report issues. We're improving things on a daily basis.

Libraries, frameworks and tooling in PHP have evolved tremendously in the last couple years. If you look at the Symfony framework and its community you'll find a ton of brand new code that is state of the art, mostly inspired and building on top of ideas from other languages, most of the time improving on them too.

Node for example is lots of fun, but most of the libraries come complete with their bugs and lack of maturity. These are exciting things to work with, but not always best bang for the buck if you're aiming at being productive.

As for Ruby itself getting faster, well guess what PHP itself is getting faster all the time too [1]. You left it behind and it's still evolving without you. Shocker.

[1] http://www.php.net/archive/2012.php#id2012-03-01-1

I'll only speak for Composer which is a new-ish PHP dependency manager, because I'm the co-lead on the project.

System-wide packages are a massive pain, especially on shared hosts. That's why we took the approach of installing everything local, much like virtualenv or npm do. You get your dependencies for the project, in the project. Upload, done. It comes with an autoloader to load classes and it all works with relative paths, so moving it all around is no problem.

Obviously this only handles php libraries, not apt-get packages or whatever, there are tons of great tools for managing system configuration, and we did not set out to reinvent those. But php libraries can just be downloaded, a few of them might depend on specific extensions but mostly if you have a recent-ish PHP version stuff works on most shared hosts worth their name.

As for your point on adoption, I beg to differ. Symfony which is one of the largest frameworks will use it in it's upcoming 2.1 release, I know of a few other frameworks that are looking into it, many libraries are already made available. Even major apps like Drupal have been looking into using it, not for their plugins at first, only for their own dependencies, but once they also discussed the adoption of it for plugins, and I know a few other CMSs have looked at it for just that, because it's easy to wrap into a web frontend to manage installation of dependencies from anywhere. I'd even argue you could convert an entire ecosystem if you have it all in one controlled database already, generating package metadata on the fly and installing from existing sources, then giving the option to plugin authors to start requiring other plugins and plain libraries instead of bundling everything in their code.

Composer is quite new and it's definitely not widely adopted yet, but things are looking way brighter than you picture them. Given the ease of use of publishing packages (basically you have to write one package definition like in npm, and then for a new release you just have to git tag and push to github), resistance from people should be pretty low. Please see docs on http://getcomposer.org/ if you are curious.

1) It does support PEAR, it's listed on http://packagist.org/about-composer

2) PHP5.3, well, so be it. The people stuck in the past are usually not the ones willing to take the plunge into such solution anyway. They can join us when they are ready.

3) Not yet, but we do have some plans for that.

4) You shouldn't commit your vendor dir, you should commit the composer.lock file, which allows anyone to re-install exactly the same version of the dependencies anywhere. And yes this is similar to Bundler as far as I understand it.

5) We also have plans for that, see https://github.com/composer/composer/issues/57 - but this depends on other features that we need to finish first.

PHP config files are much like PHP templates. It sounds handy to be able to do the odd quick hack in there, but on large scale project it always ends up as a gigantic mess in my experience. Quick hack over quick hack, it slowly turns into an unreadable maze of possibilities.

That being said, for packages I really don't think this applies, because it's static declarative information, I can't imagine why you would need "quick hacks" adding logic to that.

- Java-style. You don't like it, I'd argue it's not Java-style, but I know what you mean. I don't think this is worth debating much, it's just opinions :)

- PHP 5.3. Yes. 5.2 has been EOL for almost 1 year now (http://www.php.net/archive/2010.php#id2010-12-16-1), 5.4 is coming fast. I don't mean to be harsh but you will have to get over this one. ZF2, Symfony2, Flow3 are built on 5.3. Drupal8 will be too. Typo3 v5 will be.

- Dependencies on Symfony Components. We are trying to build a package manager here. Something that shold help and promote code re-use, and you would like us to avoid re-using code in the process? I think this is missing the point. Also, you have to realize that most end users will never have to see that, since they will only interact with the "binary" composer.phar file.

I sincerely hope you join the effort.

I really don't think you'd need comments in the package file, but that's not why we picked JSON.

JSON was nice and easy because it's provided natively by PHP, unlike Yaml. Also we were inspired quite a bit by NPM, and I guess that played a role, implicitly.

Also, it is a fact that every format has haters, and we couldn't have picked something that makes everyone happy. So we picked one, and I'm sure people will be able to live with it.

Now I do recognize the fact that some people may not be used to JSON (though I find it quite awkward - even narrow-minded - for web devs), and for that reason I added some syntax checks to warn users of common mistakes in their JSON file, because while PHP has native support, all the info you get from it for malformed JSON is a null return value and "Syntax error" in json_last_error(). We also plan to have an init command that will allow you to build a package file interactively.

It is in the process of being integrated in the Symfony2 framework, which is one of the largest PHP communities. That should dramatically help adoption.

We have some other plans that will help, but nothing sure. Just talking to various people.

Ultimately though, package management is solving a big pain point. If the user experience is good, and it is easy enough for everyone to use, I would dare say that it can not fail. And don't get me wrong, things are not perfect yet on that front, but we are trying hard, and we welcome any feedback we can get.

Fair enough, and interesting facts, but I think what he meant is more that they do not have a meaning to most people. It's not like concatenating real words, it's just finding a name that has meaning to you, but still sounds unique to the world at large.

This is the piss poor attitude that makes HN a better place. Not that the other comment was the most clever thing I ever read, but please.

That's a first world problem of ruby devs I think. When you're used to it, you never forget to write return statements.

All I'm thinking is that people should start using JSLint instead of making up languages on top of JS. That will catch most of the bugs due to common misunderstandings of the language.

I don't quite agree with the conclusion of the article ("you’ll come away with a better understanding of JavaScript"). The fact that CoffeeScript hides scoping and other stuff from you means you will never have to learn how JavaScript really works.

You can argue whether this is good or bad, but it's not giving people a better understanding of anything, it's just making them follow best practices unknowingly.

It is sad to see that our dear political elites still don't "get" the web.

I doubt this will pass, because I'm optimistic at times, and we still have a relatively decent level of democracy around here, but the fact it's been proposed is still alarming.

Unfortunately won't be able to make it, I'm at JSDay in Italy at that time. I hope there will be another chance.

I deleted it :)

If you use keyCode instead of charCode I think you'll get the same result on every keyboard layout, but of course if you tell people to use C, it means the key where C is on a US keyboard, not really the key where a C is printed. I believe Dvorak users are conscious enough to understand that though.

Site got moved to EC2 http://twitter.com/#!/chregu/status/40712581702225920 - agreed though, leaking errors is unacceptable.

Feel free to check Symfony2 at http://docs.symfony-reloaded.org/master/ - it does not have much to do with symfony1 by the way, in case you'd decide to dismiss it due to past experience.

I can now confirm that it renders perfectly in IE9 RC1, it looks exactly like in Opera 11 & Firefox 3.6. Chrome 9 is the only one rendering them a bit awkward (tiny details, but still).

It works in latest versions of all browsers, including IE9 Beta where it's almost perfect - don't have the RC at hand to try, but hopefully it improves the few glitches I'm seeing.

The good thing is that in IE<9, it just shows a white box. But it's still perfectly readable and usable, it just looks less fancy, which is an acceptable loss in some cases.

We did have people in the workshop that were quite knowledgeable in those areas, but we had to keep the text short to avoid most people just skipping over everything. This is bound to create inaccuracies. As for this point in particular, of course it is unreasonable as it is, legal issues would prevent most of this, but the point is to start a discussion. We also had folks from the European Union there that were really enthusiastic about hopefully getting a case to present to (or rather against) detractors.

The filter thing was because yes, some services do not presently allow you to search for all movies that are dubbed in language X. If you are trying to watch something with your kids, it is pretty annoying to have to look for a movie, then go in the language selection, then choose the language of your liking, and then at the end be told it's not available. It's basic UX imo, but if people don't do it right now, it's worth static.

Because importance is subjective :)

Another factor was the really short time we had for development, so implementing those two allow us to cover the largest part of our target audience with a simple UI.

Well I work on a 14" dell machine that is light enough (~2kg) to carry around. With SSD and 4GB RAM it is also sufficiently fast.

As for unplugging stuff, there is USB, Audio, Network, DisplayPort, Power.. 5 cables to pull out, it's really a matter of seconds, but if you care about that you can get a dock and then you just have to grab the laptop and go. Rearranging windows isn't an issue if you run most things fullscreen.

I can't really say what will work for you, but here's how I do it: our company only has laptops, so my work (web dev) machine is a laptop. In the office though I've a 24" monitor, along with external keyboard and mouse. Essentially the laptop is just a portable cpu when I'm sitting in the office. The nice thing is that I can take it with me in meeting rooms, go code on a sofa for a while, work in the train or wherever I feel like. It just takes 10seconds to unplug stuff and I'm good to go.

At home I have the same keyboard/mouse/monitor, backed by a aging desktop machine, but I can still plug the laptop in the whole system fairly easily. The monitor has two inputs so there is a spare cable for the laptop, and all the external stuff is plugged into the monitor which has one unique usb cable that I can plug either in the desktop (using an extender sitting on the desk) or in the laptop.

For data syncing, well the code sits in git repositories on machines that are accessible at any time. The rest is mostly provided by google apps or Dropbox-synced for the rare things that can't be cloud apps. I even have applications sitting with all their data in dropbox, so that I don't have to replicate settings changes between machines, and also for backup purposes.

This is probably one of the best use cases for open source. You can try to change the world, and if you can convince other people that you're going in the right direction you may just get tons of invaluable help.

I think you should follow on it, or if you don't have the time to do that without a decent monetary outcome, at the very least open up the idea, in this thread or another. See if it resonates with people. If so then let's get started, and then see what comes out of it.

This has been demo'd a long time ago already [1], and it seems they haven't done anything yet ? Wtf.

[1] http://www.davidnaylor.co.uk/massive-twitter-cross-site-scri...

Double tap is now going forward (just like the double click on a computer), and swipes should be supported but aren't entirely yet. The zoom isn't possible but it scales automatically to the device size now, so it's alright I think

I can't manage to fix this completely, it only happens in FF somehow it's not honoring the overflow: hidden too well.. However I reset the scroll now so it's a bit less visible.