What ORMs have taught me: just learn SQL (2014) - <AUTHOR> http://wozniak.ca/what-orms-have-taught-me-just-learn-sql <comment><USER2> Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit.

In 2016, this sentiment is outdated. A few points:

1\. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL _or_ their chosen ORM. An ORM provides type checking at your application layer, and typically better performance (unless you plan on hand-rolling your own multi-level cache system). But you still must understand relational database fundamentals.

2\. If you're not using an ORM, then you ultimately end up writing one. _And doing a far worse job than the people who focus on that for a living._ It's no different from people who "don't need a web framework", and then go on to re- implement half of Rails or Spring (without accounting for any CSRF protection). Learning any framework at a professional level is a serious time investment, and many student beginners or quasi-professional cowboys don't want to do that. So they act like their hand-rolled crap is a badge of honor.

3\. Ten years ago, it was a valid complaint that ORM's made custom or complex SQL impossible, didn't play well with stored procedures, etc. But it's 2016 now, and this is as obsolete as criticizing Java by pointing to the EJB 2.x spec. I can't think of a single major ORM framework today that doesn't make it easy to drop down to custom SQL when necessary.

<comment><USER3> > If you're not using an ORM, then you ultimately end up writing one.

I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, "fat models", etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from your framework with an ORM). For convenient access you can roll 30 lines of Perl to wrap DBI or whatever (I use Perl for most web backends these days) and call your stored procedures in normal syntax with a little metaprogramming.

Maybe this sort of scheme (heavy usage of stored procedures and offload almost everything to the DB) doesn't work for everyone, but I like databases and it works for me.

<comment><USER4> How do you manage version-control on stored procedures? Can they be checked in with the rest of the application logic?

<comment><USER5> I myself am wary of stored procedures except in very specific and uncommon circumstances. That said, you could absolutely version control your stored procedures by creating them from within database migration files that are version controlled by default.

<comment><USER6> What is the source of the wariness?

<comment><USER7> Don't know about the parent, but I always felt that stored procedures end up by incorporating a good share of the business logic, extracting it from the main code of the application. This creates a messy situation in which you have your business logic split up between two completely separate and different systems, one of which (the stored procedures) is much harder to read, write, maintain and test. That said, I also deeply hate ORMs, I much prefer to use thinner layer to interface with a database (query builders and row mappers).

<comment><USER6> I also do think putting too much logic in stored procs is a danger, and was/is a scourge for some shops. But was curious if that is the primary objection.

<comment><USER8> I try to avoid anything but mapping or querying data in sprocs, but sometimes they are a better place to put logic that is needed to ensure consistency. Your database will outlive your application, or you will eventually need to integrate data from a third party system - as a result your database engine is always the last line of defense to protect your data, and if that means using a sproc than so be it. I'll admit, I've written _some_ business logic into stored functions in PostgreSQL, but it's mostly a background job to update cached data because it is much faster to do it in the database than pulling a bunch of records down to a service and sending them back up.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> I like to say "ORMs make easy thing easier and hard things harder".

What i mean by that is, any simple CRUD operations are much easier in ORM. The hard things, i mean any complex queries that need more than one join you are probably better of writing yourself.

In the end i prefer to do inserts, updates and deletes with ORM (or some other database abstraction tools) but most SELECTs i write myself, fetching exactly what i need and mapping result to objects if needed manually.

<comment><USER10> Do uou use metadata from the db driver to do type mappings?

<comment><USER9> Not sure what you asking about. Do you mean if I define database structure in my code? The answer is: yes. I don't know about any database abstraction library that would provide you with convenience methods to query database with type checking and stuff without giving it the schema.

</comment></comment></comment><comment><USER11> Not this again. Why is this coming up at all in 2016? There isn't even a valid debate here.

ORMs are a tool, that's it. The relational operations of SQL and the object- oriented (or functional) logic of your application code are usually very different and it's nice to have a mapper that lets you interact with your app's language while it takes cares of automatically mapping it to SQL.

For 99% of database ops where it's pulling some stuff out, editing some fields and then saving it back, an ORM will save you a massive amount of time with better safety, security and performance. Even complicated queries/mappings/procedures run pretty well and you can always write raw SQL when you need it. Modern ORMs will even let you execute custom SQL and still give you conveniences like easy parameterization and hydrating the results back as objects.

Maybe I've been spoiled with the .NET ecosystem with great ORMs like NHibernate, EntityFramework, and Dapper (along with C# features like Linq) but it seems like most of these complaints are from people who use shitty ORMs or can't comprehend that it's just a tool that they can choose to use or skip, at very granular method by method level. There's absolutely no reason for any extreme here.

<comment><USER12> My experience with hibernate, entity framework, nhibernate, and lastly dapper has basically left me thinking Dapper is all you'll ever want. I can't imagine a use case where I'd rather opt for NHibernate or EF at the moment.

