Hacker News Reader

Comment by EpicEng | Hacker News Reader

I'm sure I'm going to get piled on here, but whatever. I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it. "This framework's the best!" "No, this one is obviously better!" "My design pattern is better than your design pattern!"

I don't know, maybe I'm a 32 year old curmudgeon, but I just don't see this in my area. I work at a lower level; robotics, image processing/analysis, and general systems level stuff. We worry about what technologies we use for a given task as far as it impacts our design goals, i.e., "which technology is best suited for the job" (and there are more options nowadays than there used to be). Our customers couldn't care less about how we got there as long as the final product kicks ass.

Once we arrive at a conclusion we move on and spend the remaining 99% of development solving actual problems. Hard problems. Often times unsolved problems. Our number one priority is reliability and accuracy (ok, that's two priorities). Whether or not we used e.g. C++ or Python to do it is irrelevant. What matters is that we built a system which works as it is supposed to and was engineered correctly.

I don't understand this 'programming for programming's sake' mentality. At the end of the day these are just tools, not an end goal. Help me to understand.

View on HN

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.

>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.

> 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.

Web development doesn't have many hard problems. It has one serious though. How not to get tangled in your own mess when customer is breathing down your neck.

Almost every language provides you with sufficient tools for writing algorithms, doing calculations, storing and accessing data, but almost none gives you solutions for avoiding mess.

There are many ideas on how to avoid mess but none of them works and people are left to their own devices to figure out how not to get lost.

That's why webdevelopers are so fascinated with frameworks. They promise solution to their one hard problem. And some even deliver it to a degree.

> Web development doesn't have many hard problems. It has one serious though.

Kind of a strange way to put it but I think I agree with the gist. Scaling is the web's hard problem. Building an ever expanding list of features while measuring if users like them and delivering them via cheap computers and tiny pipes is surprisingly difficult. Scaling a rigidly defined web system on it's own generally isn't so hard at this point. One off Twitter clones with a few of T's killer features can be knocked out in a few days with pretty good load scaling properties. But scaling the codebase and architecture from 1 dev, 0 users, and 1 OK feature to XXX users and YYY features users love is really hard to get right. Ideally the 100th feature is as easy as the 10th and you can just add more engineer hours, but more commonly it seems to get exponentially harder to add features as the codebase expands.

Systems always get more complex as you add features. At best you can avoid shooting yourself in the foot, but that's ok because none of your competitors can avoid the same issues.

The web's hard problem is dealing with that complexity at a speed and scale that is a few orders of magnitude bigger than any other programming environment I can think of.

> At best you can avoid shooting yourself in the foot

At best we can keep our systems simple, agile, and cut bad features as quickly as we test new ones (every damn day!).

MMO's are vastly more complex than websites. The issue with websites is they are inherently simple, and adding one dimension of complexity is still easy. But, when people continue to underestimate what adding features actually takes they snowball into unmaintainable crap.

PS: A single 1ghz CPU with a very fast connection could serve the simplest possible webpage to every single person on the planet in less than 1 day. Scaling is only an issue as you add complexity.

Web development is a bit like runaway sexual selection, but instead of developing extravagant plumage, webdevs develop extravagant frameworks and strive to rewrite everything in JavaScript.

Blog posts are a way of status signaling but also of fitness signaling. People that have the capability of always learning new things and writing about them should be really good programmers while lower quality individuals can't afford to keep up and drop out of the game. Only the former are able to reliably secure mates and reproduce, thereby perpetuating the cycle.

The true alpha of the group will build his or her own framework or transpiler.

What a great comment, I wish I could up vote this 1000 times !

And this rambling indecision of an article kinda leaves me staring into the distance, rethinking some priorities.

As someone who spends most of his time on "Hard Problems" but has done a fair share of web apps/CRUD apps I have to admit that web apps are deceptively hard. While going from zero to working prototype web app is trivial in any language, going from working prototype to fully secured, fast, scalable site that is easy to maintain, extend and deploy and easy to use across all devices and browsers is a massive pain in the ass and the difference between the right tool and the wrong tool can easily be an order of magnitude or more in time. Combine this with the fact that the time budget in most web projects is tiny, and the difference in tool choice can really make or break a project.

Basically stuff like Image Processing is trivial from an software design/architecture point of view since it's 90+% math and computer science so the the software 'architecture' tools don't matter. Non-trivial web apps on the other hand are 90+% an architecture problem so there those tools matter a great deal.

> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it.

Because writing web apps / CRUD apps is soul-destroying, boring, and always perceived by the client as easy (no matter how much business value they bring) so there's pressure to do them fast, as others have said. Any distraction is welcome, and any framework that makes the task less painful is welcome.

Both of which foster this fairly pointless set of discussions :)

