3 ms·
Because imperative programming in Javascript, even with OOP principles and patterns, generally leads to even more complexity and messiness. FP is now almost th
by bayesian_horse 5y ago
Because imperative programming in Javascript, even with OOP principles and patterns, generally leads to even more complexity and messiness.
FP is now almost the norm in frontend engineering. Certainly in the React world. Immutability and side-effect-awareness is highly valued.
- pjmlp 5y agoThé irony being that JavaScript doesn't add anything that Smalltalk didn't already provide, yet we have all this OOP backslash and how FP is somehow better.
- bayesian_horse 5y agoWell, Javascript is the language that is able to run everywhere, so that's what frontend engineers have to target. There is some more flexibility now with Webassembly... If you are interested, look up Fable, Bolero, Elm, PureScript, ClojureScript, Grain...
- deleted 5y ago[deleted]
- pjmlp 5y agoAll of them don't wash away JavaScript semantics, just because the source language is something else.
- bayesian_horse 5y agoThat's actually not true, at least if your definition of "Javascript semantics" isn't extremely broad. This was the case with CoffeeScript. But the examples I gave either work with Webassembly (Grain, Bolero), providing their own runtime, or do some work to hide Javascript's data model to a large degree (F#, Purescript, ClojureScript). What stays the same is that you are dealing with the DOM, User events occurring there and a metric sh*t ton of asynchronous APIs.