Live data from Hacker News

In web design, everything easy is hard again

frankchimero.com

201–210 of 335 posts

Re: In web design, everything easy is hard again

#201
post #82
post #25

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.

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.

Re: In web design, everything easy is hard again

#202

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. 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.

You have to do responsive design, and yes, that's a big change (and a big PITA) but that doesn't require flex or grid or React or whatever. You can't go all the way back to tables, but good ol' div-based design with appropriate CSS works just fine. The new stuff may make some things easier (or not), but if you don't feel like shifting paradigms, you certainly don't have to.

Re: In web design, everything easy is hard again

#203

This 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…

What is "PL"?

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

#204
post #113

By 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…

one thing for sure, it definitely won't need an AMP version any time ever.

Re: In web design, everything easy is hard again

#205

Earlier 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…

It's a bit annoying when doing interop between languages that have the (more common) 2⁶⁴ limit and JS - int64 for IDs etc is fairly common and you then always have to remember to convert them, e.g. by putting IDs as strings in JSON output instead of as a number.

Re: In web design, everything easy is hard again

#206
post #146

Earlier 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.

Interesting. Where do you hear that? What I've heard (and experienced) is that Haskell makes is easy to come back and understand code written a long time ago (because the language allows one to structure code very clearly).

Re: In web design, everything easy is hard again

#207
post #201
post #82

Earlier 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.

There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used.

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

#208
post #30

Earlier 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.

I agree. HTML for documents. C# etc for applications.

Re: In web design, everything easy is hard again

#209
post #30

Earlier 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…

If you are trying to tell me that HTML was purpose built for the task that it does today, then I'm sorry but I do not agree.

Re: In web design, everything easy is hard again

#210
post #22

Earlier 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 has at least 4 ways to define a function: you can have a plain function, a bound instance method, a bound class method, and a lambda, which is similar to the same options js has.

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.

Post reply on HN