32 year old curmudgeon here, in the middle of a large web app project...

FTFY: "I don't understand why those who spend most of their time __using tools__ focus so much on the tools they use to do it."

It should be more self-evident now.

When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker.

You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.

>You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.

True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business.

I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.

> I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.

Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.

"Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker."

Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument.

I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result.

The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world".

It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.

I've never had a problem moving to another language, I'll never understand why people pigeonhole themselves into categories like "rails dev" or "java dev".

The fundamentals are transferable, I don't even mention specific technologies or stacks these days if I don't have to.

Well, two things. Lots of people are good on the mechanics of a particular stack and weak on the fundamentals, making the description accurate.

And lots of people hire based on the assumption that expertise in a particular stack is the most important thing (perhaps in part as a result of the preceding point).

Definitely, which is how you end up with half of NPM's package repository.

It's not necessarily a problem, but it takes humility.

"When art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine." -- Pablo Picasso

Haha.

But there is a big difference between discussing tools and arguing about them like your career depends on a particular opinion being right.

Except, really, none of those analogues are accurate. Professionals in the other fields identified don't argue about told the way programmers, and particularly web devs, do.

The kind of tool-centered identification and tribalism seen in large segments of the development community is not only rare among other professionals, it's seen (usually correctly) as a sign of being an amateur that doesn't know the craft well in other fields.

To a point, but then it is just self indulgence. Comparing camera gear is huge in the photography world, but making a great picture is rarely limited by the gear. People spend so much time arguing over gear they never take any pictures.

I see a lot of the same thing when people argue over programming tools. Just go build stuff in whatever tool you feel comfortable in. Do not lose site that building stuff is the goal, not using some tool.

I work in embedded, web & app dev and for web or app dev, by far most customers really don't care what it is written in. They care about the end result only. So we can use whatever is the closest to the endresult already and that's not often something like Rails. More often than not it is actually Wordpress; someone in this thread mentions web projects are more often <100 hours than years (for embedded we think in years, web/apps in 1-3 months) that's why WP is working; our clients do not actually care about maintainability because it's a quick write and will be thrown away / replaced when it served it's purpose.

> Help me to understand.

Human nature, maybe?

People seem to like to form groups based on some random similarity (supporting the same football team, driving the same car model, believing in the same religion, being of the same race, etc..) and start fighting the opposite groups.

My favorite example is the following trivia from the "Planet of the Apes" movie:

"During breaks in filming, actors made up as different ape species tended to hang out together, gorillas with gorillas, orangutans with orangutans, chimps with chimps. It wasn't required, it just naturally happened."

Fair enough, I just wish those same people would spend more of their time building the next big thing instead of telling others how they use the current big thing.

Not from me, you aren't. I'm an old soldier in this game (by webdev standards of 6 months for a new framework) and I have tended to switch over to the latest stuff almost every year (projects, job change etc). It's just a common disease and herd mentality in this field to sling the latest cools. Our productivity is generally shit because instead of cranking out working code, we try to fit more tools to the box, probably to combat the repetitiveness and boredom. At the end of the day, it doesn't matter what language or frameworks we use, things still get fucked up because we never spend enough time to know the ins and outs of our tools.

