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.
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 ;).
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.
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.
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 love how YouTube approached this: Choose the simplest and most stable tools and use those.
It's a great strategy for developers that want to ship. Otherwise one can easily be lured by the siren calls of new tech.
I've certainly fallen victim to this temptation, but I've found that as I let go of the new pretty things and focus more on using the old boring workhorses of the interwebs, I get a ton more done.
Plain vanilla seems boring - but it's bad-ass in web architecture. We forget that YouTube had plenty of competitors that were well ahead them before they dominated.
They kept things simple and solid and that allowed them to scale. It's certainly not the only reason they won, but I'd bet it's a huge part of it.
It blows my mind sometimes, looking at a web page made of mostly simple text and a few images, to view the source and see page after page after page of CSS and javascript just to make something that looks only slightly better than
"Slightly better" is a subjective assertion. Especially in the webdev world where the pace of design and functionality improvements tend to move so fast. Granted, you may display the same/similar information in a text-only page, such as your example. But you won't be engaging users much or creating a site that people will want to see & return to, which is where the money that is spent on webdev work generally comes from.
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.
I'm far from an expert coder compared to most on here...but...what's the big deal? Once you've grokked server-side code and framework, is it really that hard to move from Rails to Sinatra or even to Django? Once you know databases, how hard is it to switch from SQLite to Postgres or to even Mongo? Same goes with Javascript frameworks.
Now, I'm referring to the scope of what a web-developer needs to know to interface with these technologies...obviously, a database engineer is expected to dive deep and know all the quirks/limitations of NoSQL vs SQL.
Is the complaint that "Oh shit, I don't know if I can learn new syntax?" Or is it more, "The hiring market is segmented by too many technologies for me to claim to be an expert at?"
I'm a .NET developer by day, and I've met numerous Java developers that have crawled into a .NET role, either as a contractor/freelancer or into a entry/mid-level role at a company, claiming that because they are fantastic Java developers they can pick up C# in no time at all.
Yes, if you have been programming for a number of years then the syntax will come quickly, and you'll find yourself able to use the language. Top that off with an existing code-base and it's fairly easy to get started and to write some usable code. However, in my experience, the kind of ego's we see on sites like Reddit and HN either churn out:
1) Decent code, but only after comparing their own code to what is already out there out of fear of writing something that people will laugh at, regardless of if it works or not.
2) Code that looks like a Java developer wrote it, either rewriting methods that are already a fundamental part of the .NET framework, not using LINQ/Lambdas or anything from C#2-4 and failing to use any of the built-in tools within Visual Studio to check code.
The better programmers fully immerse themselves in the differences between the languages and how they are used. They have chosen to use this new language/framework for a reason, and they enter that world knowing why they did so and what they need to know to become productive for that given task.
As I'm sure everyone on here understands, there is a huge difference between being able to write some code in a given language and working on a given project in that language with others.
> "The hiring market is segmented by too many technologies for me to claim to be an expert at?"
I think that's a concern to many new programmers (myself included) when looking at the pace these tools and frameworks are coming out and then maturing.
Learn technologies that are popular, such as jQuery. The community will help make this easy. You will use jQuery on almost every project, so this will be time well spent.
Master components that are core, such as JavaScript. You will use JavaScript on every project. A true understanding will be essential to everything you choose to do with it. It amazes me how many developers do web development without ever trying to learn how to write effective JavaScript.
Lastly, do something just for fun. Programming is fun, enjoy it once in a while. Try a new language you will probably never use. Use a new framework or library. Look into something old. It is amazing how many old things are new again.
Do all this and the web won't be such a scary place.
I think its so great that we have so many new toys and such innovation going on in the world of the web. I remember when I was first starting out as a developer (when I was 10, it was 1996, I wasn't very good) all we had was HTML and CGI scripting. CSS was the new hotness that no one understood and PHP was just learning to crawl. Those two technologies were all there was and I don't remember other developers ever going nuts like an adoloscent girl at a Beatles concert over any of the stuff that was coming out then. It really is nuts how we push all this latest and greatest stuff only to abandon it next week. I remember just about a year or two ago the HN community was in absolute love (like 'The Notebook' style, forever and ever, everlasting love) with Rails - even more so than now. There were endless debates over its merits and its pitfalls and I watched as the people who took those debates the most personally agonized over every small bit of the development process while those who didn't really care as much just built stuff.
It really is great that these new toys are coming out but what I see as the real problem is that we lose sight over one particular piece of the bigger picture. We forget to ask ourselves "Does this solve my or my users' problem(s)"? Even when we do ask that question we then get caught up over minutia like the elegance of code and performing between two competing tools.
That stuff doesn't matter yet! What matters is that you grasp the concepts the tool promotes and can use it effectively. Beyond that there's usually not much difference in the "elegance" or performance of your code between two tools and it usually comes down to subjective views and how you work. Even if you do choose the "optimal" tools you're most likely fucking up some other part of your codebase anyway. None of us write perfect code. That's why refactoring is a thing.
Are you stuck when it comes time to choose handlebars or mustache? Can't decide between Ember and Backbone? Is Rails or Sinatra better? CodeIgniter or Laravel? Thinking of using Django over... uh... whatever the competitor to Django is? Then you've got your head stuck way too far up your ass and focusing on the wrong thing. I don't mean to offend with that crack - I too have had my head up my developer ass many times before and all it got me was a 'Hello World' page in a project that was stalled before it even started.
So my point is that using the new hotness is fun and challenging and it can do you a lot of good but the moment you stop developing and start chasing the new hotness you've become kind of a tech groupie rather than a developer.
The analysis paralysis on which tools to use really comes from lack of focus on which problems you wish to work on. Many people are either told what problem to work on (employees), or have an unclear focus (I just want a job, any job!).
Therefore, they feel they need to learn and use every tool so that they can be prepared for "choosing the right tool for the job".
The solution is to focus on projects of your choosing. When it's clear that your problem is a nail, you can tackle it with any tool that can pound with force: hammer, mallet or shoe heel will all work; frozen cucumber will not. In other words, there are clear wrong choices - get rid of those and pick one of the right ones. The paralysis melts away once you have a problem around which to frame your analysis.
Another beautiful thing about web development: you can learn to use a hammer (let's say, Rails) and you can use that hammer to pound a million nails.
It's a fallacy to think that you have to learn everything, every methodology, so you can be prepared for some ambiguous future project, in hopes of solving some unforeseen problem.
This approach has another great side effect: you won't be easily side tracked by the new shiny thing that promises async evented dilly every few months. If it doesn’t solve YOUR problem, move on.
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.
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.
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
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..
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.
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.
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.
Web Development is fine, it's the Javascript, and especially the frontend world that's the problem.
Why do we bother with a language that's inconcise, lacks so many common, useful functions (enumerals, strings, etc), and general doesn't do what we want it to do? In spite of fundamental problems, people try to address them with custom solutions. Those are inherently very PERSONAL solutions - because everyone wants to do it well and better - bound to raise discussion and competition at some point. That's what's happening. People are trying to fix something broken with their own, idealistic ideas.
There's nothing wrong with that, don't get me wrong, but I think we all know that we can do better on a more fundamental level.
I'm shocked nobody has pointed this out, but we "bother" with javascript because it runs in browsers, and browsers are ubiquitous. Why does everyone who has personal issues with Javascript or web development in general seem to forget that it has become popular because of the webs ubiquity and the promise of cross-platform development?
Day to day I work in C++. I've also used many much more elegant languages, Python, Haskell, etc. Right now I'm doing web development in my spare time, and I don't see where this hate for JavaScript is coming from. Sure, it might not be the prettiest language in the world, but who cares? It's what's available to us, and I'm actually quite satisfied it's JavaScript and not something worse. I don't seem to care half as much about languages as the average hacker news reader, I'm not sure why. I care about what I'm trying to create.
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.
I like many of the state of the art frameworks, especially backbone.js and I'm really thankful for how much impact they had on making complexity in web apps manageable. That said I absolutely agree with you regarding the fragmentation problem which seems more like a stack problem to me.
For me personally it looks like what the web desperately needs is a common ground for how widgets work and behave. Web Components look like what we will get and I really can't wait to see that happen:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/...
This has been my experience, too. But I think it's wrong to jump to the conclusion that because going too far and having to learn too much is a bad use of time that you should just stick to one or two things. This is black-and-white thinking and I think in this case, your response should be in the context of the problems you face and the career you are building.
We do need to move along with technologies if we want to stay relevant. But you need to know what's a fashion and what's worth adding to your skillset. After leaving University I mainly knew Java but I learnt PHP and JavaScript because I wanted a web development job; later on I felt that none of the cool startups were using PHP and all of its warts had become very apparent to me so I picked up Python which seemed a lot more elegant. (However this was more a case of fashion that gave me access to higher-impact and higher-salary jobs. My actual needs to code in a general-purpose language with nice libraries isn't a worthy goal in itself.)
Currently I am working entirely in Node.JS and I don't consider myself to be drinking the Kool Aid because it made more sense to stick to one programming language and I needed long-running processes. I do have to be careful to not add too many libraries, however. There is so much activity in the JavaScript world currently.
I say you should focus on your career and wherever you see that leading you. To a certain extent programming languages and libraries will come and go (they will coalesce on principles so this is worth paying attention to), but architecture remains the same, social structures and positions remain the same, and sales remains the same. Apply yourself where you can see the maximum potential for personal growth and personal growth that doesn't slip (as it will when you have spent 20 years programming using the library X and everybody else switches to Y.)
I don't agree with this rant. Just becuase 50 libraries exist doesn't mean you have to be an expert in all of them or even use all of them.
I think it's great that so many frameworks are sprouting up, and once you've been around long enough, it shouldn't take more than a weekend to try one, see the benefits, and use it or learn from it and move on.
Since when is having more choice bad?
I've been out of web development for a number of years, and it is delightful to have all these options now. I am loving working with knockout.js and looking forward to trying ember next.
[+] [-] rpeden|13 years ago|reply
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.
[+] [-] barredo|13 years ago|reply
@agentdero
https://twitter.com/agentdero/status/174965036928868352
[+] [-] eranation|13 years ago|reply
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 ;).
[+] [-] freework|13 years ago|reply
[+] [-] MitziMoto|13 years ago|reply
[+] [-] api|13 years ago|reply
[+] [-] daenz|13 years ago|reply
[+] [-] smutticus|13 years ago|reply
[+] [-] benihana|13 years ago|reply
[+] [-] purephase|13 years ago|reply
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.
[+] [-] dgesang|13 years ago|reply
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).
[+] [-] mattjaynes|13 years ago|reply
It's a great strategy for developers that want to ship. Otherwise one can easily be lured by the siren calls of new tech.
I've certainly fallen victim to this temptation, but I've found that as I let go of the new pretty things and focus more on using the old boring workhorses of the interwebs, I get a ton more done.
Plain vanilla seems boring - but it's bad-ass in web architecture. We forget that YouTube had plenty of competitors that were well ahead them before they dominated.
They kept things simple and solid and that allowed them to scale. It's certainly not the only reason they won, but I'd bet it's a huge part of it.
---
For more on YouTube's stack, see: http://highscalability.com/blog/2012/3/26/7-years-of-youtube...
[+] [-] bane|13 years ago|reply
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T...
[+] [-] inigoesdr|13 years ago|reply
[+] [-] saltcod|13 years ago|reply
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
[+] [-] skeletonjelly|13 years ago|reply
[+] [-] danso|13 years ago|reply
Now, I'm referring to the scope of what a web-developer needs to know to interface with these technologies...obviously, a database engineer is expected to dive deep and know all the quirks/limitations of NoSQL vs SQL.
Is the complaint that "Oh shit, I don't know if I can learn new syntax?" Or is it more, "The hiring market is segmented by too many technologies for me to claim to be an expert at?"
[+] [-] EnderMB|13 years ago|reply
I'm a .NET developer by day, and I've met numerous Java developers that have crawled into a .NET role, either as a contractor/freelancer or into a entry/mid-level role at a company, claiming that because they are fantastic Java developers they can pick up C# in no time at all.
Yes, if you have been programming for a number of years then the syntax will come quickly, and you'll find yourself able to use the language. Top that off with an existing code-base and it's fairly easy to get started and to write some usable code. However, in my experience, the kind of ego's we see on sites like Reddit and HN either churn out:
1) Decent code, but only after comparing their own code to what is already out there out of fear of writing something that people will laugh at, regardless of if it works or not.
2) Code that looks like a Java developer wrote it, either rewriting methods that are already a fundamental part of the .NET framework, not using LINQ/Lambdas or anything from C#2-4 and failing to use any of the built-in tools within Visual Studio to check code.
The better programmers fully immerse themselves in the differences between the languages and how they are used. They have chosen to use this new language/framework for a reason, and they enter that world knowing why they did so and what they need to know to become productive for that given task.
As I'm sure everyone on here understands, there is a huge difference between being able to write some code in a given language and working on a given project in that language with others.
[+] [-] hipsters_unite|13 years ago|reply
I think that's a concern to many new programmers (myself included) when looking at the pace these tools and frameworks are coming out and then maturing.
[+] [-] nahname|13 years ago|reply
Master components that are core, such as JavaScript. You will use JavaScript on every project. A true understanding will be essential to everything you choose to do with it. It amazes me how many developers do web development without ever trying to learn how to write effective JavaScript.
Lastly, do something just for fun. Programming is fun, enjoy it once in a while. Try a new language you will probably never use. Use a new framework or library. Look into something old. It is amazing how many old things are new again.
Do all this and the web won't be such a scary place.
[+] [-] anons2011|13 years ago|reply
Also reminds me of this tongue in cheek site : http://html9responsiveboilerstrapjs.com/
[+] [-] equator|13 years ago|reply
[+] [-] spuz|13 years ago|reply
[+] [-] bpatrianakos|13 years ago|reply
It really is great that these new toys are coming out but what I see as the real problem is that we lose sight over one particular piece of the bigger picture. We forget to ask ourselves "Does this solve my or my users' problem(s)"? Even when we do ask that question we then get caught up over minutia like the elegance of code and performing between two competing tools.
That stuff doesn't matter yet! What matters is that you grasp the concepts the tool promotes and can use it effectively. Beyond that there's usually not much difference in the "elegance" or performance of your code between two tools and it usually comes down to subjective views and how you work. Even if you do choose the "optimal" tools you're most likely fucking up some other part of your codebase anyway. None of us write perfect code. That's why refactoring is a thing.
Are you stuck when it comes time to choose handlebars or mustache? Can't decide between Ember and Backbone? Is Rails or Sinatra better? CodeIgniter or Laravel? Thinking of using Django over... uh... whatever the competitor to Django is? Then you've got your head stuck way too far up your ass and focusing on the wrong thing. I don't mean to offend with that crack - I too have had my head up my developer ass many times before and all it got me was a 'Hello World' page in a project that was stalled before it even started.
So my point is that using the new hotness is fun and challenging and it can do you a lot of good but the moment you stop developing and start chasing the new hotness you've become kind of a tech groupie rather than a developer.
[+] [-] cglee|13 years ago|reply
Therefore, they feel they need to learn and use every tool so that they can be prepared for "choosing the right tool for the job".
The solution is to focus on projects of your choosing. When it's clear that your problem is a nail, you can tackle it with any tool that can pound with force: hammer, mallet or shoe heel will all work; frozen cucumber will not. In other words, there are clear wrong choices - get rid of those and pick one of the right ones. The paralysis melts away once you have a problem around which to frame your analysis.
Another beautiful thing about web development: you can learn to use a hammer (let's say, Rails) and you can use that hammer to pound a million nails.
It's a fallacy to think that you have to learn everything, every methodology, so you can be prepared for some ambiguous future project, in hopes of solving some unforeseen problem.
This approach has another great side effect: you won't be easily side tracked by the new shiny thing that promises async evented dilly every few months. If it doesn’t solve YOUR problem, move on.
[+] [-] davidw|13 years ago|reply
I'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.
[+] [-] lifeisstillgood|13 years ago|reply
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.
[+] [-] Cthulhu_|13 years ago|reply
But ZOMG RAILS IS INSECURE, quick, switch to something else! [/sarcasm]. Evaluating other technology is the opening of the rabbithole.
[+] [-] static_typed|13 years ago|reply
[+] [-] damian2000|13 years ago|reply
[+] [-] raverbashing|13 years ago|reply
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
[+] [-] marknutter|13 years ago|reply
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..
[+] [-] bungle|13 years ago|reply
These days backend is pretty straight forward, mature, and usually easy compared to client side.
[+] [-] dubcanada|13 years ago|reply
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.
[+] [-] 42tree|13 years ago|reply
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!
[+] [-] cygwin98|13 years ago|reply
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.
[+] [-] ttflee|13 years ago|reply
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.
[+] [-] beefsack|13 years ago|reply
It's great having too many tools in your toolbox.
[+] [-] baak|13 years ago|reply
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.
[+] [-] timonv|13 years ago|reply
Why do we bother with a language that's inconcise, lacks so many common, useful functions (enumerals, strings, etc), and general doesn't do what we want it to do? In spite of fundamental problems, people try to address them with custom solutions. Those are inherently very PERSONAL solutions - because everyone wants to do it well and better - bound to raise discussion and competition at some point. That's what's happening. People are trying to fix something broken with their own, idealistic ideas.
There's nothing wrong with that, don't get me wrong, but I think we all know that we can do better on a more fundamental level.
[+] [-] marknutter|13 years ago|reply
[+] [-] purplelobster|13 years ago|reply
[+] [-] otibom|13 years ago|reply
[+] [-] Torn|13 years ago|reply
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.
[+] [-] Kototama|13 years ago|reply
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.
[+] [-] tosh|13 years ago|reply
For me personally it looks like what the web desperately needs is a common ground for how widgets work and behave. Web Components look like what we will get and I really can't wait to see that happen: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/...
Here are some examples from Dart Web UI (web component polyfills for Dart) http://www.dartlang.org/articles/dart-web-components/
Also here is a great article about the web stack fragmentation that you might be interested in: http://zef.me/4835/dart-web-fragmentation-vs-web-development...
Exciting times, Thomas
[+] [-] lhnz|13 years ago|reply
We do need to move along with technologies if we want to stay relevant. But you need to know what's a fashion and what's worth adding to your skillset. After leaving University I mainly knew Java but I learnt PHP and JavaScript because I wanted a web development job; later on I felt that none of the cool startups were using PHP and all of its warts had become very apparent to me so I picked up Python which seemed a lot more elegant. (However this was more a case of fashion that gave me access to higher-impact and higher-salary jobs. My actual needs to code in a general-purpose language with nice libraries isn't a worthy goal in itself.)
Currently I am working entirely in Node.JS and I don't consider myself to be drinking the Kool Aid because it made more sense to stick to one programming language and I needed long-running processes. I do have to be careful to not add too many libraries, however. There is so much activity in the JavaScript world currently.
I say you should focus on your career and wherever you see that leading you. To a certain extent programming languages and libraries will come and go (they will coalesce on principles so this is worth paying attention to), but architecture remains the same, social structures and positions remain the same, and sales remains the same. Apply yourself where you can see the maximum potential for personal growth and personal growth that doesn't slip (as it will when you have spent 20 years programming using the library X and everybody else switches to Y.)
[+] [-] SonicSoul|13 years ago|reply
I think it's great that so many frameworks are sprouting up, and once you've been around long enough, it shouldn't take more than a weekend to try one, see the benefits, and use it or learn from it and move on.
Since when is having more choice bad?
I've been out of web development for a number of years, and it is delightful to have all these options now. I am loving working with knockout.js and looking forward to trying ember next.
[+] [-] acuozzo|13 years ago|reply
http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_ch...