(I might add, Dapper in combination with C#6 even gives me enough type saftey to be happy. String interpolation and the nameof operator complements dappers DTO approach nicely)

Since you seem to have similar experiences Im curious. When would you ditch dapper for the others?

<comment><USER13> Do you use a Dapper extension for populating and persisting entities? (Last I looked at it as I recall this wasn't default functionality.)

<comment><USER14> Dapper does have very low-level basic functionality to insert or update entities. You need to write the SQL yourself so this gets very painful very quickly for complicated models where you want to persist child objects.

That someone would say "Dapper is all they need" leads me to think they only work on very small projects. You will drown in large projects if you use Dapper everywhere. Better to use a high level ORM like EntityFramework and sprinkle in some Dapper in performance critical code.

The only time EF creates performance problems is when the developer doesn't understand the concepts behind SQL. This isn't an ORM problem, it's a training problem.

<comment><USER12> As I see it, if your model is trivially mapped, you could probably go with something like ormlite on top of dapper. But if you need to custom map you model anyway you might just as well write SQL to map it as some custom dsl mapping thing for the ORM in question.

And, I don't use dapper for performance, I actually like its transparency and friction free interface to the db. Let's me get things done without workarounds. And most importantly, lets me use ssms with a repl flow, copying sql verbatim between vs and ssms.

</comment></comment></comment></comment></comment><comment><USER15> I think ORMs are a great tool to get something off the ground quickly. Like with most tools you will hit a point where they make things more difficult and then it's probably time to switch to SQL only or mix SQL with ORM especially for performance critical queries. In most applications I have seen the ORM provided a lot of value but there were cases where it needed to be augmented with raw SQL.

I never understand why people want one or the other exclusively. Both have their place.

I think stored procedures would be very useful if they integrated better with source control and the app code. Maybe we need an ORM for stored procedures that automatically creates stored procedures from the project code?

<comment><USER16> I completely agree.

90% of the queries in my app are no more complex than selecting from a table with a simple condition. I definitely find

      users = User.where(has_foo: true).limit(10)

to be a lot more readable than

      rows = connection.exec_query("SELECT * FROM users WHERE has_foo=true LIMIT 10")
      users = rows.map { |row| User.build(row) }

(And that's an example with no user-provided input)

Likewise, any app of sufficient size seems to end up with a handful of queries that really are a pain (or impossible) to cram into an ORM. Trying to do so would result in an unreadable mess, and using raw sql improves the situation immensely.

<comment><USER17> Here's the thing, anyone who knows SQL will find the second one readable, and only Ruby programmers who have used ActiveRecord will know how the first one does.

<comment><USER18> Really? connection.exec_, .map, .build – there's a lot more non-SQL going on in the second example than the first. The first may be syntactically far from SQL, but the use of familiar vocabulary makes it pretty understandable from a SQL point-of-view.

<comment><USER6> And what are the connection and allocation semantics of the first? (Yes, the second way is more explicit.)

</comment></comment></comment></comment></comment><comment><USER19> Just once I'd like to see someone write an opinion about ORMs without resorting to sweeping generalizations ("Vietnam of computer science") or making assumptions about how they are being used ("it wasn't a good fit for my use case so therefore it must never be").

Maybe, just maybe, it's possible that ORMs are useful for solving certain types of problems and less suitable for other types. If you work on web stuff or applications that are report-oriented where most of the time you're just fetching data (possibly with complex queries) and rendering it to display, then maybe ORMs aren't a good fit.

On the other hand if you work on client-side apps where your objects are backed by a database but are otherwise long-lived, then sometimes the other features (beyond SQL generation) that ORMs provide come in handy (tracking units of work over the object graph, maintaining an identity map for consistent access to objects, and providing change notifications when an object or collection of objects is manipulated).

If you've never needed any of these features that's perfectly fine. I've never to needed to use a bulldozer either. But I'm not going around declaring bulldozers useless just because I've only ever needed to use a shovel.

<comment><USER20> Is this not the general sentiment of any piece of software? It was implemented to serve a purpose, if that purpose is not sufficing a goal of yours it is not relevant to you.

<comment><USER19> Indeed. It would be nice though, if people, having realized that a particular tool isn't useful for their particular goals, could still acknowledge that it could be useful in other situations, instead of blaming the tool itself.

</comment></comment></comment><comment><USER21> I've come to love jOOQ, the Java library that I can write type-safe pure SQL in (and with code that is immediately understandable to anyone who knows SQL). It provides mechanisms to smooth the clash of Java/SQL worlds, but otherwise never assumes it is smarter than the wisdom accumulated through decades of database usage. I've come to appreciate many aspects of databases again that tools like Hibernate try to hide from me.

[http://www.jooq.org/](http://www.jooq.org/)

I do still use Hibernate, probably because my usual framework of choice makes it so easy to, but anything above medium complexity goes through jOOQ nowadays.

<comment><USER22> I was intrigued by jOOQ, but the huge amount of generated code for internal metadata of the DB was a bit offputting. I don't want 4MB of generated classes for 3 very small tables.

<comment><USER23> Use the code generator's <inputSchema> or <excludes> flag or other means and you'll only get those 3 small tables generated...

<comment><USER22> Ah, thank you, this does the trick; I first tried to use my database name as inputSchema, but I had to use "public" in PG.

<comment><USER23> I see, yes. The database corresponds to jOOQ's Catalog, not the Schema (except in MySQL, which mixes up these concepts)

</comment></comment></comment></comment></comment><comment><USER24> The thing I love about ActiveRecord is that it makes it easy to, anywhere you want, and at any level of the abstraction stack you want, to just toss in SQL fragments. This gets you the best of both worlds, the fluidity of being able to just define methods on model objects, and the ability to utilize database tech to the fullest. You can take any query and call .to_sql on it and it shows you exactly what it's passing to the database. I prefer Sequel's semantics but ActiveRecord is an excellent workhorse that I have no problems relying on.

<comment><USER25> But how do you do:

        SELECT
          posts.*,
          (SELECT COUNT(1) FROM comments WHERE post_id = posts.id) AS comments_count
        FROM posts;

In ActiveRecord, without 1+N queries, or caching comments_count in a column somewhere?

Admittedly, that was not the best example. The last time I need something more intertwined than a simple COUNT in subquery, the answer was "give up and just use Arel." But at this point it is no longer quite ActiveRecord, but rather a SQL without strings.

This is my biggest gripe against the Active Record pattern in general, as it ties its model too tightly to the underlying database. It is convenient for a simple CRUD tasks, which may fit about 90% of use case, but that's not the only thing the database is capable of.

<comment><USER26> That's really easy.

        Post.select("posts.*, count(comments.*) as comments_count").joins(:comments)

<comment><USER27> That is not the same query at all. You need to do a left join and a group by for it to become the same query. Wihout a left join posts without comments wont show up in the result.

<comment><USER26> You're totally right. My example is an inner join. I will admit that doing outer joins in ActiveRecord is quite painful. Here's a more realistic example, which is not nearly as pretty:

      Post.select("posts.*, COUNT(comments.*) AS comments_count").joins("LEFT JOIN comments ON comments.post_id = posts.id").group(:comments)

</comment></comment></comment></comment></comment><comment><USER28> Haven't red all comments and maybe somebody already mentioned this, but here are my few cents:

I've worked with multiple ORM frameworks during my career. And I always reached the point where developer needs focus to framework internals instead of delivering new features.

Yes, usually most situation which developer didn't expected can be solved by configuring ORM framework, changing some configuration, providing additional parameters or calling some methods, but what that means? You need fully understand your framework if you want to be sure you application does exactly what you want and not misbehave.

So next time when you'll be thinking grab ORM to make things simpler, ask yourself if you really have enough time to fully learn the framework?

</comment><comment><USER29> I'm a bit surprised by these criticisms from someone using sqlalchemy. I had the same opinions of orms in the past until I learnt sqlalchemy.

 _Partial objects, attribute creep, and foreign keys_ : defer the loading of columns [1] to suit your use-case. You can even have different mappings that deal with different subsets of columns depending on your situation.

 _Data retrieval_ : sqlalchemy is so good for querying that I've mostly stopped using sql for anything other than complex exploratory analysis work. Sure, you need to know sql to be effective, but whatevs - eg Window functions? Done [2]

 _Dual schema dangers_ : I understand the concern, but again, you can choose to map this as you please and I don't see what doing raw sql gains you here. You need to change the schema, if that affects your application, you need to change your application, if it doesn't, do you need to change your orm code? I routinely migrate my db and release changes to the orm code later.

 _Identities_ : I admit there are a couple of times I need to flush in my app outside of the normal lifecycle, which I don't like. With sqlalchemy, for the most part, you just connect objects and don't worry about the ids.

 _Transactions_ : Whatever happens you'll need some sort of transaction boundary in your code. Removing the orm doesn't gain you anything there, does it?

I've written about some of this before on here so I won't rehash it [https://news.ycombinator.com/item?id=9180831](https://news.ycombinator.com/item?id=9180831)

There's a time and a place for sql, orms and storedprocs. The more you know about each of them, the more effective you can be. As ever, learn the tools and never throw the baby out with the bathwater.

[1] [http://docs.sqlalchemy.org/en/latest/orm/loading_columns.htm...](http://docs.sqlalchemy.org/en/latest/orm/loading_columns.html)

[2] [http://docs.sqlalchemy.org/en/latest/core/tutorial.html#wind...](http://docs.sqlalchemy.org/en/latest/core/tutorial.html#window- functions)

</comment><comment><USER30> I prefer to use functional frameworks. They 1) express the sql with map, flatmap, filter, groupBy etc functions 2) use classes that are equivalent to tuples.

Since I develop in Scala both are very intuïtive to write.

Apparently Linq for F# is really good as well. As someone else mentioned in a comment.

I get a programming interface that doesn't attempt to hide sql and still my code is fully typed. And it's really easy to make your query logic modular: make the sql fragment a function that you can call. Like any other code you reuse.

I can't think of an advantage of ORM over this functional approach. Apart from ORM being more well known.

</comment><comment><USER31> I, like many other people, also took a stab at my ORM / ActiveRecord lib (First for PHP on MySQL, later ported it to Javascript on WebSQL) and I've been following exactly the sentiment that a people here seem to have to: Don't make your ORM want to do everything. If you are going to need computed N+1 queries, write a View, or use custom SQL.

ORM / ActiveRecord is a great pattern imo, but if you want to make it do _everything_ , like so many other techniques, you're gonna end up with a behemoth of a thing.

I've tried many different ORMs in the last couple of years, and while mine may not be the most complete or have a sexy API for joining custom query parameters into the results, I still feel my own provides the one and only syntax / workflow 'as it should be' in Javascript:

        var serie = new Serie();
        serie.name = 'Arrow';
        serie.TVDB_ID = '257655';
        serie.Persist().then(function(result) {
          console.log("Serie persisted! ", result);
        });

I've got loads of examples with jsfiddles if you want to find out more :-)

[https://github.com/SchizoDuckie/CreateReadUpdateDelete.js](https://github.com/SchizoDuckie/CreateReadUpdateDelete.js)

 _(browser that supports WebSQL required, obviously)_

</comment><comment><USER32> Using an ORM is for advanced users, and I think it's a bad default for beginners. A good one certainly saves time when you know how to use it, but it also adds complexity and narrows the perception of what a database can do.

Narrowing the perspective is especially bad for beginners, because some options will simply never occur to them and the ORM will prevent learning by osmosis.

Let's say you need reliable, efficient cache invalidation (say, to re-render a static page when the data changes). Triggers and LISTEN/NOTIFY in postgres might save a huge amount of time (and even more in maintenance costs) over a custom solution that probably isn't right anyway.

Or maybe you need to prevent schedule conflicts. Postgres offers range types and exclusion constraints, which aren't supported in all ORMs.

Or to keep a remote system reliably in sync (even if it's a very different kind of system), logical decoding is a very powerful feature.

But how would you encounter any of these potential solutions if you are always behind an ORM?

</comment><comment><USER33> When considering using ORM we need to answer simple questions: does it help to decrease code size? In most cases ORM code is same size as SQL query. Secondly, does it hide complexity? No, it just adds up one more layer that in fact increases complexity and makes it harder to debug. Finally, does it protect us from errors or impoves code quality? This is rarely the case.

Instead of using ORM I prefer moving data retrieval code to database layer with help of views. There is also updatable views that we can use to simplify database updates on code side and sometimes avoid using transactions. Separation of code and data logic is great concern when deciding to implement ORM. Nowdays database are very smart and convinient so there is no need to use ORM.

<comment><USER34> In most cases its smaller (in the Django ORM anyway).

myobject, created = MyObject.objects.get_or_create(field1='1' , field2=field2)

That would take a number of lines. One query to check if the object exists, another to create it / retrieve it, plus application code to deal with that SQL.

<comment><USER33> Ok, for this particular example, is operation wrapped in transaction? How will code evalute if we need to check some condition on field2 and occasionally update it?

</comment></comment></comment><comment><USER35> Never seen a large enough project that relies on an ORM be anything other than a giant mess. I mean never. The conclusion is correct. From an application perspective the db is just another API and should be treated that way and the ORM should just be thought of as a convenient DSL for creating queries on top of that API.

<comment><USER36> To be fair, I've never seen a large project be anything other than a giant mess. This is the nature of large projects. If it's not a giant mess, you are probably leaving user happiness (= $$$) on the table.

<comment><USER35> And it comes at the expense of craftsmanship and programmer happiness. Lately I've been thinking how much initial architecture affects the mental well-being of all subsequent programmers that join the project. This is one of the reasons there is such a high turn-over and burnout rate in programming. If you're not consistently paying back technical debt and improving the architecture of the project then you're paying for it in other ways with the revolving door of programmers.

Then again if you're a big enough business it probably doesn't matter as long as customers are paying you. All you have to do is plug-in another cog/programmer into the machine when the previous one wears out.

<comment><USER36> All this is true, but it's also the reason why programmers are paid as much as they are. In general, in a market economy, you are paid to do things that other people don't want to do. The whole point of a market is to create an incentive to do things that are unpleasant.

Beautiful code does exist in the software world. It's usually found in hobby, open-source, and research projects without profit motives, userbases, deadlines, and all those other complications that result in shitty hacks.

In the meantime, you could look at the crap that is most large-scale codebases as a barrier to entry that keeps demand for programmers high. Enjoy the money you get for cleaning up other peoples' messes, and then use that to buy time to make the beautiful, useless stuff.

</comment></comment></comment></comment><comment><USER37> ORMs tend to assume that there is "the application" with "its database". If the application changes, so does the database. If the data is used by more than one application, it's better to have the data defined in the database and write applications as database clients.

<comment><USER38> At the big tech firm I work at, there's a best practice where any database (whether that's a traditional RDBMS or a NoSQL client) is abstracted away by a microservice with a defined API, and every other application that wants to get that data needs to interact with the microservice. That way, the database schema can change without it affecting multiple applications. There's still the traditional mismatch between ORM and database, but doesn't feel as painful because only a single application is using that data, and that application can have special knowledge of the persistence layer underneath (meaning, use database hints if necessary, defer to raw SQL, etc.)

<comment><USER39> We have decades of research into filtering, joining, and aggregating across a complex set of tables and views. With microservices you have to roll your own query planning and stream all the intermediate results on the wire even when you're throwing away most of them.

<comment><USER40> Unfortunately, SQL servers aren't generally scalable. Offloading joins and aggregation onto (inexpensive) app servers can increase over all system performance, despite lack of advanced query planning.

<comment><USER34> Bollocks. SQL scales fine unless you are stupid in the way you use it. All the crap performance I have seen in the last couple of years have been from doing crap like you suggest - doing joins and aggregation at the application level. Our front page currently makes over 1000 database calls because of this sort of nonsense.

</comment></comment></comment></comment></comment><comment><USER41> ORMs can alleviate a lot of tedium, until you get to a level of complexity where they start to create it.

I created my own ORM-like access library which seems to work pretty well.

[https://github.com/dieselpoint/norm](https://github.com/dieselpoint/norm)

Comments welcome.

</comment><comment><USER42> "quasi-professional cowboy" here. I have used both ORM and direct SQL systems with the problems outlined above. I finally gave up and wrote my own row mapper:

1\. Using the DB Schema, generate stored procedures to load and save data together with code/validation in partial C# classes.

2\. Transport data in XML format using single letter (or two) table/element and column/attribute names (auto generated). Use .Net to automatically build/ serialize the XML into objects. SQL Server/.Net have some nice XML features that make this simple.

This means that the only user access to the database is through authorized stored procedures. The users have no access to database views or tables.

I have implemented the means to load and save arbitrary hierarchical objects (e.g. an Order/Order Lines). A single request to the database can return a complex three level object which would otherwise take hundreds to round trips to load.

I agree with the observation that this would be hell to maintain. However, the people likely to maintain this system would be in just a different hell if they had to work with Hibernate or MS Entity Data Model.

</comment><comment><USER43> I written a fair number of C# LOB apps and use LINQ quite a bit with mysql. I don't even want to talk about Java and some of its ORMs as its too painful to think about. I agree with the sentiment of the post but in compiled languages I really want an ORM to simplify unpacking result sets. LINQ is great when it works but joins sort of suck as well as calling in-built sql functions and it can some times generate highly unoptimized queries. I frequently pull in data via LINQ to SQL and then massage the data with LINQ for objects where I have better control of performance and operations.

Trying to write pure SQL leads to lots of manual unpacking of the result set which I generally dislike and is much harder to maintain and doesn't work well in practice compared to when LINQ actually works.

I think maybe what I've really learned is use scripting / loosely coupled type systems when working with SQL. In python, I usually just call sql directly rather than use sqlalchemy and its fine because of the loose typing and result set unpacking isn't terrible.

<comment><USER44> On C#, Dapper's useful, but not perfect, for letting you write your own queries and then making it easy to unpack the result sets.

Unfortunately, it relies on property setters for doing the unpacking, so it doesn't interact super well with your code if you like to avoid unnecessary mutability.

The only publicly-available lightweight ORM I know of that does a good job with that is the SQL type provider in F#.Data. That one is head-and-shoulders above any other option I've found for working with databases. It does require that you write your data access layer in F#, though, which may make it a hard one to sell at work.

<comment><USER43> Thanks. That actually doesn't look that bad. It would be nice to have anonymous type objects but I recognize the difficulty in that. This looks like a nice compromise. Now if they could also fix passing in arrays as part of a parameterized query "select x from y where z in ?" where ? is a collection of strings or integers it would be perfect but I think that is a driver/interface problem.

Edit: Looks like it actually does says it does support the enumerable but I'm questioning if it will do what I want. Will have to test out but I'm guessing there is a limit to the size of the array.

<comment><USER44> Dapper accepts anonymous objects for passing query parameters. It will return an expando if you don't specify the type of object you want back, too. That can be convenient, but I don't personally like having dynamic objects running too wild in my code so I end up manually mapping it to another type before returning anyway. (AutoMapper can help here.)

The IEnumerable support will generate (parameterized, I believe) inline arrays in the query. Not really my favorite, but it works.

The thing that I couldn't get over, and which ultimately led me to write my own micro-ORM at my last job, was the weak support for table-valued parameters. But I gather they've fixed that since then, so hopefully it's not a big deal anymore.

</comment></comment></comment></comment><comment><USER45> What reading articles on how bad ORMs are has taught me: More people need to use Django.

Django does a lot and does it well.

<comment><USER34> I wouldn't say the ORM is Djangos strongest point. Its great for simple stuff, but not great for any moderately complex queries (e.g. extra conditions on a join, subqueries, conditional aggregates - though I think that last one may be solved in the most recent version).

I don't think they have done a bad job with the ORM, but you really ought to know SQL as well.

<comment><USER46> I think the ORM is Djangos strongest point. Take the ORM away and then ModelForms and Admin go with it. I think Django makes little sense if you're not using the ORM.

That said, you're absolutely right that it is really bad at certain types of queries. There's no way to really influence joins. Subqueries are coming ([https://github.com/django/django/pull/6478](https://github.com/django/django/pull/6478)), and conditional aggregates became possible in Django 1.8 with Expressions support (which I authored). Queries that map over many to many relations that have .exclude() or .annotate() generally produce incorrect results. Most of the problems with the ORM are as a result of Django handling joins for the user - which is also one of its biggest strengths.

You should absolutely know SQL if you're using an ORM. If you're doing anything other than basic CRUD, you have to know SQL. An ORM should give you an escape hatch to write that custom SQL. Django's ORM does not save you from all the problems mentioned in the article.

</comment></comment></comment><comment><USER47> > ORMs are more detriment than benefit

The author mentions Hibernate and SQLAlchemy, which are both DataMapper ORMs. But what about Active Record? It's true that AR will provide even more abstraction and distance from the database, but it also provides a lot more convenience, which for me in small CRUD projects (as most are) has been worth the downsides.

And as another posted mentioned, you can always optimize by replacing slow AR queries with custom SQL ones, and restructuring your database as your project scales.

</comment><comment><USER48> I love ORMs, they help abstract the database technology which has been really useful in a recent project switching an app from MSSQL to PostgreSQL. I also personally as developer appreciate the programmatic syntax.

I would caveat the performance issue, sometimes there is no better way, however i would always try to make things work in the ORM first before switching into native SQL to get the job done.

<comment> nommm-nommm > they help abstract the database technology

If you are going to do anything even remotely complex you're going to need to know that database technology otherwise your ORM is going to spit out queries that are dead stupid and a performance nightmare (pages taking 1 full minute to load). Then you end up fighting with the ORM to do what you want.

That's my experience.

I guess there are projects that are so simple the database layer can be abstracted away but I've never worked on one.

</comment></comment><comment><USER49> I've always said: "ORMs are for people who don't know SQL!"

<comment><USER50> ORMs are not for people who don't know SQL.

The secret to using an ORM is knowing exactly the SQL it will generate underneath. The advantage to using one is static typing as well as writing orders or magnitude less code than SQL. As well as orders of magnitude more understandable code than the equivalent SQL.

If you work on heavy enterprise applications the ORM can be your best friend or worst enemy. It comes down to knowing the tool you're using inside and out. It will make you much more productive in the long run. And sometimes yea, you need straight SQL or a stored proc to get the job done. That's OK.

</comment></comment><comment><USER51> What django gave us out of the box would have been impossible with SQL in the same timeframe with the resources we had. If we had the luxury to do things properly and fully the first time, we never would have made it to market with our robots.

This isn't to say that one day we won't throw away django or use more SQL. We just had real world schedules to deal with.

</comment><comment><USER52> Oh finally!!! I've typically had a ambivalent relationship with ORMs. The mass of config files and auto generated code is a huge pain - especially when things go wrong. Doing multiple DBs can also be an issue and requires messing around with config/annotations, what not...

Just write the SQL :) - relational algebra is not that hard...

</comment><comment><USER53> As much as I advocate for properly using SQL, I still want an ORM (lightweight) to manage the repetitious small stuff that happens repeatedly throughout an application. I'm all about custom SQL or stored procedures when the time comes though.

</comment><comment><USER54> I find ORMs great in some scenarios.

Take a really thick client, like say a graphical diagramming tool that makes your machine's fan whir loudly when you start it up. Here an ORM can be a great tool to efficiently manage a constantly evolving, large cache of your hot objects, and keep them syched with the backing RDBMS.

Big batch programs can be another good use case.

Server side web apps and API servers though are the opposite of this. Web pages and API responses should be fast and small, so we don't normally build up a big cache, and in a stateless architecture we are normally throwing the cache away at the end of each request. In this case raw SQL is often easier than work with.

</comment><comment><USER55> If you dont want to deal with quirks of ORM,use a lightweight microORM. You basically get some productivity, simple type checking,consistent way to access data , sql injection protection and you will deal with hand rolled sql queries.

</comment><comment><USER56> Sigh. Whenever I have to hurt myself at work on such issues, I find myself thinking of the web that could have been, if only...

Let me backtrack a bit. There's a much better way to do things than the way we do it right now. A way that completely obviates the need for ORMs, or indeed any way to deal with the interface between application and database.

You see, there would be no object-relational Impedance Mismatch (and therefore no need for such clunky kludges like ORMs) if the database and the application were both written in languages of the same paradigm, either both OOP or both relational. Ideally, that would be a single language, that could handle both data and application logic.

There is such a language: Prolog [1]. Prolog is implemented as a relational database. So your program itself _is_ the database. There is no separation between data and operation and therefore no ORIM and no need for ORMs, or stored procedures or anything, really.

And, yes, it's perfectly possible to do your web dev in Prolog. Here, see this explainer on the Swi-Prolog website, titled "Can I replace a LAMP stack with SWI-Prolog?":

[http://www.swi-prolog.org/FAQ/PrologLAMP.txt](http://www.swi- prolog.org/FAQ/PrologLAMP.txt)

Hint: Yes. Yes, you can. You can replace LAMP (or LAM-whatever) with an LP stack, where all you need on top of your OS is Prolog itself. Its built-in Definite Clause Grammars notation [2] can be used to parse and generate javascript, html, xml, css, YAML, whatever you like. Swi-Prolog even offers translation to RDF, which is as natural as you can expect given RDF is also a relational language.

Here's a big fat tutorial to help you started:

www.pathwayslms.com/swipltuts/html/index.html

Can this be done _for real_? OMG yes it can. The Swi-Prolog website itself runs on an LP stack. There's a few more websites that do too:

www.pathwayslms.com/swipltuts/html/index.html

In short: you don't need to hurt yourself as badly as you 're currently doing it. There's no other need than of course, nobody wants to learn Prolog. I know that, I've made my peace with that and I've spent all of my so-far career hurting myself against the ORIM just like everyone else.

... but we could have had a better web.

___________________

[1] [https://en.wikipedia.org/wiki/Prolog](https://en.wikipedia.org/wiki/Prolog)

[2] [https://en.wikipedia.org/wiki/Definite_clause_grammar](https://en.wikipedia.org/wiki/Definite_clause_grammar)

<comment><USER46> This sounds really interesting, but I'm having a lot of trouble trying to follow how all that code fits together - from what code I could find. I also strongly dislike the object/function based approach to constructing HTML (which - funnily enough, is just like using an ORM to construct SQL which I like heh).

Really, I don't see enough offered to counteract what little pain I feel using an ORM. The LP actually looks more painful (to me). Obviously I'm totally unfamiliar with this stack which makes it hard for me to see where the benefits lie.

<comment><USER56> >> Really, I don't see enough offered to counteract what little pain I feel using an ORM.

In that case you'd probably find no benefit in giving up the use of one, regardless of what replaced it.

</comment></comment></comment><comment><USER57> Hibernate is a very complex library. SQL+JDBC on the other hand is easy (JDBC is tedious, some complex SQL might be hard, but generally it's easy). On the other hand Hibernate could significantly reduce development time, if developers know it and application is a goot fit (CRUD, filters).

My advice is to avoid ORMs unless your project is big and its database schema is a good fit. And if it is, don't think, that ORM is easy, it's not. Learn how it works, read its source code, understand its inner workings. Or find someone who does.

I didn't have much experience with other ORMs, though.

</comment><comment><USER5> I expect I am approaching things improperly, but the only time I end up fighting ORM's is when I am trying to creation complex aggregation queries, or other responses used on "reporting" pages.

</comment><comment><USER58> Previous discussion: [https://news.ycombinator.com/item?id=8133835](https://news.ycombinator.com/item?id=8133835)

</comment><comment><USER59> Domain objects in the middle tier only make sense if there is pervasive reuse of component objects. I extensively chased the unicorn of component orientation but it never pans out.

The _logical_ place for domain objects is in the Database. Yes, stored procedures, with object layer mappings of _views_. But the reality of the practice is that (a) the toolchain for the DB backend is quite firmly stuck in 80s and (b) most IT programmers lack SQL skills.

</comment><comment><USER60> The trick to using ORM is being smarter than it, so that you can ultimately rewrite everything it once did for you incredibly inefficiently.

</comment><comment><USER61> Use the best tool for the job.

ORM's might do it 80% of the time. The other 20%, most of the mature ORMs provide a way to execute your own sql.

</comment><comment><USER62> I'm curious how the author would like MyBatis, which is just a thin wrapper for calling SQL, and then translating results to POJOs.

I like it, and it, IMO, keeps the API distinct from the access in the DB. You have to write your own SQL, which is good and bad. Huge amounts of control and performance, but higher portability costs.

<comment><USER63> Also Records for Python: [https://github.com/kennethreitz/records](https://github.com/kennethreitz/records)

</comment></comment><comment><USER64> One important benefit of using an ORM is not being locked in with a particular DB server tech. Good luck migrating large app not using ORM, from, say, MySQL to Postgres if, for example, Postgres replication is something you are all of sudden interested in.

<comment><USER34> Has anyone ever actually migrated a database on a non trivial application? I want to go from MySQl to Postgres, but I am not sure if its worth the risk / effort. We got told about the standard nature of SQL in University, and how you could swap engines 'easily'. Then we started using them in real life and the reality of that situation hit.

</comment></comment><comment><USER65> For me the time I loved SQLAlchemy the most was the time when I migrated my database from MySQL to Postgres. Almost all of the issues people were warning me about did not matter as SQLAlchemy caught them automatically.

</comment><comment><USER66> I came to the same conclusion, and wrote this ORM for SQL lovers:

[https://github.com/iaindooley/PluSQL](https://github.com/iaindooley/PluSQL)

</comment><comment><USER67> There are two types of ORMs 1\. ORMs for SQL dummies 2\. ORMs for SQL gurus You really need to be clear, when discussing ORMs, which type you are discussing.

</comment><comment><USER23> Use ORMs for complex CRUD. Use SQL for complex queries.

</comment><comment><USER68> Enterprise Objects Framework just worked.

Pretty much every other ORM I've worked with has been terrible by comparison.

</comment><comment><USER69> (= 'ORM 'OMG) #Clojure

</comment><comment><USER70> SQL is a write-only language. You better hope you don't have to rewrite your complicated raw SQL queries in the future.

<comment><USER71> You can write well written modular SQL that supports changes and can be read by a competent developer.

<comment><USER70> Not in my experience. Please show me actual examples of "well-written modular SQL" in a real application.

<comment><USER72> Would modular sql be wrapping up subqueries inside of views, and then selecting from those views?

<comment><USER46> Common Table Expressions (CTEs) help with modular SQL.</comment></comment></comment></comment></comment>


Trading for their own account - <AUTHOR> http://radar.oreilly.com/2007/12/trading-for-their-own-account.html

<comment><AUTHOR> After this article follow this thread ~ <http://news.ycombinator.com/item?id=279627></comment>


The little-known secret of how to actually choose a web designer - <AUTHOR> http://informationhighwayman.com/rants/choose-web-designer-easy-steps/ <comment><USER2> This is ridiculous. In my experience, graphic designers are not primarily, nor should be, concerned with revenue, ROI, sales, etc. Much less copywriting.

Instead, the client is. Once the client has established his or her goals, and worked with marketing/sales/engineering/architects to determine what pages will be built with what functionality, _then_ you hire a graphic designer to produce a "look" that achieves those objectives in the visual realm.

And depending on what kind of objectives you have, you may want a "clean" style or not -- maybe a "grunge" style instead, depending on your market. You may want "modern", or you may want "retro".

And when the author says "...are not actually designers at all. They are artists." Yes, that's the point. And artists are extremely important in seamlessly merging your brand together with your website's functionality.

But if the author is talking about "web designers" in general, then there's barely anything to talk about at all, because it's become such a vague term that nowadays it's practically useless. There are graphic designers, interface designers, information architects, and so on...

<comment><USER3> Could be useful advice though for any designer who wants to enter the realm of the bullshit artist, and make a small killing doing so ...

</comment></comment><comment><USER4> This isn't an article about how to choose a web designer, it's a list of designer stereotypes that business people believe in.

To "actually choose a web designer" you need to have a clear idea of what your objectives are for the project and then interview with an open mind. Find somebody intelligent with a strong portfolio. No silly checklist is going to outperform you as a thoughtful decision maker. Litmus tests are used because they are easy, not accurate.

<comment><USER5> From his facebook: <https://whichtestwon.com/archives/5274>

_rolling eyes_

</comment></comment><comment><USER6> This is a very odd perspective. Why is it a web design portfolio's job to convince you to care about good copywriting?

If your primary objective in hiring a website designer is something like SEO, improving conversions, or otherwise directly generating more revenue, obviously language like "ROI" and "Generate more business" can be a sign that a firm is focused on those aspects of design for the web. If I was looking for a firm that specialized in that area, I would prefer case studies that demonstrate concrete improvements to just an argument or mentioning certain buzzwords.

But lots of web design firms help their clients meet objectives besides immediately increasing business. For some companies, branding doesn't matter at all. But, for some companies, like say a fashion label, branding is extremely important. If they hired a designer who was focused on "ROI" and so forth, they would likely not only get a terrible product that doesn't match their needs, but see very little in the way of new business.

The "secret" of hiring a web designer is just being clear about what you want your new design to do, what your goals are for the design. Whatever those goals are, you should select a few designers whose work looks like it speaks to your goals, and tell them directly about what would constitute a successful design. Ask for examples of times they've successfully reached similar goals for a client in the past.

</comment><comment><USER7> The funny thing about this article is that its very existence points out the fact that many web designers are very much aware of the concepts of "business objectives", "return on investment (ROI)", "lead generation", "increase sales". Designers' websites are clearly crafted with the sole purpose of procuring clients, and they presumably work given that many such designers are still in business!

I think that in many cases (and I'm not a behavioural psychologist or anything), consumers make irrational decisions when shopping... usually based on an emotional response. Personally, I would much rather hire a designer who has experience making "beautiful", "modern", "clean", and "usable" websites than one who claims they will somehow magically pump out a website that immediately provides a high ROI.

Web design is an iterative process that starts from a nice, clean base and improves through A/B testing and similar experiments.

</comment><comment><USER8> My mantra is always WWOD - What Would Ogilvy Do?

My website exists to sell product. My job is to improve traffic and conversion. Anyone who isn't going to directly contribute to that effort is at best deadweight, at worst pulling in the wrong direction.

I'll give a potential hire the benefit of the doubt based on their website, but if we exchange more than two e-mails and he isn't talking about traffic and conversion, he isn't getting hired.

I'd require very little persuading to hire OP, based purely on him referencing Drayton Bird. The converse is also true - I wouldn't consider ever hiring someone who can't quote chapter and verse on Commonsense Direct Marketing.

<comment> mkr-hn "The converse is also true - I wouldn't consider ever hiring someone who can't quote chapter and verse on Commonsense Direct Marketing."

Do you believe someone can't be a competent marketer without having read that specific book?

<comment><USER8> Yes. If you're in the business of selling and haven't read it, you're either lazy, stubborn or a fool. It remains the definitive text on direct marketing. I know of no-one in the direct mail industry who hasn't read Bird's Commonsense and I know no-one who considers it anything short of a masterpiece. Ogilvy said "Drayton Bird knows more about direct marketing than anyone else in the world.". Commonsense is the essential distillation of everything Bird knows about DM. If you haven't read it, either you have no interest in understanding the business of DM or you're terrible at choosing books. Either way, I don't want you anywhere near my business.

<comment> mkr-hn That's very narrow-minded. I would just recommend the book and tell them to come back after reading it. Someone who's genuinely incompetent wouldn't get much out of it alone. Someone who is competent will be even better than they already were.

That's if the book really is any good. I'm going to go check it out after your roundabout recommendation.

</comment></comment></comment></comment><comment><USER9> "Branding" isn't a puff word if you're serious about marketing -- and not only is a "return on an investment" but an actual part of your product. Without a brand your can of sugar water isn't Coca Cola. And in terms of tech if you look at the work of Paul Rand he put IBM on the map. And branding isn't just for the big guys, if you're a small startup picking the right name for your web domain (and investing in it) can be make or break when taking those first steps.

</comment><comment><USER10> While the author suggests some points about creating value that at face are silly to disagree with, I would warn away readers and suggest that as a whole, this post contains some very bad advice. It's a "the enemy of your enemy is not necessarily your friend" scenario; he's not wrong, but he's also totally full of shit.

Look at a site like Vimeo and tell me that beauty and passion aren't critical aspects of this design. Then head on over to AirBnB or Kickstarter or Etsy and tell me that they didn't put a huge amount of design thinking into making a clean, modern site that makes the visitor feel like they are making a difference by participating in a consumer revolution.

Good design extends far beyond logos and colour swatches. To have good design means that you've thought through every interaction path so that you can manipulate how your visitor _feels_ when they use your site or product. You need to connect with their limbic brains first, and only then are you in the best position to really understand how to maximize their ROI.

TL:DR; this is bad advice. Don't hire a designer that only cares about "business objectives", "return on investment (ROI)", "your revenue goals", "lead generation", "increase sales" because chances are they are also busy with real estate and network marketing. The author knows who not to hire, not who to hire.

</comment><comment><USER11> Is it just me or did the design on that page make the article startlingly painful to read?

<comment><USER12> For an article about 'how to choose a web designer', I'd say that's a pretty important thing to get right. Business wise or otherwise. And you are right. It was a massive fail in that department.

</comment></comment><comment><USER13> Following this advice will probably cause you to rule out a lot of good designers.

<comment><USER14> As a designer myself, I agree.

</comment></comment><comment><USER15> I'll add that during your first conversation the designer should dive right into understanding your business, and understanding your objectives, before any discussion of solutions.

If the conversation flows in the opposite direction, you have a problem.

</comment><comment><USER16> I would much rather choose a designer with a history of work I like the style of than someone that can spout buzzwords like ROI.

It's not like you hand everything over to a designer and say "achieve my business goals", it's a collaborative process where you make sure your business goals are met.

<comment><USER17> The problem here is I think that the style 'you like' may not be what you actually need. If it was that easy, there would be no need to articles telling you how to find a good designers. I agree that buzzword are not the best metric ever, it's easy to fake, but as an engineer I wouldn't trust my own taste either. By the way, I didn't like the design of site in the OP, but I guess the author is a good designer.

<comment><USER16> I'm an engineer too, but I still trust my taste. I can't actually make what I like, but I know when I see it.

I am probably using the term "like" a little broadly, as I don't just mean visually appealing, but more so a design that meets my requirements and fits my purpose. Ultimately, I need to judge that, not the designer.

</comment></comment></comment><comment><USER18> "You can be sure anyone who advertises his services in this way understands nothing of importance about marketing or business."

I think this statement is almost backwards. The reason "designers" use buzzwords is because it gets small business owners on board with them. Advertising your design services in a cookie cutter, predictable way is OK if you have the portfolio, skills, and actual marketing knowledge to provide business value. I don't care how great your copy or copywriter is, the text and UI has to be seamlessly integrated into the experience so there is NO distraction and the message can be properly conveyed. This takes an artist...

Bottom line- this guys is missing it

</comment><comment><USER19> I genuinely thought this article was a joke -- I thought he was going to say something about you should add up the ticks in the 'good' and 'bad' columns and if the total number was greater than zero you should find a different designer :)

I think this guy is just wrong. A designer's job is to design. It's not his/her job to use buzzwords like "business objective" or "ROI" - it's his job to create a functional, relevant and aesthetically-pleasing website. And, frankly, I think words like 'clean' and 'modern' are GOOD.

As a web consumer, I know I think higher of companies with clean, functional, modern websites. It means they have a clue.

</comment><comment><USER20> When choosing to work with anyone you should look for skills which complement your own / your current teams. Generally when looking to recruit a designer, it would be their design skills your after; not their legal advice or ability to write in marketing jargon. Look for people whose designs you like, preferably who have produced something similar to the look you're after before. Find someone you can build a relationship with, where they can talk you through their subject in your language. If you're a small business with no technical skills, your "web designer" should be someone who describes the whole process of getting a site on-line up front, and who offers ways for you to maintain that site yourself, without having to pay them each time you want a few lines of text added. If you're a larger business, or a developer who lacks graphics skills, you'll probably be focussed on just the design side, and will want someone who uses technologies compatible with what's in your toolkit, people who have experience working alongside programmers, and perhaps those who understand how to optimise their designs for performance. Everyone's requirements are different, so the designer they're after will also be different. Look at what these designers have done before, and look at their customers' feedback, and pay particular attention to those customers who seem to be the most similar to yourself.

</comment><comment><USER21> Well, duh. Design is not art. Art is about beauty primarily. Design is about leading user where he wants to, be it content, product, or a graphic. Design is communication.

What this means to business-people/developers: you can have all the functionality and low prices in the world, but if no one can get what they want in time, it's all useless. There are no sales if the user can't get to the "Sell" button. There are no ad views if the content is hidden somewhere in .html files or is unreadable.

<comment><USER22> > Art is about beauty primarily.

Actually art is not really about beauty. Serious art is a lot like business, but with one important difference: art is about attracting a very select, discerning audience (while ignoring or even actively _repelling_ the non- discerning audience). The way art works is that this very select, discerning audience will be willing to pay money to establish that very fact. In other words, art is about extracting money in exchange for exclusivity. Most businesses, of course, work in an entirely different mode: they extract money in exchange for service.

<comment><USER23> Speaking as a musician, I can assure you that that is not what art is about. That is what art dealership is about. Artists and art dealers are not the same people.

On the other hand, it is also not necessarily about beauty. I've played plenty of ugly music that is still great.

<comment><USER22> > Speaking as a musician, I can assure you that that is not what art is about.

Speaking as an artist, I can assure you that is exactly what art is about. Additionally: all people are the same, and have always been.

Even when you do not actively try to play for an audience which has exclusivist tendencies, your art (music) will invariably end up used in a very specific way. There are invisible relations of power behind most of the things that people do, art and music being no exception. In school, we were taught that it is not nice to be exclusivist, however that is not how the world works. Similarly, in school we were taught that desiring power is a bad thing, while it isn't in fact (as long as this desire is productive).

Take a simple example: a guy meets a girl (or the other way around) and asks her what music she listens to. Music taste is a way in which connections are established between individuals (connections between people have a lot to do with power so stay with me...). Now this connection will mean relatively little if the music that both the girl and the guy like can be commonly heard on the radio. The connection will mean _a lot_ if the music they both like is relatively obscure. And it's not just music. Anything, really, that is rare _and_ is shared between two individuals becomes _special_ \-- i.e. becomes a nearly fetishistic object signifying the commonality between the two individuals. It's very beautiful actually. And it's all based on exclusivity. Side-note: the "commonality" I am talking about probably has a lot to do with Shannon's entropy and information transferred between the two individuals.

<comment><USER23> > Speaking as an artist, I can assure you that is exactly what art is about. > Additionally: all people are the same, and have always been.

Fair enough. I suppose I can only speak for myself, and to a certain extent I can speak for other artists I know and have talked to about these sorts of things. So yes, please assume that everything here is a gross generalization. Also, please accept my apologies is this whole digression is off-topic. It is something of particular interest to me. If I should shut up, just let me know.

What you're talking about is a popular line of research for musicologists. The way art is used to reinforce social bonds is an important part of why people make art. That doesn't mean that, for artists, that is what art is "about." Any object once it's released into the ether will be used or misused as the people who encounter it see fit. I am responding to the notion that artists are craven elitists whose primary goal is to have their art acquired by rich people in order for them to show how much better they are than the plebes. Rich people do and have done that, but in my experience, if that layer enters into the creation of the art itself, it is generally the artist thinking, "how can I trick some dumb tasteless (bourgeois) rich person into giving me money so I can keep making art." Artists make art because they have to. If it were about getting a paycheck they would have gone into investment banking.

There are some people running around painting or playing a musical instrument who are not like this, who do it because they majored in it in school and some inertia keeps them doing it even though they have no inner drive and no commitment to producing authentic work. I've met them, and I've seen them play. Frequently they are stunning technicians, but I tend to take the 19th century Aestheticist view and say that what they produce is not usually art. Given a double-blind test, could I distinguish between those who have standards and those who don't? I don't know. Again, I like the old-fashioned view that what matters is the-thing-itself.

I am by no means suggesting that artists do not or should not take their audience into account. Art is not effective if it conveys nothing to anyone but the artist. Also, clearly, artists produce different work depending on whom it is for. Mozart, for instance, had a different style for his "public" works, such as symphonies and concertos, than in his music that is intended for connoisseurs, such as string quartets. I don't think this is the same as what you're talking about, though. Taking into account comprehension levels of your audience is part of the craft, and does not preclude producing an authentic product. It does not mean that aesthetic goals are secondary to financial ones.

</comment></comment></comment></comment></comment><comment><USER24> This article makes some interesting points, however I believe the author fails to differentiate the devices of which a web designer aims to market to potential clients versus what they are entirely capable of.

As a professional entrepreneur running my own company my career began with freelancing and instructing in web/print design. I won't claim to speak on my years of experience at that time of specific "business" knowledge as the author mentions (ROI, revenue goals, etc), nonetheless I never felt it appropriate to market my business skills on my design resumes and portfolios. While I agree wholeheartedly with the importance of understanding business models and revenue goals, I also feel it's not in the web designer's best interest to include these skills on a design portfolio.

All in all - it should be apparent that just because a web designer includes "buzzwords" such as "clean" and "modern" it certainly doesn't mean they don't grasp concepts such as ROI or revenue goals.

</comment><comment><USER25> Tennant's point about the use of these words, "branding", "beautiful", "passion", "making a difference", "modern", "clean", is totally valid. These are qualities that web designers either want to achieve on a professional level or have seen mentioned most design blogs and rockstar designer portfolios.

These are qualities that any web designer worth their salt will have demonstrated in their portfolio. They will show, not tell, how good they are.

As for the rest of the article, I think it demonstrates the author's skill more as an online marketer rather than a graphic designer. He did get to the front page of HN after all.

</comment><comment><USER14> Interesting, as a web designer I did not understand I was supposed to be a web marketer as well. So, if I study up on the books mentioned in the comments does that mean I can now command two paychecks? If I spread out into copy writing as well does that now mean three paychecks?

I don't know about his world but in mine the marketer worries over conversions and ROI and WORKS WITH the web designer to achieve those goals. Somewhere in there a copywriter is involved. In my office we refer to this as a "web team". Is this a new concept? Can I patent it?

</comment><comment><USER26> I don't think it's possible to come up with universally valid selection criteria.

Some projects are purely design-driven, the site just needs to look great (say, for a fuzzy image campaign), and that's simply the job that the client needs to get done.

Other projects (and I like to believe the majority of launches) are clearly business driven and the site needs to accomplish specific goals to meet strategic objectives. In that case, OPs approach makes a lot of sense.

</comment><comment><USER27> Unless you are acquiring generic services or commodities, hiring anyone starts with a conversation, not with looking at the website. The only useful information you can get from a designers (or any kind of bespoke service) website is a) is their style what you are looking for (if you even have a preference), b) do they have relevant experience, and c) how can I get in touch.

Everything else is human interaction, not browsing through a catalog.

</comment><comment><USER28> The skills he's talking about you'll want to have in-house as you optimize for conversion - probably working closely with whoever's doing traffic acquisition.

When just starting out, should you be seeking funding, I'd recommend sticking with someone focused on aesthetics - the guy he tells you not to hire. Pretty goes a long way with angel investors and venture capitalists.

</comment><comment><USER29> One look at how the author describes himself on twitter (<http://twitter.com/#!/bnonn>) clears this right up: "Direct response sharp- shooter D Bnonn Tennant—the dashing & debonair web copywriting ace & attention-thief for hire"

</comment><comment><USER30> I wonder how the awesome sword and spade symbol on this website help him sell whatever he's selling.

</comment><comment><USER31> Selective quotes:

information highway _man_

Award 12 million points if _he_ argues the case

Firstly, that _he_ knows so little about design that _he_ thinks recognizing the importance of branding makes _him_ sound knowledgeable.

 _he_ knows so little about marketing that _he_ believes brand

 _He_ does not understand how to present a unique value proposition—that most basic element of selling. And _he_ certainly does not understand what matters to your business. _He_ is just an amateur

\----

Well I'm no information highway man, but first semester of first year university we did a subject that taught us using gender-specific language when it isn't required never gains you a sale, but may well lose you some.

The author sure lost me with his apparent assumption that only men run web design businesses.

<comment><USER31> I get downvotes for _that_?!

One might note that I took the least extreme position possible: that gender neutral language is harmless; but gender specific language may offend so it makes sens to use the neutral form.

One may also note that there are much more extreme positions available: that the author's language choices displays an underlying current of sexism that is found though out the IT, business and web communities. I didn't say that because I don't think it is true - but perhaps I should have because I'd have started a discussion instead of just getting a downvote.

One might also note that someone could disagree with me and _reply_ , instead of a lazy downvote.

</comment></comment><comment><USER32> Kudos for the point about working with a copywriter. I see tons of new "Show HN"-style websites and apps come across this website, and without fail 80% of them are in much greater need of a better writer than some fancy, unique design.

<comment><USER33> any books or other resources you can recommend to read up on copywriting?

<comment><USER32> Start with Strunk and White, Elements of Style. Once you get that move on to literary devices. Try Mary Oliver, A Poetry Handbook, or Robert McKee, Story.

There are all kinds of business-y books out there about copywriting for email marketing etc, but you will never learn the fundamentals from them.

</comment></comment></comment><comment><USER34> Those things he listed are MY job. I just need a designer to make things pretty.

</comment><comment><USER35> While I disagree with why these are on your negative list - "branding", "beautiful", "passion", "making a difference", "modern", "clean". "Making a difference" can read pretty darn close to "Return on investment", etc.

I actually stopped reading when you used the phrase "babbling like a retard". As a Christian like you profess to be, I would probably look a little more closely at the words you choose.

<comment><USER36> I wholeheartedly agree with this comment. Using "babbling like a retard" is akin to employing the n-word in terms of being considerate to a world-wide audience.

<comment><USER37> When did the word retard start carrying the same weight as nigger? Is it an American thing?

<comment><USER38> If you're not American, you'll probably understand when I say it carries the same weight as "spaz".

<comment><USER37> Spaz is a nothing word in Australia. I found this article which begins to explain the change: [http://www.npr.org/templates/story/story.php?storyId=1124793...](http://www.npr.org/templates/story/story.php?storyId=112479383)

</comment></comment></comment></comment></comment><comment><USER39> Complete nonsense. Shopkeeper mentality.

</comment><comment><USER40> At what stage should a copywriter by brought it? Before or after the designer has done their work?

</comment><comment><USER12> it's links like this that make me wish there was a down vote on hn

</comment><comment><USER41> > babbling like a retard

A lot can be said of that.

</comment><comment><USER42> Here's a cool article on how to actually choose a web host. <http://www.ehow.com/how_4449124_choose-website-host.html>

Great website copy, great website designers... they mean jack if your website doesn't handle the traffic it receives. <http://cl.ly/3t2D1E2c3H3A2d1I433W></comment>


Responding to a Potential Job Offer in an Interview - <AUTHOR> https://medium.com/@wyounas/responding-to-a-potential-job-offer-in-an-interview-70ba258ec4e5 <comment><USER2> I would have to agree. A hypothetical question like that, not an _offer_ note, deserves one of two answers, either "I would consider it and get back to you within <short time>", or "let's find out".</comment>


Ask HN: What's wrong with the new MacBooks? - <AUTHOR> <comment><USER2> They lack ports, everything needs an adapter, internals are locked tight, the weird touch bar is a waste of money and battery life, hate the trackpad, the keyboard is horseshit and suffers from thermal throttling. (Also I hate the fact that they don't have the light up logo on the back anymore)

Other than that though, the screen is pretty good, the OS "just werks" and sound isn't too bad either. Battery holds up pretty well, the build quality holds up pretty well too.

</comment><comment><USER3> I am probably the most bullish person I know about them. I love the convenience of USB-C, they run cooler than any other model I've owned, great screen and trackpad, etc.. but.. it's _the keyboard_. I find it fine to type on but I have to lever up keys and blast with air very frequently. It feels so fragile.

</comment><comment><USER4> My one complaint:

The keyboard is just too delicate. I've owned a 2016 MBP without touchbar since January of 2017 and I've had 5 keys get faulty on me. Previously I've owned one MBA and one rMBP (2012 design) and never had issues with the keyboards on those.

</comment><comment><USER5> Touch bar (or rather, lack of physical function keys). Dongles. No 32GB option.

</comment><comment><USER6> glitchy, especially when power is low

touch bar is useless and gets in the way

individual keys can go out

touch bar Contrast and Volume require more keypresses than dedicated key versions

escape key is in different position than dedicated key version</comment>