41–50 of 112 posts
I want to like JavaScript, but the type coercion land mines and the lack of a real numeric tower make me a little queasy. When I have to use JS I stick to the transpile-to-js languages mostly for those reasons.
Is TypeScript one of your goto "transpile-to-js" languages? I'm a Python developer who is learning to love TypeScript. With TypeScript I feel like I can write maintainable, collaborateable JS.
Just in case the author is present in the thread: Your blog is extremely difficult to read on wide screen monitors. The entire left 50% is basically just blank space. My suggestion is to make the left side maybe 20% width on desktop or less. Also, regarding the article content: There really aren't any good reasons presented here about why you moved from Python to Javascript for back-end web development. It seems that…
Thanks, I'll take a look when I have a chance. I myself don't own a widescreen monitor, the site looks fine on my MacBook and several other computers. It's not a paid job, not a lot of effort went into it ;)
> but the title is misleading considering that the bulk of the article is actually about which JS tools you use on recent projects and not why you moved.
Hm, actually, it's not. I'm surprised by this comment. I point out precisely the JavaScript features that weighed the most in my decision: "So with JavaScript you've got arrow functions, the method shorthand definition syntax, the spread operator, destructuring assignments, all functional Array methods and async functions. Combined with Vue's minimal patterns and Nuxt's conventions, I can't think of a better language to write web applications in."
> Also, could you clarify what you mean by > > Also, there's no acceptable way to pass a function body to another in Python.
Exactly that, a "function body", "closure", "inline function", whatever you wanna call it. In Python there are lambdas, but they're limited and not even encouraged anymore. We're left with passing function references, and that's where JavaScript comes out the winner IMHO.
Just in case the author is present in the thread: Your blog is extremely difficult to read on wide screen monitors. The entire left 50% is basically just blank space. My suggestion is to make the left side maybe 20% width on desktop or less. Also, regarding the article content: There really aren't any good reasons presented here about why you moved from Python to Javascript for back-end web development. It seems that…
Python has lambda but they are one liners. There is no way to do write this in Python: someFunc( _ => { // this is // a function // with multiple lines }) Having to define a named function to use it as a callback is a pain in the ass. Python has an excellent standard library but the language itself is pretty mediocre IMHO. Classes are an afterthought thus verboses, as so is "functional programming" in Python. JS bigg…
if you have a multiline function it should be named and unit-tested instead of just stuffed anonymously into some pyramid of doom
A lot of innovation happened in JavaScript space over the past few years and yet the learning curve is high. I prefer to use Python for Data Analysis, Data Transformations & Machine Learning. For web applications, Node/Express + React/Vue seems to work better.
Look, writing programs that respond to HTTP requests with HTML is not rocket science. You can do it in JS, Python or Ruby and be very productive. If you hate yourself, you can do it in Java, Go or whatever else and trade server performance for development speed. If you really hate yourself (or are Amazon circa 2004), you can write your whole website as a C++ static binary.
My theory is that the endless proliferation of JS libraries, frameworks and language revisions are because lots of smart and talented developers are employed to build websites - but building websites is just not that technically interesting, so they express their creativity by creating new tools, frameworks, package managers and ES revisions. It's a symptom of boredom.
But my one bit of career advice would be don't "Leave X for Y." Don't tie your livelihood and career to a single X or Y. Learn how to use a variety of tools and pick the best one for each job. Any big project will require using a few different tools and really valuable developers are the ones who can navigate that entire landscape intelligently.
Earlier quoted context omitted.
The author did not say "as a string" and I am extremly confused as to how you read it like that... what? Essentially, the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented (and you are horribly tempted to play extremely insane tricks with decorators to build something that…
> the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented You mean these critics find >>> map(lambda x: x**2, filter(lambda x: not x % 2, range(11))) preferable to the "fragmented": def square(x): return x ** 2 def is_even(x): return not x % 2 >>> (square(x) for x in range(11…
In the real world you filter water to get the water. In most programming languages filter() is more like a strainer or colander.
My guess is you ran into someone stubbornly insisting on the meaning of the word filter despite all evidence.
Earlier quoted context omitted.
The author did not say "as a string" and I am extremly confused as to how you read it like that... what? Essentially, the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented (and you are horribly tempted to play extremely insane tricks with decorators to build something that…
> the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented You mean these critics find >>> map(lambda x: x**2, filter(lambda x: not x % 2, range(11))) preferable to the "fragmented": def square(x): return x ** 2 def is_even(x): return not x % 2 >>> (square(x) for x in range(11…
# square even numbers
range(11)
.filter(lambda x: not x % 2)
.map(lambda x: x ** 2)
Why is all the actual content on the far right side of the page? Even more interesting given that you specialize in UI/UX.
Just in case the author is present in the thread: Your blog is extremely difficult to read on wide screen monitors. The entire left 50% is basically just blank space. My suggestion is to make the left side maybe 20% width on desktop or less. Also, regarding the article content: There really aren't any good reasons presented here about why you moved from Python to Javascript for back-end web development. It seems that…
Python has lambda but they are one liners. There is no way to do write this in Python: someFunc( _ => { // this is // a function // with multiple lines }) Having to define a named function to use it as a callback is a pain in the ass. Python has an excellent standard library but the language itself is pretty mediocre IMHO. Classes are an afterthought thus verboses, as so is "functional programming" in Python. JS bigg…
Happy debugging!
Earlier quoted context omitted.
Python has lambda but they are one liners. There is no way to do write this in Python: someFunc( _ => { // this is // a function // with multiple lines }) Having to define a named function to use it as a callback is a pain in the ass. Python has an excellent standard library but the language itself is pretty mediocre IMHO. Classes are an afterthought thus verboses, as so is "functional programming" in Python. JS bigg…
the problem is callbacks as a pattern if you have a multiline function it should be named and unit-tested instead of just stuffed anonymously into some pyramid of doom
It's like saying all data should be declared as variable, in the functional programming paradigm, functions are data. That's why closures are useful. And it has absolutely nothing to do with unit-testing, that's beside the point. Javascript is not harder to unit test because it has fully featured anonymous functions.