Hacker News Reader

> All these kids want to do a bunch of busy work and for no good reason. It makes the feel productive.

This is pretty patronizing. Not everybody who uses these tools are "kids who just want to do busy work". In fact, I'd argue that "kids" (or more accurately, "new developers") are the least likely to want to do busy work, as they'd prefer to be able to build stuff fast. (And for the record, I feel like I suddenly started doing a whole lot LESS busy work once I got decent with React.)

I generally agree that "less is better", until you have to start re-inventing solved problems.

> I learned this lesson with Cucumber/RSpec/Caybara and etc.. I started asking why I had to use these over plain old TDD and so I used TDD for a month and I found out everything was totally fine.

RSpec is just a testing framework though? It's not something you chose instead of TDD...

>I generally agree that "less is better", until you have to start re-inventing solved problems.

I think the takeaway is that before you assume you have an "unsolved problem" due to all the buzz/hype around $HOT_LIB, study a little more, try it with the upstream, make sure it's really necessary before you get a tortured contrivance of a stack in place. Consider the cost of adding more dependencies and whether the functionality you're getting from the third party lib is really worth it.

Let's be honest, the core problems you're likely to run into on any given day are probably "solved" pretty reasonably by any language that's at the appropriate level for the problem space and has seen significant use over the last 10 years. You're more likely to be reinventing the wheel by pulling in $COOL_GITHUB_PROJECT than you are by taking a few more lines to implement with the stdlib.

> "kids" (or more accurately, "new developers") are the least likely to want to do busy work, as they'd prefer to be able to build stuff fast

You're grossly underestimating the proportion of new entrant workers in the ICT industry that don't have an aptitude for programming, and cover their tracks by appearing to be productive.

This is /r/iamverysmart/ material.

I'm going to go out on a limb here and guess that you don't work in a large team with other developers, maintaining a common codebase.

This.

I am pretty sure this is the case. I have worked with small and large teams. Large teams usually have a lot more abstraction in terms of their architecture. So there is most likely a "backend" app that is just an API and you consume it in your "frontend" (node, rails, etc) whatever that may be.

Frontend in this context is just another server that is communicating with backend APIs using RPC. When small teams think of frontend, they usually think about a framework like React, etc and pair it with a backend like Rails.

CoffeeScript is ES6+ with a bit more expression-ness, less punctuation, and fewer new features like async/await. CoffeeScript's grammar and compiler have always been a bug-ridden mess (a fix was my first open source contribution), while for ES6+ you have three different well-supported sanely-engineered cross-compilers, as well as native support in browsers, and support from every development tool made in the last few years.

I loved CoffeeScript in 2012, but even then it was clearly a stop-gap, and we're on the other side. You're putting yourself at a strict engineering and hiring disadvantage, in return for... having less punctuation so you feel better about writing markup in your JavaScript..?

> I don't even really use Arel in ActiveRecord. I just write raw SQL that serves JSON directly back. I made it easier for me to organize SQL in partials just like views and to injects variables and conditions into my SQL.

This seems misguided. Arel is already very much like a library for partials for SQL that allows composition and takes care of tedious but important concerns like injection safety.

> All these kids want to do a bunch of busy work and for no good reason.

That's what your SQL-partials system sounds like to me! Different strokes for different folks.

I think that Tom Dale made a pretty good argument of why to avoid CoffeeScript as part of his argument for TypeScript.

"For example, CoffeeScript adopted for..of loops to iterate over the properties of an object. Meanwhile, ES6 introduced its own for..of loops as a way to loop through iterable objects. If CoffeeScript wants to support new functionality with similar syntax like this, it has two choices: break existing CoffeeScript code, or diverge from JavaScript more and more over time."

https://medium.com/@tomdale/glimmer-js-whats-the-deal-with-t...

I don't think JSX is ugly. React/JSX are incredibly simple and follow the less is more philosophy.

I couldn't tell if this post was sarcastic or not at first. Seems weird to say Less is Better, and then say you like CoffeeScript which adds a whole layer of abstraction over JS.

I think it really depends on what type of code you write. In many many cases, the code you write in CS is exactly the same you would write in JS. The difference is that you can omit some elements that visually clutter the code like brackets

Thanks for the pointer to Mithril. Hadn't heard of it.

> The only issue I foresee is tools being built around the use of ES6 that compel you to abandon it.

A friendly CS fanboy here. With CS2 many tools become trivial to integrate and work with

"I just write raw SQL that serves JSON directly back."

I'm surprised and intrigued by this. How do you get your query to return JSON? What percentage of your code actually works like that? How business logic heavy is your SQL? This is super interesting!

I've also managed to obtain extremely good performance from this approach. It's good in areas where for one reason or another you need to dump several MB of JSON, which languanges like ruby simply can't do performantly but postgres definitely can. Here's an extremely quick and dirty example:

    def serialize_in_postgres(relation, columns)
      ActiveRecord::Base.connection.select_rows(
        <<-SQL
          select array_to_json(array_agg(row_to_json(result))) from
          ( #{relation.select(columns).to_sql} ) result
         SQL
      )
    end

    puts serialize_in_postgres(SomeArModel.limit(2), ['id', '"created_at"::date'])
    # => [{"id":12345,"created_at":"2017-06-11"},{"id":23456,"created_at":"2017-06-11"}]

Unlike the parent, I would not recommend doing this everywhere, or even most places, but it is a very useful tool to have.

Postgres and probably others support JSON these days.