Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

see, this is where i'm not cool with this newness.

i've spent years getting away from procedural, and switching to functions, classes/methods. now, we want to get away from that and go back to procedural?

that's all fine and dandy, but you're trying to have a new trick conversation with an old dog that just doesn't care. you're bringing some sort of logic to a conversation where it's not needed. it works for me. i don't get paid to make UI apps or write heavy code nonsense with server side JS. i use a proper back end language. JS can stay in the browser and manipulate the DOM thank you very much. i get paid to make heavy processing code that sometimes is helpful to have UI dashboards.

i can whip up a JQuery front end faster for my needs than most can even figure out what NPM librar[y|ies] they need to use



surely you still use procedural code within your functions and classes.

the point of await/async is you break down the callback nesting into a single set of procedural code. it doesn't mean all your code is procedural. just that what used to have to be a series of indented anonymous functions or spread all over the place named functions can now be an easy to read concise few lines of code all at the same indentation in a single spot. its an obvious net-win for readability and code maintainability. you are doing yourself no favors by not understanding/embracing it.


> now, we want to get away from that and go back to procedural?

AFAIK, we are all still programming browser UI with Javascript. It is an imperative language, about as stateful as you can get.

Now, if you managed to do your frontends with Haskell or Prolog, I'd be interested on learning how.


LISP in the browser! You end up having to ship a large runtime with your app but it all transpiles to vanilla JS.

https://clojurescript.org/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: