Comment by themgt | Hacker News Reader

Comment by themgt | Hacker News Reader

Parent Full thread

What is the average number of hours you spend on a given project? Honestly I think part of the reliance and importance placed on frameworks is that a lot of web dev (especially contract/freelance work) is still relatively small projects, stuff between 10-100 hours of work.

So you're almost never spending 99% of your time solving unsolved, hard problems. You're building custom solutions to relatively common but special-snowflake problems. And in that context, you need a framework because in effect you're building a 1000 hour project but only spending 40 hours doing some configuration, customization and polish on top of a framework. Could you spend 1000 hours and build something from scratch and forget a framework? Sure, but no one wants to pay for that. So the framework you use is the giant's shoulders you stand on.

Rails didn't beat PHP and Java for webdev because hipsters think it's cool. It's because developers delivered projects better and faster with Rails, because it lets you spend less time re-solving the same solved problems which still comprise a lot of modern web development.

> Rails didn't beat PHP and Java for webdev because hipsters think it's cool.

I despise Ruby, PHP, and Java, but there is no objective argument that Ruby has "beaten" PHP or Java. It hasn't even beaten Python. It's tiny compared to the largest back-end languages.

Edit: evidence below:

- Ruby is used by 0 of the top 15 most-visited sites[1] (Twitter doesn't use it anymore). Java is used by 7 of them. PHP is used by 3.

- Job listings on Indeed asking for Ruby skills are far behind Java and PHP[2].

- W3Techs shows that 82.2% of all websites reporting their backend language are using PHP. Ruby is 0.6%.[3]

- Ruby is not even in the ballpark of Java on Github. It has a similar number of repos as PHP.[4]

1. https://en.wikipedia.org/wiki/Programming_languages_used_in_...

2. http://www.codingdojo.com/blog/9-most-in-demand-programming-...

3. https://w3techs.com/technologies/overview/programming_langua...

4. http://githut.info/

As a Ruby developer who gets paid to work with PHP daily, the reason 82.2% of all websites report a PHP backend is because 82.2% of all websites can only afford a PHP backend.

PHP developer salaries lag well behind market average for pretty much the same skillset. The tooling around PHP on the web is a wreck because you get what you pay for. Java isn't that much different -- I see tons of Java jobs I don't want in NYC for $60k wanting 5 years experience.

Who is taking all of these jobs we don't want? More is not necessarily better.

Don't forget the huge number of those 82.2% (is that made up on the spot) websites are likely built on wordpress as well.

~80% is what I've been hearing for a while from various reliable sources so I'd wager it's not far from there.

The real reason PHP is everywhere is because PHP is everywhere. It used to be that the only major host that didn't offer it was Google App Engine but that was resolved ~3 years ago. Since it's everywhere - and the vast majority of people don't care about the technology under the hood - they just choose the first thing that works.

Odds are that's a one-click install of WordPress. They do that. They add their content. Then they move on to their actual business.

Other than software developers, people don't care about the code under their website as long as it a) keeps working and b) no, that's it. Even security is an afterthought for most of these people.

Scala is where it's at for higher paying jobs, I agree PHP and Java are generally low paid because of baggage.

I pitch that as a benefit. You get my expensive skills and when I've built it you get a cheap replacement of me for maintenence.

I didn't mean to suggest people shouldn't write Ruby or that one language is better than the others. I was just stating (and backing up) a fact about web programming. Whether you think it's unfortunate, fortunate, or neutral is up to you.

I don't disagree, but your last point is rather misleading as Java on Github also includes pretty much all Android projects.

All of the different data points are imperfect measurements, which is why I attempted to include many angles.

> Ruby is used by 0 of the top 15 most-visited sites

The majority of projects are not the next twitter or facebook, but something with a limited scope to be done as fast as possible

I think you are interpreting it the wrong way (and I don't even mean that you wrongly equate Ruby with Rails).

If you look at the existing web frameworks, how many of those are RoR clones? That's what I see when somebody says "Rails won".

I completely agree that Rails (and Rails-inspired frameworks, like Laravel and Sails) has won. I was disagreeing specifically with the assertion that Ruby has beaten PHP or Java.

I wouldn't put much weight on GitHub language stats because there's a lot of duplication, and people check in libraries and tooling (usually JS, it seems) that overwhelm whatever language they're actually using.

>What is the average number of hours you spend on a given project?

That's a fair point; my project plans are usually measured in years, not hours. Of course there is ongoing maintenance, but that's not where I spend most of my time.

I didn't mean to imply that tools aren't important, or that we shouldn't care. We absolutely should care, and I do as well. The difference is that I don't feel the need to spend copious amounts of time defending my tools, or debating their merits with other people who will never agree with me.

I evaluate them, use them, and move on. They are an integral part of my process, but not nearly as important as building something that solves real problems.

It's the same old issue of religion v enthusiasm, belief v fanaticism. That line gets crossed too often and it's just a waste. I think some lose sight of what's important.

Part of the reason it matters more to web developers is that often our clients and employers do care what we use and if we love a particular tool it needs widespread adoption to be able to use it on real work. I have potential clients asking constantly if I can build their project with WordPress or Rails or Drupal or Symphony or whatever else they think is the best. It would be much better if they just came and asked if I could build it and let me help them determine what is the best platform for their project and pre-existing skill set.

Now, sometimes, they have a legitimate need to have it integrate with a larger system and using that tool has external advantages. But most of the time it is just a vague notion that if it is in WordPress it will be easy to use, cause you know, anyone can edit a WordPress site. But when you bolt a hundred plugins and custom business logic into WordPress, it makes no difference that it has any easy blog editor. That should have been a separate project to begin with. Half the time they have built 10% of what they need with a dozen plugins, think they are 90% done and that I can just make the rest of it work. This because someone told them there were plugins that could do everything they needed in WordPress and with WordPress they'd get good SEO.

The point is that if we want to use a particular tool, we better evangelize for it, because clients never want something built in a framework they haven't heard of. It's not even irrational for the clients, since 50% of the time their developers disappear before the project is done and they have to find someone else who can pick it up and finish.

Yeah, it made me smile when a non-technical friend had narrowed down the choice of languages for the project he wanted to build.

"Python, Java or <something else>" Python and Java are relatively opposite ends of the web dev spectrum, and he didn't code so it was likely based on rants from the programmers around him.

In the end his project failed because he couldn't find any Django devs to continue the project for a relatively low wage. He might have found some PHP devs if he had chosen that.

We're a small Django shop and I do weigh up this when deciding if we're the best option for a prospective client. If we build them a site then there is a maintenance cost that is potentially higher than there would be with a PHP site.

Of course - the counter-argument is "a good PHP dev is no cheaper and just as hard to find" but for maintenance tasks you might only need an average (or even mediocre) dev - and it's a hell of a lot easier to find an average PHP dev than an average (insert less popular choice here) dev.

> average (or even mediocre) dev

doesn't mediocre mean average?

I think it has probably now developed a more negative connotations by now:

"good < average < mediocre < bad"

sounds about right to me.

WordPress is a valid question/option for them if they have a large amount of content they have to add using their marketing staff instead of more expensive developer consultants.

It also is if they don't have a years-long working relationship with you, because who is going to maintain all of this when you're gone? At least if they have to dump your work and build a new theme, they don't have to worry about figuring out a whole new data model (most of the time).

WordPress done the right way uses plugins sparingly to get the job done, outside of obvious ones like Advanced Custom Fields Pro and Post 2 Post Links.

WP isn't bad per-se, it's just the majority of people who work on it (and let's be honest, who built it) are/were rank amateurs.

> WP isn't bad per-se

From a data standpoint, yes, WP is bad. Really bad. The poor quality code base of WP is only one half of the equation. The other half is the downright awful, novice database schema that ships with it. I've never seen a database schema that is so tightly coupled with the parent application that it essentially hijacks your data into always needing itself simply to extract and render data. WP takes the "relational" out of relational database and flushes it down the toilet. To add to the mess, instead of fixing the rot of its database schema and data handling functionality, WP developers, in their infinite wisdom, merge a woefully incomplete, faux-API system into WP's core, thereby further sealing the door of ever having a clean, thoughtfully designed database that one can access outside of WP and PHP.

it's some bad db choices at core that get multiplied to many other plugins as well. and... sessions in the database - why are they in wp_options? Still to this day that makes no sense to me.

@mtbcoder I always thought WordPress's schema issues were a function of it trying to be generic enough that it can accommodate everyones "vision". What are examples of it's "novice database schema"?

> WordPress done the right way uses plugins sparingly to get the job done, outside of obvious ones like Advanced Custom Fields Pro and Post 2 Post Links.

We don't give credit to how good some plugins are, either.

In my current web app I've had to add user-defined custom fields to a few entities. It's been a nightmare (Symfony2's form library isn't designed with this in mind) and the user experience is nowhere near as nice as ACF.

And for web apps, the user experience is as important as what it does. I wouldn't want to build this application on WordPress, but having components like ACF already present, so I don't have to reinvent the wheel, is making me seriously consider it for the next project.

That's all true, and I do "backend" stuff so I'm in the same boat as you, but I think you might still not get the point of the more-projects-faster thing:

To be competitive, web devs need to be working with the most popular framework, which has the most modules which are maintained (for stuff like "log in with facebook" or "publish photo to twitter" or "get weather for visitor's geo-ip location").

All this pre-packaged functionality does require some time to get familiar with, it's an ecosystem on top of a language with many DSLs.

So they need to make their team win, or join the winning team early. Or else they don't feel like they can compete.

It's a really big marketplace for web sites/apps out there, many small businesses get new-from-scratch websites every 2 years or less ... new shiny design drives consumer interest, it's not like they could afford for the old one to be maintainable anyway.

Your project plan is measured in years?

All the orange crops just froze over from the chills running down the backs of all the Agile\Lean practitioners.

Turns out that it is very hard to deliver any hardware project in a purely Agile environment - it lacks the capability for careful delivery of long lead time/critical path items, as well as failing to neatly fit into a sprint.

Reply on news.ycombinator.com