Earlier quoted context omitted.
Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up r…
I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.
In web design, everything easy is hard again
201–210 of 335 posts
Re: In web design, everything easy is hard again
#202html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confu…
> html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. A decade ago, the requirements for supporting all/most clients (devices) were radically different. Different requirements mean different solutions and perhaps new tools must be used.
Re: In web design, everything easy is hard again
#203This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters w…
I find it kinda funny that you compare to Python as the way you want webdev to be, since Python and JS are very similar in my mind, aside from minor syntax differences and JS keeping more warts from it's early days, they are very similar environments.
I like Python and have been doing some Tensorflow recently, and one thing I've definitely noticed is that Python docs really suck compared to mdn JS docs.
The biggest problem with JS on the other hand, is it's lack of a decent standard library so you have to use a lot more 3rd party libs, and setting up a modern babel/webpack/linter/test tool chain is a pain in the ass with so many different options to choose from.
Re: In web design, everything easy is hard again
#204By chance I ended up at the Berkshire Hathaway (Warren Buffets company, more like mega-conglomerate) website today. http://www.berkshirehathaway.com If that site is good enough for one of the worlds most valuable corporations, maybe we're just massively over-doing the entire web? Side note, I laughed really hard when I saw that they had a god damn ad hard-coded on the page hahaha. That's how you end up one of the ric…
Re: In web design, everything easy is hard again
#205Earlier quoted context omitted.
I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is…
Both ESLint and TypeScript solve all of that except the integer thing. But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to compla…
Re: In web design, everything easy is hard again
#206Earlier quoted context omitted.
Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more. The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or v…
Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.
Re: In web design, everything easy is hard again
#207Earlier quoted context omitted.
I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.
If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.
I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.
Re: In web design, everything easy is hard again
#208Earlier quoted context omitted.
HTML is inferior than a technology that is purpose built. It was not originally designed to handle the job it does today. It is possible to create a much better user experience with eg. C# using some network code to talk to the server than trying to shoe horn an application over HTML just because it hides the low level complexities of E.g C#/C++ communicating with a server. This is a classic case of HTML/web apps are…
C#, and maybe all programming language, are not designed for structuring documents inside a browser either. That is what HTML is for, not display or applications or communication, etc.
Re: In web design, everything easy is hard again
#209Earlier quoted context omitted.
HTML is inferior than a technology that is purpose built. It was not originally designed to handle the job it does today. It is possible to create a much better user experience with eg. C# using some network code to talk to the server than trying to shoe horn an application over HTML just because it hides the low level complexities of E.g C#/C++ communicating with a server. This is a classic case of HTML/web apps are…
HTML is not inferior it's different. In the late 90s some people said the same about Java and Java applets in particular. The UX of those however often was significantly worse than that of roughly equivalent (but at that time less dynamic) web applications. Apart from the usual benefits like being able to easily link to and consume resources HTML affords you a great deal of flexibility. Desktop UIs for very good reas…
Re: In web design, everything easy is hard again
#210Earlier quoted context omitted.
I didn't find JS any worse than Java, PHP or Python. They all have really ugly parts at least in JS they don't slow you down.
I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is…
Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks.
Other than Python's superior type handling and standard library they seem like very similar languages to me.