1. 1

    I still struggle on how to choose the right log level. Error and warning are easy; errors are when there’s certainly an error in our code, warning is when it’s a strange and wrong condition, but no obvious error. But info/debug/trace? I mean, there’s still an intuition to follow, but it’s so vague and there are so many instances where it is completely unclear what’s the right level.

    Also, quite often when you need to dig into logs, you end up following the call stack of your program, and you wish that your logs would be bound to that callstack, just as exceptions are. Wouldn’t it be ideal to browse through your logs not as a list, but a call stack tree? If only recording the whole stack on every trace log message wouldn’t be such a performance hit.

    1. 3

      My personal rules of thumb:

      • error: when there is an error in my code: the famous “this should not happen” (IO error, get db from known id, etc.)
      • warn: when there is an error but can be generate from bad usage (not enough permission from a user, bad id from an api, etc.)
      • info: steps that I want to be logged in a normal usage (something important is saved, a process is started correctly, etc)
      • debug: what I put in printlin or console.log to know what happens when debugging on my machine
      • trace: often use in conjunction with generated log (enter and exit a function) or something heavy to compute if the level is not enabled
      1. 1

        Most of the time I only use debug, info and error, with a log level setting of info, which produces info and error log messages in production systems. Debug logs are very verbose and print very detailed info. Error logs are only used for errors and info for important non-error information that’s useful in production, like requests and responses, initialization events of parts of the system and other things you might want to keep track of like some business metrics.

        About creating useful logs, what I have done in the past is pass the unique request ID to all loggers so that every log is correlated by request ID. This is very helpful but to be honest I don’t do it on every project because I don’t have a good strategy to do it in a clean way. Ideas are welcome.

      1. 16

        Yes, I agree. It kills me to see people say a traditional website isn’t RESTful when it is actually exactly what Fielding was trying to describe in his paper. A simple website form too I’d take offense at saying it not consumable my machines: html is also machine parseable and submittable. Kinda a pity html forms don’t let the other methods be used though instead of just get and push.

        But like imagine if everyone did it with forms. You don’t need any more separate api explorers, the standard browser does it! They could include documentation right on the page, or clients could just bypass that and submit what they know.

        So I actually made my D web thing able to do a bunch of this: it reflects over the D functions and can build HTML forms to fill them in, then process it on the receiving side. Or you can submit json for the http api people. I love it and i wish more people would explore these ideas.

        1. 7

          Yeah, I blame the brain-dead verb limitations of most browsers’ HTML form implementations for an entire generation of web developers not being able to see what HTTP is. I’ve had people as me questions about “HTTP vs RPC” which is like asking “PHP vs templating language” – bur if you don’t think of HTTP verbs as freeform space then “BrowserTP” is easy to see as just a dumb tunnel that you need to layer a second RPC on top of.

          1. 2

            It isn’t strictly the implementations’ fault, since the html spec (see html4 thing here https://www.w3.org/TR/html4/interact/forms.html#h-17.13.1) only allows the two values! And html5 https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-method added “dialog” rather than the other keywords. I just don’t understand why they won’t expand this.

            In my library, I did a post with hidden input method - similar to what ruby on rails supports - but it is so annoying.

            1. 2

              Well, with HTML5 the spec authors are the implementors now (even more so than before) – but also if implementations had been doing this all along as part of their “extensions” someone would surely have a spec edit by now, even before they controlled the spec completely. Every single framework out there has some crazy workaround where you send a verb as a query param or similar, but no one seems to want to fix it. Well, that’s not totally true. XHR also had this limitation for awhile but fetch does not, so yay?

              1. 3

                Yeah, that’s true. I guess they’re just more interested in the next shiny thing instead of revisiting fundamentals.

          2. 5

            You should check out htmx is an attempt to extend HTML to actually be more useful. Including allowing you to send POST, PUT, PATCH or any other HTTP method from HTML without writing custom JS.

            1. 1

              This seems like the opposite of what I want. I want <form> to accept method="PAY" or whatever else, not for non-forms to be able to do ajax.

          1. 2

            Finish my blog post on Value Objects in TypeScript.

            1. 2

              I would love it if browsers also allowed things like U2F without Javascript. My login pages have zero javascript on purpose, but I would love to offer U2F.

              1. 2

                I don’t think that the goal should be to remove JS from the web but rather make the other fundamental technologies (HTML/CSS) as powerful as they can be without changing their nature.

                If this proposal or other like it is adopted it will extend the capabilities of HTML while remaining a declarative language that encodes UI, data and actions to perform on that data.

                1. 3

                  agreed, I’m not saying JS should die a horrible death, it’s far to entrenched now to go away any time soon, and it’s not an abysmal language, though there are definitely some warts.

                  I hope this or something like it gets adopted AND I hope the browser(s) continue to expand on what can be done without JS, as there are cases where JS is a bad idea, like say login forms and places where security matters. There are mitigations, like sub-resource integrity, CSP, httponly cookes, etc. But if one can avoid that, then one probably should. There isn’t really anything like veil/pledge or capsicum, etc for JS web code(CSP sort of attempts it), so once you allow execution of JS, your attack surface gets gigantic and very hard to reason about, especially as browsers continually add more attack surface daily. I’m not a browser developer, and I don’t want to have to become a browser developer to reasonably ensure security and I don’t think I should have to, but clearly browser developers disagree.

                2. 1

                  The reason why JavaScript exists in the first place is to allow web pages to be rich and interactive without complicating HTML by adding in imperative logic - and U2F is so special-purpose (relative to HTML’s goal of delivering documents) that modifying HTML to accommodate it would incur significantly more complexity.

                  1. 1

                    U2F has 2 API calls, it’s not THAT complicated: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#methods

                    The entire point of the OP is they figured out how to make it declarative.

                1. 8

                  I really like the idea of extending HTML to support many common UI patterns that currently need JS. In a sense this is nothing new. We have built in calendar picker, button hovers and form validation all of which requires JS before they where included in HTML or CSS.

                  This would be the next logical step, allow HTML to make HTTP requests and replace small parts of the page.

                  1. 3

                    Precisely! Stuff like routing, data binding & http requests should be doable out of the box.

                  1. 4

                    Starting to work towards migrating our two large single page apps to old school server rendered web apps.

                    1. 1

                      Server rendered is old school now? Pfft, I’m old.

                      1. 2

                        It was once the only way to do web apps, so if that’s not old-school, what could be?

                        1. 1

                          Well, if you were not born yesterday, then anything about web design you know is outdated.

                      1. 1

                        I have a lot of aliases on my dotfiles and some of them are actually mini scripts. I should try something similar. Good stuff.

                        1. 1

                          Before making them scripts, consider making them functions. It’s much more manageable than having a script and you still get arbitrary arg referencing. Try composing them too, if you have to. But if they’re overwhelming your shell rc, go ahead :)

                        1. 1

                          TypeScript will become even bigger. As JS codebases keep growing rapidly, old object oriented approaches will start to appear more on JS code bases. Teams trying to use purely functional approaches will start to appreciate the multi paradigm nature of JS.

                          1. 2

                            This week I’m talking to people interested in our latest project FilePreviews.io. They main thing we are interested in right now is trying to better understand the range of use cases and maybe how to reach more users with the most common of them. If anyone is interested in using our service please reach out gcollazo@getblimp.com