Live data from Hacker News

In web design, everything easy is hard again

frankchimero.com

141–150 of 335 posts

Re: In web design, everything easy is hard again

#141
post #103
post #53

Earlier quoted context omitted.

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, f…

And for non-functional languages? Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing. [rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing fu…

It's not that bad.

I've been learning Elixir (a functional language) for a new project I'm working on and even with only being able to allocate 20-30 minutes a day on it, I don't feel like I need to relearn everything. This is with no prior functional language experience, just a bunch of general experience with Python and Ruby.

I have no formal CS education and while I've heard the terms category theory and monads before I have no idea what they are. In my mind, monads are some Haskell related meme and category theory is thinking about whether or not to use categories on a blog engine.

I found Elixir to be curiously easy to adapt to. I spent like 15 minutes glancing Elixir's documentation and now I'm running a Phoenix based web app (somewhat comparable to Rails but not really) following an "error based development" work flow.

This is where you try to do something, completely fail at it, look up the answer and figure out how to apply it. I don't even know how most of Elixir / Phoenix works yet I'm able to accomplish real things.

After spending 15 minutes reading Phoenix's docs on routing, I actually feel like I understand Phoenix's routing system better than other frameworks in different languages that I've worked with for years. This is partly because it's so easy to just trace a function call back to another function call and understand what's going on (plus their docs are badass).

Re: In web design, everything easy is hard again

#142
post #63

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…

I would argue that web development have never been as easy as it is now and that a lot of people just does not take it seriously enough to bother to learn it properly. People think that just because that they did some jQuery development 10 years ago they should be able to use to the same skills now and discard all new developments. Being able to use modern JavaScript and with linting/prettier will in practice make it…

The nice thing about the current situation is, if you want to you can still use jQuery, basic CSS & HTML5 and ECMA sub version 6 for 99% of all sites that exist and are likely to exist. That will remain true for the next decade at least.

Most sites are not applications and never will be. Most businesses will never need a complicated site. Most of the Web has zero beneficial use for React or ECMA 6. Factually that's easily demonstrated just by looking at data compilations of what the Web largely consists of: static content, typically pushed out into the world via a basic CMS. That isn't going to change. Most of what's going on is an evolution in the top tiers, up the value chain. Facebook & Co have dramatically greater technology demands than Joe Small Business or Susan the blogger.

Re: In web design, everything easy is hard again

#143
post #103

Earlier quoted context omitted.

And for non-functional languages? Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing. [rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing fu…

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect program…

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 variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.

Re: In web design, everything easy is hard again

#144
post #103
post #53

Earlier quoted context omitted.

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, f…

And for non-functional languages? Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing. [rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing fu…

> And for non-functional languages?

I would recommend Typescript then.

> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.

True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.

Re: In web design, everything easy is hard again

#145
post #103

Earlier quoted context omitted.

And for non-functional languages? Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing. [rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing fu…

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect program…

Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.

Re: In web design, everything easy is hard again

#146

Earlier quoted context omitted.

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect program…

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

#147
post #79

Earlier quoted context omitted.

Sure that works, especially if you tend to write more web sites than advanced web applications. But that is true for back end as well, a one man operation can write Python or Java in a style and using libraries from 10 years ago and it would work perfectly fine. But depending on what they are doing they might not be as productive as they could be. If you want to try for example React it is incredibly easy to get star…

This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 can run fine on Python 3.6). And no, that doesn't make Python and Java old hat…

You can run 10 year old JavaScript as well, no problem. But Java written today is pretty different from Java written 10 years ago and the Java frameworks are very different.

My point is that you can write code in the style from 10 years ago in any stack but for some reason people seem to take pride in it in the JavaScript world just because they cannot be bothered the actually learn modern development. Not to mention they tend to exaggerate the difficulty of getting started. Compare the tooling, build chain and language features of a JavaScript stack with for example Java. It is not like the JavaScript one is more complicated.

You don't need something like React if you are doing a simple web page but a lot of people ARE building more advanced web applications these days and then it is probably best to just suck it up and learn a modern stack because the old ways of development is not really suited for it.

Re: In web design, everything easy is hard again

#148

Earlier quoted context omitted.

Both ESLint and TypeScript solve all that. In all honesty, if you're not using tools like that I'm not sure you're doing "modern JS development". It's like complaining that modern C++ is a mess while refusing to use references and RAII.

In C++, proper tools are part of the language. In JS, they're part of ecosystem of third party components that's changing on a weekly basis. There's a difference.

> In C++, proper tools are part of the language.

You couldn't be more wrong. The toolset that you need to develop decent C/C++ programs is massive and took decades to develop.

Re: In web design, everything easy is hard again

#149
post #103
post #53

Earlier quoted context omitted.

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, f…

And for non-functional languages? Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing. [rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing fu…

If you want an imperative and statically typed language, try Kotlin: https://kotlinlang.org/

...which targets JavaScript in addition to the JVM (and being an officially supported language for Android development): https://kotlinlang.org/docs/reference/js-overview.html

Re: In web design, everything easy is hard again

#150
post #53

Earlier quoted context omitted.

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, f…

That's incredibly high praise for Clojurescript. It's got some great features but it has flaws, too. I feel like many people new to web dev would be more confused setting up a Clojurescript project than they would be with JS. It was a lot of googling when I did it a couple weeks ago, and that's coming from someone who has done several times over the years (what's this boot thing, I was told lein was the best thing ev…

> It is important to realize that they will increase bundle sizes

Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript.

That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.)

I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.

Post reply on HN