Thats the reason why its more important to learn the fundamental ideas behind the frameworks and not just the syntactic sugar . A deep understanding of any one will help in easily picking up any of the newer ones.
I was just about to post "Cambrian explosion" as an metaphor for the state of javascript libraries.
There are good reasons to get the HTML formatting off the server and into the client, so the new style JS is all going in the right direction. So another metaphor:
All these frameworks are trying to solve the right problem in the right direction - which one will win out eventually - who knows, but even if you hitch a ride on one that stops half way, you are half way closer to the right destination than if you wait.
I agree. Separation of concerns is a very good design pattern. MVC server frameworks (like Rails and Django) have already separated out the concern of displaying data to the user with their template systems. its a very reasonable next step to just migrate the entire template system off the server and let the client do it.
This has gigantic performance increases for servers under heavy load, and it puts the display logic in a domain that is more naturally suited to dealing with it (JavaScript and the DOM instead of treating HTML as just a string).
The pattern also promotes the use of RESTful APIs for data access from the server, which has the wonderful bonus of allowing you to make your data publicly accessible for free if you want to.
Templates... ok - that's fairly convincing. I'm less convinced about keeping the model and controller client side, because they end up replicating stuff that still has to live on the server anyway, to some degree. That just seems to make things harrier than they were to begin with.
I think if you are trying to replicate the same functions you are right. But if I have, say, a User model then it is merely a conveniently name for two groupings of functions.
My client side user should know nothing about Dbase lookups or persona verification - just as server model should not care about displaying addresses. Overall I think getting the crap out of the server makes it much much easier to reason and architect
Given the constant flood of Ruby and Rails security problems of late, it would seem better to start new projects with something a bit better engineered.
I understand where you're coming from. But don't you feel that the security fixes are coming out in a timely fashion and once they're shut, they're gone for good? (At least that particular exploit)
Slowly but surely Rails will become robust because of this.
1) scattering of effort (each framework gets less total attention by fewer people),
2) duplication of effort (besides what is unique in each, tons of effort is spend in implementing mostly the same things),
3) Many half-finished frameworks
4) Worse documentation and less books/manuals/video tutorials (see 1, 2)
5) Less chances of getting an answer to a framework problem in forums/irc/SO (again: scattering of resources).
6) Less vibrant ecosystems around the framework (if each of 10 frameworks has 10% of the market, it's not as good a business to invest in making plugins as something that has 30-40%). Same for hosting offerings, support, etc.
So you want variety but not too much. 2-3 big players would be mighty fine. 10 players of equal size, not so much.
Agree. The current war of numerous Javascript MVC frameworks reminds me of the situation of Python Web Framework a few years ago, the community was confused by so many choices to select from. In the end, nobody wins, even the ultimate winner Django lost the opportunity to become mainstream. In that sense, the merging of Rails and Merb seemed to be a wise and successful strategic move in hindsight.
Django is pretty mainstream. Its not as popular as Rails but its hardly a maverick.
I think the reason why Python never went all in on a single web framework is just because the Python community itself is much larger and more diverse than the Ruby community. Consequently there were alot more opinions and alot more people willing to develop those opinions into separate projects.
Maybe you're right that there are advantages to converging on a single framework, but I'm not so sure. Rails is omakase, so if there's some part of it you don't like its not really easy or a good idea to change it, and you don't have any other options in Ruby. Django is also omakase but if there's some part of Django that you really disagree with you can just move to web.py or flask or pyramid. these are all built on the common core of Python's wsgi module so these are just different opinions on how to accomplish the same task.
With Django in specific you can swap out a component. For example, if (like many people) you don't like the HTML template syntax, just swap it out for Jinja2 or Mako. In Django it is also usually easy to customize something minor by use of overrides (OOP).
this is very true for some of django's components. the template engine is probably the most opinionated part of django and is also one of the easiest parts to swap out. other parts of django are not so easily disposed of. for example, the ORM is very tightly integrated. its possible to swap it out for SQLAlchemy or something but this is really a huge headache and not worth doing.
This is also true of Rails. That's what the Gemfile is--a list of optional packages that you can swap out. (Almost) all of your configuration happens in that one file where you tell Rails what packages (gems) you want to use with your application.
I think part of the problem is that there is no clear "right tool for the job" for many jobs. There are many that will work just fine. Every author and podcaster who wants to project a veneer of pragmatism will sprinkle "the right tool for the job" truisms and call it good, but IMO that's just a hand-wavy placeholder for whatever they happen to be into at the moment. Which is fine, but to me it somewhat disingenuously dismisses the fact that it's still largely a subjective choice in many situations.
Pick technologies which are most suitable for the job, not the most "hyped" ones. Also don't forget that sometimes the latest technologies comes with innovation tax, you may be the first to solve some issues, because of the small ecosystem.
I agree and can see where OP is coming from. As a Chinese, I notice the difference in how we approach problems. Let me make an analogy:
Chinese and western dude learns guitar. The Chinese player will worry about the scales, the hammer on/off drills, chord drills, picking drills, and maybe practice a song and focus on technicalities; western dude would pick a guitar, learn a few chords to play a song, realise that to play more songs he/she must practice hammer ons, etc, but everything is so that he can play more songs. They have never had to worry about drills. It's a means to an end.
Web frameworks are just drills to choose from. Pick the one you need and move on. With experience, you'll be able to tell what is good and what is not.
Why worry about which framework is "best"? It doesn't matter. If WP template and jquery solves the problem then why is he even talking about Haskell?
You're right but I think this is a bit strong and perhaps a little generalist.
Anyway, IMHO it DOES matter which is best for you because if you choose the wrong one, and you're project is big and complicated enough, you'll spend a long time dicking about trying to fix the 'deficiencies' of your poor technology choice later. So in some sense the OP is right too.
IMHO, as with many things, a little moderation in both is the key. Do just enough analysis to meet your requirements, and future proof your choices, and then leave the crazy web world where you found it.
I has nothing to do with being Chinese or not. I'm a "western dude" and I feel like it's my job to evaluate all of those things because picking the right tool IS my job. If I don't then I am doing a disservice to myself and clients.
I wouldn't want to get surgery by a doctor who said "well, I can do the operation in 5 minutes instead of 5 hours if I knew how to use Hyper Awesome Super Laser but sorry, I don't know how to use that technology".
I think you are generalizing the issue too much. also take a look at the comment of the original author of the post. he is not Chinese: http://news.ycombinator.com/item?id=5206578
any human (or even nature) domain knowledge is enormously detailed rich, with countless sub-domains, methodologies and references beyond the scope of a single person. And thanks god for that.
While some might complain or worry, this is what makes this field so fascinating. A myriad of options, toolsets and methodologies means that it is alive, open and thriving.
Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX battles, where would we have been today?
As much as I use Chrome (and love it), I can't help but admire the work done by Mozilla to rescue the Netscape codebase and mould it into Firefox. I think they deserve a lot of the accolades that enables this zany ecosystem to thrive.
> Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX battles, where would we have been today?
I don't know what 'would have been', but I know that we would not be where we are today (in a positive sense) without those companies and the many many technologies and products they have provided us with (even though some of them can only serve as bad examples).
I'm not bashing them as a whole, just some of their technology decisions. To be honest, I've always felt that MS gets a bad rap. As much as it was anti-competitive, bundling IE in Windows enabled users to download alternative browsers. Obviously, there are other ways to do it but I doubt many users would have gone down that road with higher technical obstacles.
As for Oracle, not much can redeem them. Flash had it's day, but I wish Adobe would let it die already.
I know many here can't accept the truth that Flash had, has and will have its place on the Internet. There was a need for such a technology and there still is. I will be here for another 5-15 years or so, so we should make the best out of it instead of screaming 'DIE ALREADY'. But as always, there is plenty of room for improvements. :)
FYI: Adobe donated Flex to the ASF a while ago and the mailing list is already the most active on ASF. It is actively developed and people are quite motivated.
If it wasn't the security issue laden monstrosity that it is, I could see it living on.
But the facts are that the only real "secure" version is the PPAPI implementation in Chrome (which has it's own limitations), Adobe has dropped future development for embedded systems and that it is almost non-existent on mobile does not speak to the longevity that you predict.
Flex is cool, but it's dependency on Flash will be it's noose.
With Django 1.5 (final just about to be released, hopefully within a week) supporting Python 3, you're not tied to Python 2.
There are other good options, too. Here's one, also conveniently Python 3 compatible:
(3) Pyramid with (a) SQLAlchemy; (b) ZODB; (c) something else—whatever you want!
I'm actually working on a Pyramid + traversal + ZODB project just at present. It's very instructive when once you have become used to URL routing and pattern matching (I've worked with Django hitherto).
As with all technology choices, you've got to draw the line somewhere - new and risky, or old and proven, or somewhere in between.
What matters these days is probably how well you and your team already know the technology, how good the documentation is, community size/takeup, how quick the devs are to respond to issues, and how mature and stable the API is from release to release. How popular/old the technology is also counts for more if you're looking to hire people with experience in it.
MVC on the client is becoming more and more important, once you start slapping a lot of js on a page it can quickly become un-maintainable. We went with Backbone as Ember was changing too quickly in backwards-incompatible ways.
MVC on the server (Django/Rails/Express/whatever) still has a place - you want something serving restful data / html skeletons and mapping urls to responses. In my day job that's Spring MVC because that's what people here know and it ain't broke.
Frontend language choice: Learning JS seems to be the natural choice here. Things that compile to JS e.g. CoffeeScript or DART might also work for you; I don't have experience with them but I'd imagine debugging problems in the resulting js would be a pain until browsers support them natively.
I used to develop with JavaScript, and JavaScript with Backbone before we switched to ClojureScript.
Backbone helped me to better structured my code but I found it also brings its own problems. There is a quite a lot of boilerplate code and views composed of other views were for me hard to manage.
I also wrote some macros to use Backbone from Clojure but the mismatch between object/mutable and functional/immutable is too high.
Finally the approach from http://clojurescriptone.com/ seems promising. It uses a simple yet flexible event dispatcher. Add that a templating engine and you are done.
Debugging ClojureScript within the browser is harder than normal JavaScript but it's easy nonetheless to find what generated JS functions corresponds to your ClojureScript code. If you compile in debug mode you can set a breakpoint as usual. Compiling ClojureScript adds a bit of overhead to the workflow but I compiled it continuously in the background via Emacs and forget about it, it just popups when an error occurs.
In general I found ClojureScript much cleaner than JavaScript and it's easier for me to write cleaner code with it when the data manipulation or the logic is not trivial.
Maybe this is a side effect of this current day and age being a specialist society? Everyone needs something to differentiate themselves from the crowd, and Javascript being such a recent growth in setting a "standard" with regards to frameworks and tools makes for a good incubator for specialists.
while the author claimed to have it translated from Chinese back to English, surprisingly almost exactly the same as the original English version. I guess English-Chinese-English translation has reached an amazing stage!
OP here. I've updated my blog to credit eranation (author of the original English post) and relevant links. I was not aware of the existence of the original English post and thought that I should share it as lots of us suffers the same frustration.
I guess English-Chinese-English translation has reached an amazing stage!
I would take it as a compliment as my 'unofficial English version' isn't too far off.
> I guess English-Chinese-English translation has reached an amazing stage!
It's a misunderstanding and/or an illusion.
Most of the technological terms, e.g. jquery, node, ember.js etc, were merely copied from English to Chinese without translation. And BTW the retro-translation reads as if it was translated with Google translate service, which explains the low quality of translation.
Because of course everybody has to have "MVC responsive html5 cascading containers with chocolate covering"
Not to mention most of these are underdocumented, bug-ridden, too specific, etc
Need a js library? JQuery. period (and don't get me started with mootools, I need to ship, not swim around their docs figuring out how to do what in jquery is easy )
And focus on the backend, a competent backend development will eat your whatever.js "specialist" except for the most specific cases
Still, the back end sees complexity the front-end doesn't. (it is mostly irrelevant for the Facebook frontend if they have hundreds or millions of servers - it certainly has an effect though)
Sure, if you love writing the same boiler plate code over and over again to make sure your dom is updated and your data is synced. JS frameworks are solving a problem, whether or not people like that there are so many out there. We are in the early days, and of course there's going to be a lot of competition. A few will rise to the top and become standards. You know, there were quite a few competing JS libraries before JQuery became so popular..
What I mean is "don't use a jQuery competitor (or jQuery 'sized' tool) in place of jQuery"
Sure, if you need something else/more use it, still I've been burned by those "wonderful js frameworks" and I'll make sure to not use them unless needed and thoroughly evaluated.
mootools documentation is fine. It's just different and therefore "harder". Has nothing to do with your ability to "ship" it's you're lack of knowledge of the library that's the problem. Not the library.
If you can't work a saw it doesn't mean the saw sucks and scissors work better. It means you can't work a saw.
that was probably a bad analogy but I can't think of any better one atm.
'mootools documentation is fine. It's just different and therefore "harder"'
I think I know what you mean, the docs are mostly a reference documentation from what it seems.
But the learning curve is steeper, especially with lack of documentation focused on the beginner.
I know, Django docs are similar (but less worse in this aspect). Still, when you finish the tutorial you don't know where to head.
That's where jQuery shines, it takes you through every step, not to mention it's easier to understand. Hence, more plugins and more users.
"It means you can't work a saw". At this day and age, "saw manufacturers" have to be concerned about the easy of use of the saw.
Of course this is an analogy, because js tools are "free", but it's still a nice idea to go for the better cost x benefit in terms of capabilities/community/libraries etc.
I've found that a large subset of programmers share the same trait as a large subset of photographers: they become so obsessed with tools that they lose sight of the fact that the end product is what matters at the end of the day.
For example: there are many people who spend thousands on cameras and gear, and still take terrible photos. There are many developers who spend a lot of time keeping up with what they think is the latest trend, and yet they never finish any projects that get used.
Then you have the photographers who take great shots no matter what gear they use, and developers who write and ship great code and products using Java and other unsexy languages.
Can better tools help you be more productive? Absolutely. But if you spend all of your time worrying that you're not using the latest and great tools, you won't get much done, and you won't be satisfied with what you do get done. I have 15 cameras and unfinished projects in 10 languages that demonstrate that.
My advice? Sit back, pick technology a couple of steps behind the bleeding edge, and focus on results. Choosing Ember over Backbone isn't going to cause your project to fail; building the wrong thing or failing to finish, however, will.
Absolutely. In this case, though, bad tools aren't the problem. The problem is that there are too many roughly equivalent tools, and many of them are very good, but there is a lot of arguing and navel gazing about which new one is the best to use.
Bad tools also completely confound beginners and can make them think they aren't suited to or do not enjoy an activity that they might otherwise enjoy if they had better tools.
For example, I used to hate cooking, because I hated the prep work, it was very difficult for me. It turned out that my hand-me-down knives were very, very dull, a fact I didn't realize until I decided to invest in a nice set of Henckels. A sharp, quality knife makes the prep work easy and now I enjoy cooking much more than I used to. And now, whenever a friend tells me they want to learn to cook, my first recommendation is to make sure they have a good sharp set of knives, because for me, that made all the difference.
The point of it was actually: it's impossible to always keep up anyway so take something you like or already good at and move with it otherwise you'll never get your project done. It's nice to learn new frameworks, and you should, but it's mandatory that by the time you pick up something there will be something else that is considered better / more popular.
(I'm not saying "use Java Applets / Flash / XML+XSLT" just because "you are already good at it", sometimes you must let go of what you know and adapt to change, just don't over-kill it by learning EVERY new technology as it comes out, taking 1 step back is always a good thing)
I think the spirit of it was a bit lost in translation so here is the original text:
> I agree, I can't keep up, I just finished learning backbone.js and now I've found out on HN that it's old news, and I should use ember.js, cross that, it has opinions, I should use Meteor, no, AngularJS, no, Tower.js (on node.js), and for html templates I need handlebars, no mustache, wait, DoT.js is better, hang on, why do I need an HTML parser inside the browser? isn't that what the browser for? so no HTML templates? ok, DOM snippets, fine, Web Components you say? W3C are in the game too? you mean write REGULAR JavaScript like the Google guys? yuck, oh, I just should write it with CofeeScript and it will look ok, not Coffee? Coco? LiveScript? DART? GWT? ok, let me just go back to Ruby on Rails, oh it doesn't scale? Grails? Groovy? Roo? too "Springy?" ok, what about node.js? doesn't scale either?? but I can write client side, server side and mongodb side code in the same language? (but does it have to be JavaScript?) ok, what about PHP, you say it's not really thread safe? they lie?? ok, let me go back to server coding, it's still Java right? no? Lisp? oh it's called Clojure? well, it has a Bridge / protocol buffers / thrift implementation so we can be language agnostic, so we can support our Haskell developers. Or just go with Scala/Lift/Play it's the BEST framework (Foresquare use it, so it has to be good). of course we won't do SOAP and will use only JSON RESTful services cause it's only for banks and Walmart, and god forbid to use a SQL database it will never scale
I've had it, I'm going to outsource this project... they will probably use a wordpress template and copy paste jQuery to get me the same exact result without the headache and in <del>half</del>quarter the price
p.s. it would have been a longer rant today, I have lot of new things to add to it, sadly things didn't get any better: Now I'm trying to choose between yeoman and brunch, coffeescript vs livescript vs typescript, LESS vs Sass vs Scss vs stylus, Haml vs Jasmine vs that weird language called HTML, testacular vs mocha, fixtures vs mocks, RequireJS vs CommonJS, with almonds or without, I started using underscore then figured out it's already "old school" and I need to actually use lo-dash. So I think I'm going to take your advice ;).
Hi, OP here. Didn't know the existence of your original post, hope that you don't mind my 'unofficial English version', :) I've updated my blog to reference your post and previous discussions. I'm glad that my version isn't too far off.
it would have been a longer rant today, I have lot of new things to add to it, sadly it didn't get any better
Please do. I would look forward to the newer version.
"you'll never get your project done" This, it is about shipping product in the end. You will have a hard time selling an incomplete project. You are solving problems for customers.
Sometimes I love over engineering my projects. It helps me hone my skills and keep updated. But I limit my self to one side. E.g. Back end or front end.
In my case, it's back end. API and stuffs. I'm also trying to limit my self in using different kinds of language. My current Back end stuff today are Grails for web app, Scala for non web, Redis, memcached, MongoDB.
Don't ask me about front end. I'm not updated with it by choice.
I am amazed a rant can go English -> Mandarin -> English via half the world's tech forums, and still be recognised by its original author.
But what really blows my socks off is how a tech forum in Beijing follows rants from Slovenian blog to a Californian forum and back again. And it actually matters to the Chinese because they liked it as much as we did.
Welcome to the new global culture, sharing the same memepool.
Of all the conclusions to be drawn from this observation, I believe yours is the most pessimistic.
I'm much more excited by the fact that information was able to quickly traverse national and language barriers, making it's way all around the globe to catch up with where it began in such a short time. That's pretty amazing if you ask me!
Some forms of diversity we want to lose - the current Syrian culture stands as a good example, China's own culture of terrible human rights abuses is another. On a more usual definition of culture diversity of attitude towards race or sexuality covers diverse opinions such as the KKK and that guy who protests at gay funerals.
Not all diversity is positive - and given that the norms on the forums this passed through are themselves widely different is a indication of how culture will disconnect slightly from geography.
A genepool is strong if it has variety and if it can spread the beneficial genes widely. This can be dichotomous, but trust me 4chan proves generating a wide variety of memes quickly is something we can do.
I don't think that's entirely fair - we can safely assume the Chinese tech forum techsmth has a techie culture, because to the relevance of the rant.
That does not mean they do not have heavy influences from their own (and from a quick surf-by Japanese) culture - lots of threads on photos from the 70s and what was it like then.
They will export back. Just because all the money in Hollywood is forcing young pretty WASP vampires at us does not mean its the only way to express oneself
Yeah, it's not just a one way thing. "Western" culture and American in particular is mostly exporting at the moment. I just found it quite funny that a pro diversity comment was downvoted and so disagreed with (well, it was when I posted) here. The startup culture (that HN had a large part in defining) is extremely monolithic and really skewed to exporting ideas right now. Sure, it's happy to import arguments or small ideas from anywhere, but only if they don't disturb the core philosophy.
I feel a powerful need to poke at people, especially smart ones, when they seem to be knee jerk supporting the status quo. Just a good/bad habit of mine.
Ironic since the original comment complaints about too much diversity. Just because a good rant is recognised across cultures does not imply a loss of diversity. Somethings are just common on this planet, like gravity.
I don't think this implies we are losing diversity. Internet makes easy to connect with like minded people and share information. That sounds good.
Like minded people around the globe becomes more alike? Maybe. But just in the field they share. And they started with similar interests anyway.
To those who are confused due to the myriad of OPs here, Swizec is the author of the excellent blog post that is the beginning of this interesting global thread.
The absolute worst is SOA (the "enterprisey" buzzword for lots of small services) architectures in which every service is written in a different language!
"Oh, our payment processor is in Node, but our site's in Ruby. Our file caching layer is in Python with bits of C for high performance and our crypto stuff is in C++ with Boost and libcryptopp but it talks to a Java app that uses Cassandra..."
(Runs outside, sets self on fire, shoots self in head...)
Yes. The more different languages (and frameworks) someone has to know, the harder it is to hire them. If you hire people who only know the language of one small part of your system, they can't help out on other parts during emergencies and there will be difficulties adding new parts (which language do you use, or which existing part do you steal developers from). If you hire people who know one language and train them in the rest, the more languages there are the more that training will cost.
And it's rather a good thing, no? I mean, for me, as a developer who happens to know at least a dozen of languages quite well and has a basic grasp on a dozen more, I like it that way. Namely, I like being a harder to find good with limited supply, this means that I will be paid more.
Otherwise what would be the point of learning all these languages, frameworks, libs and environments? Of course the learning experience can "make you a better developer", but is it supposed to be only that?
(2) Multiplication of surface area for things like security bugs... now you have five different stacks to keep track of security updates for instead of just one.
(3) Multiplication of deployment resources-- now you need multiple VMs, maybe multiple instances with different stacks to run them on, etc.
(4) Developers can't pinch-hit for each other unless they know every damn stack in the world.
(5) If you sell, God help whoever has to support that stuff in your new organization.
(5) If you sell, God help whoever has to support that stuff in your new organization.
It would be interesting to know if an acquisition fell through because due diligence revealed something like this and the purchasing entity didn't want to deal with that mess or it conflicted with their culture.
Absolutely not - no it manager worth their salt will pass up the opportunity to say - well we can do it but we will need more cash - we have to hire a ruby team a node team a ...
In the 1970s, the US DoD had what one could parallel to SOA. They had hundreds of languages; they'd start a new project and with it came a new programming language, stack and toolset. They created the High Order Language Working Group which worked on a document of requirements for one language to rule them all, the Steelman. A competition was had to which 4 colorful languages were entered. The winner, Green, became Ada which coincidentally has just wrapped it it's latest language revision process at ISO. Much of the Steelman focused on maintenance, reliability, readability and other traits that make for good software that will last. It is a good thing take that step back and make sure we are programming up to her level.
I'd take that situation any day over a monolithic monstrosity written in only Java. Small losely coupled services that do one thing is the only way to build a large system if you want to keep your sanity.
My advice to you is to pick the technology that's right for the job. If you don't know it, learn it. Otherwise, don't learn it. For example, if I never make an app in my LIFE that has to do with data processing, why in the world would I want to learn Clojure? What use will it have to me? There are lots of things you can do with any language you described, but I think you'll know a good fit when you see it.
It took me about an hour of writing Ruby for the first time to know that this is the language I would prefer writing all of my web applications (client and server side) in.
The second sentence really tells all. " Just learned Backbone.js and only found out it’s already out of fashion." This is why critical thinking and a sight of the big picture is so important. Who cares if something is fashionable? Does Backbone help you solve your problems? Yes? then use it. No? Don't use it.
This really bears repeating over and over again, and I think it's a corollary of "start by writing the dumbest thing that can possibly work."
If you start with dumb, simple things, the problems become more obvious. Dumb simple things tend to shake out the parts that are tedious to build, or non-conformant, or confusing to read, or hard to maintain. It may be that Backbone (or any of the dozens of other gizmos) alleviate the problems, but you really have to understand the problem first.
I really think a lot of people are seduced by the marketing of various tools and frameworks into thinking they have (or will have) problems that they don't actually have. Then they end up with over-engineered solutions that are all the things they hoped to avoid.
Don't meant to criticize backbone, or any other framework (or language, or platform). A fancy, hip tool can be just thing. The question is: do you know what "the thing" is really for, and does it fit your situation?
I hear what you're saying, and I basically agree. However, I still see some shops building new product with Jakarta Struts, hand coded javascript, and no continuous integration. They spend way too much time doing things that could be automated, which would allow them to spend more time on quality, or more features. (Say, if you want to use a java webstack, have you heard of spring & jquery, and maybe you should try hudson for your builds?) So, its also important to keep abreast of whats happening in the field, so long as you don't fetishize the newest/latest thing.
I agree 1000% - very good point. The best tools (for you) are the ones that solve the problems that bug you the most and feel the most "right". It's a personal thing.
For example: In my case, I used to write a lot of plain HTML. I found it got annoying to type brackets and keep track of all the closing tags. So I tried ZenCoding, and it helped, but only on creation, not on editing. I finally settled on haml, because to me (not everyone), it solves the exact problem that I found troublesome and gave me the results that I like. No closing tags, cleaner markup. Others may disagree, but that doesn't matter - I like it for my purposes, and that's all it takes.
So to your point - learn the underlying tech, find your personal pain points, and use the tools that best solve them for you.
Haml is soo 2012. :) Try Jade (http://jade-lang.com/), it has a much cleaner syntax and integrated markdown support. You can even use it as a preprocessor for other templating languages.
No, this isn't correct. Fashionability has nothing to do with it. PHP is not fashionable - in fact I'd argue that right now it might be the most despised language around - but upstream development isn't slowing down at all but in fact speeding up and it's being improved at a very rapid pace as of late.
I think choosing fashionable tools because you think upstream maintenance will continue into the future is actually misguided. In my experience the old, boring tools are what have staying power. The new fashion comes out, gets lot of attention, then the next big thing steals its thunder and you start seeing your fashionable tool's upstream updates go from a stream to a trickle to droplets here and there and finally you start to wonder if the project is dead.
Maybe you meant something different but just by going off what you said I'd say you're wrong. There's a difference between something popular with staying power and the latest fashion. I think the JavaScript world, node.js in particular, is in a period where for all its new hotness we'll start to see a lot of these popular modules just die. I think node may soon become a good example of why fashionable tools are not to be relied upon. That isn't to say that node itself is going anywhere but rather that its in a transition period from new hotness to something more stable and the NPM packages are what we'll see start dropping like flies before we can be sure what we can count on later.
Right, the difference between "fashionable" and "unfashionable" is just what the cool kids on HN say it is.
To take your example on a stroll, PHP is like regular (non-skinny) blue jeans. Everyone knows them, most people use them, every store carries them, at one point in history they were revolutionary, they're probably never going to go away. But the cool kids say skin-tight crazy-colored jeans are the new hotness...
I think this goes for the latest and most hyped where the communities could be small. A good middle ground would be well-established projects with a relatively big community and preferably strong industry ties. Usually projects over a certain size will survive by some faction of the community even if it's losing steam or something dramatic happens sort of like MySQL and MariaDB.
I really dislike the anti-intellectualism in fallacious quips like that. People discussing haskell and clojure are not magically prevented from writing code as a result of their intellectual curiosity and desire to explore better tools and methods. The implication that people who are smart and use quality tools never accomplish anything or do any work is quite insidious, as newcomers start taking pride in ignorance because they are "shipping product" while falsely believing those other people aren't. It becomes used as a way to dismiss opportunities to learn because they've equated learning and being educated with not accomplishing anything.
agreed. Just because someone can use a pocket knife and some twine to lash together a chair in 20 minutes doesn't mean someone is going to buy that chair.
Craftsmen care about their tools, and great craftsmen ship. Shitty ones can ship too, but it won't be good.
Honestly, I wish I could believe that. But I really don't see how I am reading anything into it. The implication that people who talk about programming languages that he doesn't want to learn about are not "shipping product" is quite clear. I don't see any way to interpret that sentiment other than as anti-intellectualism.
I guess strictly speaking it's a false dilemma to say you're either arguing endlessly or shipping, but I don't really think that was the spirit of the quote. Unless there are infinite productive hours in your day you have to choose your stack and go for it, and the less boilerplate you have to do to get your stack running, the more time you'll have for productivity.
It's nuanced. We all of us owe our careers to the people who came before us asking, 'what if we could do it this way?'. But, you have to draw the line between intellectual wanking and thoughtlessness. It's a surprisingly hard line to draw - more for some than for others.
>Unless there are infinite productive hours in your day you have to choose your stack and go for it
But the people advocating haskell and clojure have done that. And they feel that their choice worked out so well that they should be nice enough to tell others how good it is. The people "just shipping with PHP" aren't spending their entire day coding, how is spending a half hour advocating for a programming language any different than spending that half hour watching TV (or as a more apt analogy, spending it arguing that PHP is totally good enough because I am shipping software in it so there's no need to ever try anything else)?
>and the less boilerplate you have to do to get your stack running, the more time you'll have for productivity.
This seems like an implication that using haskell or clojure somehow means having to deal with lots of boilerplate. That is not the case, and it is a rather odd thing to believe. This argument actually works against "just shipping in PHP". The less time you have to spend dealing with bugs that would have been prevented in another language, the more time you'll have for productivity.
>But, you have to draw the line between intellectual wanking and thoughtlessness
I believe the idea that there is anyone engaged in "intellectual wanking" instead of "shipping product" is fallacious. I've advocated haskell here before. Obviously I wasn't writing code while doing so, but would I have been writing code were I not advocating haskell? No, I would have been talking about something else, still not coding. Using downtime to advocate for your preferred language, platform, OS, library, framework, etc is a perfectly reasonable use of time, and if you are willing to read the contrary opinions of others, it can even be educational.
> the idea that there is anyone engaged in "intellectual wanking" instead of "shipping product" is fallacious
The idea that you could know what everyone is not doing at all times is fallacious.
The time I'm talking about (and I thought has been implied in this thread) is the time where you sit in a meeting room/coffee shop/founder's house, during work hours, arguing about why X is a better stack than Y and why project Foo should use it instead of your "default" stack (not necessarily haskell v. php; X vs Y).
And again, I am saying that time is virtually non-existent. It is a red herring, used to try to pretend that "those weird people who actually learn stuff" aren't getting anything done. People are not talking about haskell and clojure instead of working. That is the entire point.
If one bothers to learn about tools and why they are useful, they can think a little bit deeper and understand why some intellectual argument do result in software that ships. We write Scala at my company because we've found that with the right developers who seek to understand type systems and fp we can ship fast as fuck. I'm dozens of times faster working in Scala than I ever would be in php. We want to beat the average, not be the average.
I've programmed large projects in 6 or 7 different languages now and I simply don't believe your statement "I'm dozens of times faster working in Scala than I ever would be in php." That's like saying "I would write that essay dozens of times faster in Spanish than I would in English."
The tough problems that take most of the time are the design and theoretical understanding of the problem. The actual tools used to implement the solution, while not trivial in their differences, are never as important as fully understanding the problem and having a good architectural design.
Or put differently, if you found me the fastest, most knowledgable person in the world with PHP web development, and then found the same guy for Scala, my assumption is they would both build a particular project in the same amount of time, all other things equal. And I could guarantee that one of the two wouldn't be "dozens of times faster" than the other.
Thats true of almost any hobby/endeavor. I know some people who call themselves "guitar players" but all they ever do is go to the guitar shop every weekend to exchange gear. They never actually play their instrument.
Another problem with this is that tech companies (mostly startups) also fall into this trap where they feel like if they're not using the absolute latest and greatest frameworks they cannot be successful. This leads them to only hire developers who are "experts" with these frameworks (which is basically no one since they're so new) and they spend more time figuring out how to adapt this new technology to their business than they do shipping an MVP. It becomes a viscious circle because now the developers who are experts in some older technology feel like they have to spend all their time learning the latest shiny toy so that they can compete for jobs with said startups.
Beautiful. I think it's also important to recognize that all tools have their warts, and to stop trying to pursue The Perfect Language/Framework/Environment™, because aside from marginal slow improvements, many modern tools are not that much better than their peers.
Call me a masochist, but I love the huge amount of selection, I love how passionate people are about their own solutions meaning they rapidly improve, and I love getting my hands dirty with pretty much anything I can get my hands on.
That last sentence conjured an image of a person trying to drag a giant toolbox with him everywhere for some reason :) I do tend to disagree with the sentiment though.
The initial time investment per tool is steep.
Also, the tools' values deteriorate rather rapidly. Languages/Frameworks will become less used over time as something new replaces them (generally), and even your specific skills with a language will get worse over time if you aren't using it.
I've been wanting to use one of the new JavaScript frameworks on a new project, after dabbling with backbone and getting lost very quickly trying to clean up zombie views/events. My latest project is a front end site to a JSON API, so I thought it was the perfect opportunity, but after discussing it with my client we both decided not to.
Because I know what I'm doing best in PHP. So the site is going to do REST queries, but on the backend. We still have the ability to use the API in other clients, and we could in the future use shinyFrameworkOf2013.js, but for now we're building something we know will work.
I like this because it demonstrates the complexity that can possibly be involved with some serious web development projects.
Also, I think it is the skill/ability to make the decision between these tools and platforms and know that you only need some etc - is what separates the good educated developers from the rest.
205 comments
[ 4.8 ms ] story [ 217 ms ] threadI'd just use Rails as a default for most things I do these days, and if it's not a good fit, evaluate other technology.
There are good reasons to get the HTML formatting off the server and into the client, so the new style JS is all going in the right direction. So another metaphor:
All these frameworks are trying to solve the right problem in the right direction - which one will win out eventually - who knows, but even if you hitch a ride on one that stops half way, you are half way closer to the right destination than if you wait.
It alos makes my server software conceptually simpler - which is always nice
This has gigantic performance increases for servers under heavy load, and it puts the display logic in a domain that is more naturally suited to dealing with it (JavaScript and the DOM instead of treating HTML as just a string).
The pattern also promotes the use of RESTful APIs for data access from the server, which has the wonderful bonus of allowing you to make your data publicly accessible for free if you want to.
My client side user should know nothing about Dbase lookups or persona verification - just as server model should not care about displaying addresses. Overall I think getting the crap out of the server makes it much much easier to reason and architect
But ZOMG RAILS IS INSECURE, quick, switch to something else! [/sarcasm]. Evaluating other technology is the opening of the rabbithole.
Slowly but surely Rails will become robust because of this.
1) scattering of effort (each framework gets less total attention by fewer people),
2) duplication of effort (besides what is unique in each, tons of effort is spend in implementing mostly the same things),
3) Many half-finished frameworks
4) Worse documentation and less books/manuals/video tutorials (see 1, 2)
5) Less chances of getting an answer to a framework problem in forums/irc/SO (again: scattering of resources).
6) Less vibrant ecosystems around the framework (if each of 10 frameworks has 10% of the market, it's not as good a business to invest in making plugins as something that has 30-40%). Same for hosting offerings, support, etc.
So you want variety but not too much. 2-3 big players would be mighty fine. 10 players of equal size, not so much.
I think the reason why Python never went all in on a single web framework is just because the Python community itself is much larger and more diverse than the Ruby community. Consequently there were alot more opinions and alot more people willing to develop those opinions into separate projects.
Maybe you're right that there are advantages to converging on a single framework, but I'm not so sure. Rails is omakase, so if there's some part of it you don't like its not really easy or a good idea to change it, and you don't have any other options in Ruby. Django is also omakase but if there's some part of Django that you really disagree with you can just move to web.py or flask or pyramid. these are all built on the common core of Python's wsgi module so these are just different opinions on how to accomplish the same task.
Pick technologies which are most suitable for the job, not the most "hyped" ones. Also don't forget that sometimes the latest technologies comes with innovation tax, you may be the first to solve some issues, because of the small ecosystem.
Chinese and western dude learns guitar. The Chinese player will worry about the scales, the hammer on/off drills, chord drills, picking drills, and maybe practice a song and focus on technicalities; western dude would pick a guitar, learn a few chords to play a song, realise that to play more songs he/she must practice hammer ons, etc, but everything is so that he can play more songs. They have never had to worry about drills. It's a means to an end.
Web frameworks are just drills to choose from. Pick the one you need and move on. With experience, you'll be able to tell what is good and what is not.
Why worry about which framework is "best"? It doesn't matter. If WP template and jquery solves the problem then why is he even talking about Haskell?
Anyway, IMHO it DOES matter which is best for you because if you choose the wrong one, and you're project is big and complicated enough, you'll spend a long time dicking about trying to fix the 'deficiencies' of your poor technology choice later. So in some sense the OP is right too.
IMHO, as with many things, a little moderation in both is the key. Do just enough analysis to meet your requirements, and future proof your choices, and then leave the crazy web world where you found it.
I wouldn't want to get surgery by a doctor who said "well, I can do the operation in 5 minutes instead of 5 hours if I knew how to use Hyper Awesome Super Laser but sorry, I don't know how to use that technology".
Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX battles, where would we have been today?
As much as I use Chrome (and love it), I can't help but admire the work done by Mozilla to rescue the Netscape codebase and mould it into Firefox. I think they deserve a lot of the accolades that enables this zany ecosystem to thrive.
I don't know what 'would have been', but I know that we would not be where we are today (in a positive sense) without those companies and the many many technologies and products they have provided us with (even though some of them can only serve as bad examples).
As for Oracle, not much can redeem them. Flash had it's day, but I wish Adobe would let it die already.
If anything. :)
> I wish Adobe would let it die already.
I know many here can't accept the truth that Flash had, has and will have its place on the Internet. There was a need for such a technology and there still is. I will be here for another 5-15 years or so, so we should make the best out of it instead of screaming 'DIE ALREADY'. But as always, there is plenty of room for improvements. :)
FYI: Adobe donated Flex to the ASF a while ago and the mailing list is already the most active on ASF. It is actively developed and people are quite motivated.
But the facts are that the only real "secure" version is the PPAPI implementation in Chrome (which has it's own limitations), Adobe has dropped future development for embedded systems and that it is almost non-existent on mobile does not speak to the longevity that you predict.
Flex is cool, but it's dependency on Flash will be it's noose.
1) Django 2) Flask + SQLAlchemy
Not that much choice, is there?
There are other good options, too. Here's one, also conveniently Python 3 compatible:
(3) Pyramid with (a) SQLAlchemy; (b) ZODB; (c) something else—whatever you want!
I'm actually working on a Pyramid + traversal + ZODB project just at present. It's very instructive when once you have become used to URL routing and pattern matching (I've worked with Django hitherto).
What matters these days is probably how well you and your team already know the technology, how good the documentation is, community size/takeup, how quick the devs are to respond to issues, and how mature and stable the API is from release to release. How popular/old the technology is also counts for more if you're looking to hire people with experience in it.
MVC on the client is becoming more and more important, once you start slapping a lot of js on a page it can quickly become un-maintainable. We went with Backbone as Ember was changing too quickly in backwards-incompatible ways.
MVC on the server (Django/Rails/Express/whatever) still has a place - you want something serving restful data / html skeletons and mapping urls to responses. In my day job that's Spring MVC because that's what people here know and it ain't broke.
Frontend language choice: Learning JS seems to be the natural choice here. Things that compile to JS e.g. CoffeeScript or DART might also work for you; I don't have experience with them but I'd imagine debugging problems in the resulting js would be a pain until browsers support them natively.
Backbone helped me to better structured my code but I found it also brings its own problems. There is a quite a lot of boilerplate code and views composed of other views were for me hard to manage.
I also wrote some macros to use Backbone from Clojure but the mismatch between object/mutable and functional/immutable is too high.
Finally the approach from http://clojurescriptone.com/ seems promising. It uses a simple yet flexible event dispatcher. Add that a templating engine and you are done.
Debugging ClojureScript within the browser is harder than normal JavaScript but it's easy nonetheless to find what generated JS functions corresponds to your ClojureScript code. If you compile in debug mode you can set a breakpoint as usual. Compiling ClojureScript adds a bit of overhead to the workflow but I compiled it continuously in the background via Emacs and forget about it, it just popups when an error occurs.
In general I found ClojureScript much cleaner than JavaScript and it's easier for me to write cleaner code with it when the data manipulation or the logic is not trivial.
Marionette (https://github.com/marionettejs/backbone.marionette) lets you do all of that stuff out of the box; I've not used it though so can't comment.
This is precisely how I see the ecosystem too. If I've learned anything:
1. Focus on something —Rails, Python, Javascript, WordPress, something 2. Learn to actually program — any language will do
Also reminds me of this tongue in cheek site : http://html9responsiveboilerstrapjs.com/
while the author claimed to have it translated from Chinese back to English, surprisingly almost exactly the same as the original English version. I guess English-Chinese-English translation has reached an amazing stage!
I guess English-Chinese-English translation has reached an amazing stage!
I would take it as a compliment as my 'unofficial English version' isn't too far off.
It's a misunderstanding and/or an illusion.
Most of the technological terms, e.g. jquery, node, ember.js etc, were merely copied from English to Chinese without translation. And BTW the retro-translation reads as if it was translated with Google translate service, which explains the low quality of translation.
The amount of 'meetoo.js' is amazing(ly bad)
Because of course everybody has to have "MVC responsive html5 cascading containers with chocolate covering"
Not to mention most of these are underdocumented, bug-ridden, too specific, etc
Need a js library? JQuery. period (and don't get me started with mootools, I need to ship, not swim around their docs figuring out how to do what in jquery is easy )
And focus on the backend, a competent backend development will eat your whatever.js "specialist" except for the most specific cases
These days backend is pretty straight forward, mature, and usually easy compared to client side.
Still, the back end sees complexity the front-end doesn't. (it is mostly irrelevant for the Facebook frontend if they have hundreds or millions of servers - it certainly has an effect though)
Sure, if you love writing the same boiler plate code over and over again to make sure your dom is updated and your data is synced. JS frameworks are solving a problem, whether or not people like that there are so many out there. We are in the early days, and of course there's going to be a lot of competition. A few will rise to the top and become standards. You know, there were quite a few competing JS libraries before JQuery became so popular..
Sure, if you need something else/more use it, still I've been burned by those "wonderful js frameworks" and I'll make sure to not use them unless needed and thoroughly evaluated.
If you can't work a saw it doesn't mean the saw sucks and scissors work better. It means you can't work a saw.
that was probably a bad analogy but I can't think of any better one atm.
I think I know what you mean, the docs are mostly a reference documentation from what it seems.
But the learning curve is steeper, especially with lack of documentation focused on the beginner.
I know, Django docs are similar (but less worse in this aspect). Still, when you finish the tutorial you don't know where to head.
That's where jQuery shines, it takes you through every step, not to mention it's easier to understand. Hence, more plugins and more users.
"It means you can't work a saw". At this day and age, "saw manufacturers" have to be concerned about the easy of use of the saw.
Of course this is an analogy, because js tools are "free", but it's still a nice idea to go for the better cost x benefit in terms of capabilities/community/libraries etc.
For example: there are many people who spend thousands on cameras and gear, and still take terrible photos. There are many developers who spend a lot of time keeping up with what they think is the latest trend, and yet they never finish any projects that get used.
Then you have the photographers who take great shots no matter what gear they use, and developers who write and ship great code and products using Java and other unsexy languages.
Can better tools help you be more productive? Absolutely. But if you spend all of your time worrying that you're not using the latest and great tools, you won't get much done, and you won't be satisfied with what you do get done. I have 15 cameras and unfinished projects in 10 languages that demonstrate that.
My advice? Sit back, pick technology a couple of steps behind the bleeding edge, and focus on results. Choosing Ember over Backbone isn't going to cause your project to fail; building the wrong thing or failing to finish, however, will.
For example, I used to hate cooking, because I hated the prep work, it was very difficult for me. It turned out that my hand-me-down knives were very, very dull, a fact I didn't realize until I decided to invest in a nice set of Henckels. A sharp, quality knife makes the prep work easy and now I enjoy cooking much more than I used to. And now, whenever a friend tells me they want to learn to cook, my first recommendation is to make sure they have a good sharp set of knives, because for me, that made all the difference.
The rant was made as a comment here: http://www.zemanta.com/blog/i-bet-you-over-engineered-your-s...
Picked up by a Tilo Mitra: http://tilomitra.com/the-crazy-world-of-code/
And as discussed here in HN before: http://news.ycombinator.com/item?id=4226990
The point of it was actually: it's impossible to always keep up anyway so take something you like or already good at and move with it otherwise you'll never get your project done. It's nice to learn new frameworks, and you should, but it's mandatory that by the time you pick up something there will be something else that is considered better / more popular.
(I'm not saying "use Java Applets / Flash / XML+XSLT" just because "you are already good at it", sometimes you must let go of what you know and adapt to change, just don't over-kill it by learning EVERY new technology as it comes out, taking 1 step back is always a good thing)
I think the spirit of it was a bit lost in translation so here is the original text:
> I agree, I can't keep up, I just finished learning backbone.js and now I've found out on HN that it's old news, and I should use ember.js, cross that, it has opinions, I should use Meteor, no, AngularJS, no, Tower.js (on node.js), and for html templates I need handlebars, no mustache, wait, DoT.js is better, hang on, why do I need an HTML parser inside the browser? isn't that what the browser for? so no HTML templates? ok, DOM snippets, fine, Web Components you say? W3C are in the game too? you mean write REGULAR JavaScript like the Google guys? yuck, oh, I just should write it with CofeeScript and it will look ok, not Coffee? Coco? LiveScript? DART? GWT? ok, let me just go back to Ruby on Rails, oh it doesn't scale? Grails? Groovy? Roo? too "Springy?" ok, what about node.js? doesn't scale either?? but I can write client side, server side and mongodb side code in the same language? (but does it have to be JavaScript?) ok, what about PHP, you say it's not really thread safe? they lie?? ok, let me go back to server coding, it's still Java right? no? Lisp? oh it's called Clojure? well, it has a Bridge / protocol buffers / thrift implementation so we can be language agnostic, so we can support our Haskell developers. Or just go with Scala/Lift/Play it's the BEST framework (Foresquare use it, so it has to be good). of course we won't do SOAP and will use only JSON RESTful services cause it's only for banks and Walmart, and god forbid to use a SQL database it will never scale I've had it, I'm going to outsource this project... they will probably use a wordpress template and copy paste jQuery to get me the same exact result without the headache and in <del>half</del>quarter the price
p.s. it would have been a longer rant today, I have lot of new things to add to it, sadly things didn't get any better: Now I'm trying to choose between yeoman and brunch, coffeescript vs livescript vs typescript, LESS vs Sass vs Scss vs stylus, Haml vs Jasmine vs that weird language called HTML, testacular vs mocha, fixtures vs mocks, RequireJS vs CommonJS, with almonds or without, I started using underscore then figured out it's already "old school" and I need to actually use lo-dash. So I think I'm going to take your advice ;).
it would have been a longer rant today, I have lot of new things to add to it, sadly it didn't get any better
Please do. I would look forward to the newer version.
... this is a crazy trip for a comment to make! And I still think most people over-engineer and over-think their startup tech.
Customers don't care what you use, as long as it solves their problem. The rest just helps with recruiting I guess.
In my case, it's back end. API and stuffs. I'm also trying to limit my self in using different kinds of language. My current Back end stuff today are Grails for web app, Scala for non web, Redis, memcached, MongoDB.
Don't ask me about front end. I'm not updated with it by choice.
But what really blows my socks off is how a tech forum in Beijing follows rants from Slovenian blog to a Californian forum and back again. And it actually matters to the Chinese because they liked it as much as we did.
Welcome to the new global culture, sharing the same memepool.
What on earth would make you think that this leap "stands to reason"?
I'm much more excited by the fact that information was able to quickly traverse national and language barriers, making it's way all around the globe to catch up with where it began in such a short time. That's pretty amazing if you ask me!
Not all diversity is positive - and given that the norms on the forums this passed through are themselves widely different is a indication of how culture will disconnect slightly from geography.
A genepool is strong if it has variety and if it can spread the beneficial genes widely. This can be dichotomous, but trust me 4chan proves generating a wide variety of memes quickly is something we can do.
Harder to see the harm in it when it's your culture that's becoming the monoculture. That's the "good one"!
That does not mean they do not have heavy influences from their own (and from a quick surf-by Japanese) culture - lots of threads on photos from the 70s and what was it like then.
They will export back. Just because all the money in Hollywood is forcing young pretty WASP vampires at us does not mean its the only way to express oneself
I feel a powerful need to poke at people, especially smart ones, when they seem to be knee jerk supporting the status quo. Just a good/bad habit of mine.
(I bet you over engineered your startup, posted on July 2012 at http://www.zemanta.com/blog/i-bet-you-over-engineered-your-s...)
If you haven't read it yet, highly recommended, much better than my rant.
"Oh, our payment processor is in Node, but our site's in Ruby. Our file caching layer is in Python with bits of C for high performance and our crypto stuff is in C++ with Boost and libcryptopp but it talks to a Java app that uses Cassandra..."
(Runs outside, sets self on fire, shoots self in head...)
Otherwise what would be the point of learning all these languages, frameworks, libs and environments? Of course the learning experience can "make you a better developer", but is it supposed to be only that?
(1) Code reuse, or lack thereof.
(2) Multiplication of surface area for things like security bugs... now you have five different stacks to keep track of security updates for instead of just one.
(3) Multiplication of deployment resources-- now you need multiple VMs, maybe multiple instances with different stacks to run them on, etc.
(4) Developers can't pinch-hit for each other unless they know every damn stack in the world.
(5) If you sell, God help whoever has to support that stuff in your new organization.
It would be interesting to know if an acquisition fell through because due diligence revealed something like this and the purchasing entity didn't want to deal with that mess or it conflicted with their culture.
:-)
It took me about an hour of writing Ruby for the first time to know that this is the language I would prefer writing all of my web applications (client and server side) in.
This really bears repeating over and over again, and I think it's a corollary of "start by writing the dumbest thing that can possibly work."
If you start with dumb, simple things, the problems become more obvious. Dumb simple things tend to shake out the parts that are tedious to build, or non-conformant, or confusing to read, or hard to maintain. It may be that Backbone (or any of the dozens of other gizmos) alleviate the problems, but you really have to understand the problem first.
I really think a lot of people are seduced by the marketing of various tools and frameworks into thinking they have (or will have) problems that they don't actually have. Then they end up with over-engineered solutions that are all the things they hoped to avoid.
Don't meant to criticize backbone, or any other framework (or language, or platform). A fancy, hip tool can be just thing. The question is: do you know what "the thing" is really for, and does it fit your situation?
I wish all the energy of these polarized discussions would go into learning of the ways to find a good balance.
For example: In my case, I used to write a lot of plain HTML. I found it got annoying to type brackets and keep track of all the closing tags. So I tried ZenCoding, and it helped, but only on creation, not on editing. I finally settled on haml, because to me (not everyone), it solves the exact problem that I found troublesome and gave me the results that I like. No closing tags, cleaner markup. Others may disagree, but that doesn't matter - I like it for my purposes, and that's all it takes.
So to your point - learn the underlying tech, find your personal pain points, and use the tools that best solve them for you.
I think choosing fashionable tools because you think upstream maintenance will continue into the future is actually misguided. In my experience the old, boring tools are what have staying power. The new fashion comes out, gets lot of attention, then the next big thing steals its thunder and you start seeing your fashionable tool's upstream updates go from a stream to a trickle to droplets here and there and finally you start to wonder if the project is dead.
Maybe you meant something different but just by going off what you said I'd say you're wrong. There's a difference between something popular with staying power and the latest fashion. I think the JavaScript world, node.js in particular, is in a period where for all its new hotness we'll start to see a lot of these popular modules just die. I think node may soon become a good example of why fashionable tools are not to be relied upon. That isn't to say that node itself is going anywhere but rather that its in a transition period from new hotness to something more stable and the NPM packages are what we'll see start dropping like flies before we can be sure what we can count on later.
To take your example on a stroll, PHP is like regular (non-skinny) blue jeans. Everyone knows them, most people use them, every store carries them, at one point in history they were revolutionary, they're probably never going to go away. But the cool kids say skin-tight crazy-colored jeans are the new hotness...
@agentdero
https://twitter.com/agentdero/status/174965036928868352
Craftsmen care about their tools, and great craftsmen ship. Shitty ones can ship too, but it won't be good.
It's nuanced. We all of us owe our careers to the people who came before us asking, 'what if we could do it this way?'. But, you have to draw the line between intellectual wanking and thoughtlessness. It's a surprisingly hard line to draw - more for some than for others.
But the people advocating haskell and clojure have done that. And they feel that their choice worked out so well that they should be nice enough to tell others how good it is. The people "just shipping with PHP" aren't spending their entire day coding, how is spending a half hour advocating for a programming language any different than spending that half hour watching TV (or as a more apt analogy, spending it arguing that PHP is totally good enough because I am shipping software in it so there's no need to ever try anything else)?
>and the less boilerplate you have to do to get your stack running, the more time you'll have for productivity.
This seems like an implication that using haskell or clojure somehow means having to deal with lots of boilerplate. That is not the case, and it is a rather odd thing to believe. This argument actually works against "just shipping in PHP". The less time you have to spend dealing with bugs that would have been prevented in another language, the more time you'll have for productivity.
>But, you have to draw the line between intellectual wanking and thoughtlessness
I believe the idea that there is anyone engaged in "intellectual wanking" instead of "shipping product" is fallacious. I've advocated haskell here before. Obviously I wasn't writing code while doing so, but would I have been writing code were I not advocating haskell? No, I would have been talking about something else, still not coding. Using downtime to advocate for your preferred language, platform, OS, library, framework, etc is a perfectly reasonable use of time, and if you are willing to read the contrary opinions of others, it can even be educational.
The idea that you could know what everyone is not doing at all times is fallacious.
The time I'm talking about (and I thought has been implied in this thread) is the time where you sit in a meeting room/coffee shop/founder's house, during work hours, arguing about why X is a better stack than Y and why project Foo should use it instead of your "default" stack (not necessarily haskell v. php; X vs Y).
And again, I am saying that time is virtually non-existent. It is a red herring, used to try to pretend that "those weird people who actually learn stuff" aren't getting anything done. People are not talking about haskell and clojure instead of working. That is the entire point.
http://www.paulgraham.com/avg.html
The tough problems that take most of the time are the design and theoretical understanding of the problem. The actual tools used to implement the solution, while not trivial in their differences, are never as important as fully understanding the problem and having a good architectural design.
Or put differently, if you found me the fastest, most knowledgable person in the world with PHP web development, and then found the same guy for Scala, my assumption is they would both build a particular project in the same amount of time, all other things equal. And I could guarantee that one of the two wouldn't be "dozens of times faster" than the other.
This haskell fizzbuzz is great: http://dave.fayr.am/posts/2012-10-4-finding-fizzbuzz.html
It's great having too many tools in your toolbox.
The initial time investment per tool is steep.
Also, the tools' values deteriorate rather rapidly. Languages/Frameworks will become less used over time as something new replaces them (generally), and even your specific skills with a language will get worse over time if you aren't using it.
Because I know what I'm doing best in PHP. So the site is going to do REST queries, but on the backend. We still have the ability to use the API in other clients, and we could in the future use shinyFrameworkOf2013.js, but for now we're building something we know will work.