It's certainly a luxury to not have to think about malicious input from the world wide web, and be able to try any tool you want and just try again if it misbehaves -- it won't empty your users' bank accounts.

> I don't understand why those who spend most of their time writing web apps / CRUD apps focus so much on the tools they use to do it.

> We worry about what technologies we use for a given task as far as it impacts our design goals

I don't see the difference.

As a 36 year old curmudgeon, I agree. I think the overabundance of framework/tool choices is resulting in decision paralysis. The C++ world doesn't (or at least it didn't) have this problem -- there's usually few standard ways to do something and it takes a only a few minutes to pick one. The rest of developer energies are spent on actual implementation.

There are no hard problems in web design, other than that browsers are a really shitty platform for delivering software, and there's never been a concerted effort to start from scratch and solve it properly once. Just loads of proprietary solutions which are security nightmares and poorly supported, and endless frameworks.

Start again. Burn it all down, and do it properly this time.

I think the problem is no one seriously reads Hawryszkiewycz anymore.

Seems everyone's trying to squeeze problems into fitting their solution/framework rather the other way around.

They're not arguing about technology as such, they're arguing about productivity. The specific problems are not hard, just the organisation and maintenance of the parts. So it does probably matter a lot for this kind of work.

Let me explain. You are looking from the outside at a community which has a lot of issues around languages, tooling and frameworks for complex historical and technical reasons. E.g. Things that developed over long periods of time, like desktop apps, had to be rebuilt in the browser in a decade. Ask any desktop application developer how fun they think client side web dev is in comparison. And you are then assuming that the difficulties of this community are because they are immature and not as wise as you. Hope that clarifies things.

>Hope that clarifies things

No, not really, and I don't think I assumed that at all. I think it is objectively true that debating the merits of e.g. Python v Ruby for years on end is an utter waste of time. This is not engineering, it's vanity. I can get behind the occasional spirited debate. Of course there are pros and cons to every tool, and we should know what those are, but at the end of the day that's all they are; tools. They're middle men in the problem solving process, not the end result.

BTW, your current web protocols and frameworks are going to change again, just like your decrepit old desktop technologies did. Be prepared to denounce your current toolset and fervently embrace another in the near future.

I think it 's because of the number of young/unexperienced developers in the field. Those are the ones spending (wasting) a lot of time debating the relative merits of frameworks, languages, editors. More experienced people don't care as much.

>I think it 's because of the number of young/unexperienced developers in the field.

I honestly think this is it. Webdev has an inordinate amount of "let's rewrite it... again!" But the thing that really cinched the webdev community isn't ready for primetime was the whole left-pad debacle. Auto updating of dependencies is bush league bullshit, and the whole rotten edifice came predictably crashing down because of it.

They are tools, but some tools are more enjoyable for people to work with than others (and we don't agree on which ones), and when you're spending a substantial percentage of your life working with those tools, then working with something you enjoy matters.

For some, the tools they work with doesn't matter or doesn't affect their enjoyment. Great for them. But for me it does. Working in a language or with a framework I don't like is a constant stress factor because I keep hitting things that annoy me.

Personally, I don't touch Python projects if I can avoid it, for example, because I don't enjoy working with Python. It's got nothing to do with objective issues with it, and everything to do with subjective issues that affect my enjoyment. If I work with something I enjoy, I will be more motivated and put in a better effort, and will overall be happier.

> Be prepared to denounce your current toolset and fervently embrace another in the near future.

Awesome. While I like my current stack, I've changed it many times during my career because I found something I liked better. And sometimes I've had to put my preferences aside and pick something for more pragmatic reasons, and that's ok, but I most of the time have the luxury of being able to turn down work if I don't thnk I'll enjoy it.

Reply on news.ycombinator.com