Hacker News Reader

Comment by rob74 | Hacker News Reader

The "advice" slide is great and probably uncontroversial, but if you add another factor into the mix, it becomes very hard to follow: most modern (web) development uses frameworks: Laravel for PHP, Next/Nuxt/whatever for JS, and so on. Using these frameworks makes development faster (of course only if you intimately know and restrict yourself to the "one true way of doing things" set out by the framework), but by using a framework, you also subscribe to the amount of bloat that the framework authors deem acceptable. And, from what I have seen, that's a lot of bloat.

View on HN

I don't use frameworks. I've had to extract customers from their over-commitment to frameworks when they inevitably hit a limitation, had to change the framework core, then got stuck at that version forever.

Ironically PHP works fine as a web framework -- I have never understood the point of adding another layer over it. I guess programmers who don't understand SQL injection or XSS -- basic web dev security stuff -- create some demand for the training wheels. With Rails I understood the need, because Ruby doesn't come out of the box with the web app orientation of PHP, but then why choose Ruby in the first place?

Now I see frameworks promoted for Go, which by design includes everything needed for a full web app. Habits die hard, and some of those habits I can only attribute to either lack of skills or laziness. We now have a world where a significant percentage of so-called web developers can't write HTML, CSS, or Javascript.

> Ruby doesn't come out of the box with the web app orientation of PHP, but then why choose Ruby in the first place?

It was and is absolutely possible OOTB to do PHP-style webdev with Ruby quite trivially with the Ruby-included CGI and ERB (a.k.a eRuby; which has an `erb` command).

The set up is hardly any different from any other CGI setup be it with Perl or PHP.

Here's a `foo.rhtml`†:

    % cgi = CGI.new
    <%= cgi.http_header("status" => "OK", "type" => "text/html") %>

    <html><body>
    
    <ul>
    <% [1, 2, 3].each do |a| %>
      <li>
      Hello <%= a %>
      </li>
    <% end %>
    </ul>
    
    <%= cgi.params.inspect %>
    <%= cgi.path_info %>
    <%= cgi.script_name %>
    <%= cgi.request_method %>
    </body><html>

You'd configure the HTTP server with calling `erb -r cgi <script>` for `*.rhtml` and... that's it.

So we mimic a CGI server call:

    env REQUEST_METHOD=GET PATH_INFO=/foo SCRIPT_NAME=foo.rb QUERY_STRING='foo=1&bar=2' HTTP_HOST=foo.com erb -r cgi foo.rhtml

There was even an Apache `mod_ruby` for a time.

It just didn't make sense very quickly as soon as Rack came to be a thing††, and then you're one step away from Sinatra†††.

Even then you can easily still use pure Rack (or even Sinatra) and ERB in extremely PHP-esque ways.

† `.rhtml` is the conventional extension for ERB files that generate HTML, while `.erb` is the generic one.

†† Bonus is that you don't even have to setup a whole Apache/NGiNX server on your machine; you just spin up the Ruby-included WEBrick so it's even more beginner friendly.

††† Which contrary to Rails is hardly prescribing about anything.

Unfortunately developers cannot be blamed. Most customers give unrealistic deadlines that you can only meet if you use a framework. Convincing them to wait a little bit more time to do it right does not work, they will just hire somebody else. I am working for a customer who opted out from a properly working, fast website with a Go backend in favor of Wordpress, because Wordpress happens to have a WYSIWYG editor. So we comply and install an enormous pile of insecure bloat that loads for eternity... just so the customer can change colors and move blocks around the landing page. It sucks, but having no food on your table sucks more.

Reply on news.ycombinator.com