In web design, everything easy is hard again • Hacker News Board

Re: In web design, everything easy is hard again

#111

Post by BjoernKW » Sat, Feb 10, 2018, 1:05 PM UTC

TeMPOraL wrote: post #102

BjoernKW wrote: post #94

Earlier quoted context omitted.

> You can share files. In the cloud, each application defines its own half-assed abstraction over data storage, and you're limited to what the service allows you and/or the company was bothered to implement. proposal-2-final-new-FINAL-draft-02-2018.docx isn't exactly sane data-sharing. With desktop environments you could use a version control system for that but that hardly ever happens in a consistent manner. You ca…

> proposal-2-final-new-FINAL-draft-02-2018.docx isn't exactly sane data-sharing It is, when you can freely move it onto a USB drive, or attach to an e-mail, an IM message, or transmit over countless other systems that have no relation with Microsoft Office. > You can create walled gardens both on the desktop and the web. That's a question of ethics not technology. Yes, but that's pretty much a tautology. Technology i…

> Technology is all about making stuff easier, and web is pretty enabling when it comes to walled gardens and other unethical conduct.

The web enabled us to reason about walled gardens in the first place. Before the advent of the web there was no talk about walled gardens simply because everything was a walled garden.

> Ultimately, the web is what killed end-user open source

That implies that end user open source had really lived before. For end users open source while not exactly irrelevant never has played a huge role. One reason for that perhaps is that there doesn't seem to be a long-term viable business model for open source desktop applications.

> A web application is an ultimate anathema to both open source and free software - you don't get to run the program as you like, you can't inspect it in any way

That's the case for pretty much any client-server application. The Affero GPL for example tries to remedy this but again that's more a question of business model rather than technology.

Re: In web design, everything easy is hard again

#112

Post by tonyedgecombe » Sat, Feb 10, 2018, 1:06 PM UTC

danieltillett wrote: post #27

The whole thing is driven by all fields reaching the highest level of complexity their practitioners can understand. Web design in not inherently complex, but it is filled with lots of talented and intelligent people because the pay is good and the conditions cushy compared to say gutting chickens in some factory. The only way to solve to the complexity treadmill is to drive out all the smart people.

We do have a tendency to make things as complex as we can, which if you are smart is too complex for the majority.

Re: In web design, everything easy is hard again

#113

Post by Jedi72 » Sat, Feb 10, 2018, 1:07 PM UTC

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 richest investors of all time, waste nothing.

Re: In web design, everything easy is hard again

#114

Post by gaius » Sat, Feb 10, 2018, 1:08 PM UTC

randomsearch wrote: post #9

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

Let's take a step back here: the web is designed, from the ground up, for hypertext, interlinked documents comprising text and images, some of which are clickable and lead to other hyper-documents. HTTP - hypertext transfer protocol. "Web dev" should be referring 100% to things that happen on the server, which can be in any language you like, generating documents that are rendered as the end user would like. Forcing a thing designed for documents to run entire applications is what has gone wrong, it is, on the most fundamental level, an incredibly stupid thing to even try, but the entire industry did, and here we are today. It would be like MS declaring all Windows development henceforth will be in VBA macros for Word.

This is why the real engineering disciplines don't take software engineers seriously. You would never see a civil engineer try and construct a bridge out of some completely inappropriate material...

Re: In web design, everything easy is hard again

#115

Post by TheCoreh » Sat, Feb 10, 2018, 1:08 PM UTC

sureaboutthis wrote: post #93

skrebbel wrote: post #68

Earlier quoted context omitted.

I wonder which recent new web standards you think are fads. Push notifications? Offline web apps? Multithreading? async/await?

Not a fad but an example of what I mean (and the only one I can think of this early in the morning). "box-sizing". This seems to have been created because people are unwilling or unable to understand the standard "box model". People find box-sizing is easier for them but it is not necessary as it only combines already available and well understood sizing properties. Worse, many even use the '*' hack to apply it to ev…

Box-sizing is not a good example of a standard that was poorly engineered: it actually fixes a poorly engineered standard instead.

I understand the box model, which is precisely why I think one should not have to perform mental padding calculations just to know how wide an element will be on screen. Content box sizing (the original standard) also makes CSS less composable (since the results of combining multiple classes are harder to account for). Ergonomics are a very important engineering consideration.

The tag also forces the browser to "do something it doesn't do natively" (enter standards mode) so does "use strict"; these are concessions one has to make when a platform evolves over 25 years and must remain backwards compatible.

Re: In web design, everything easy is hard again

#116

Post by dvfjsdhgfv » Sat, Feb 10, 2018, 1:09 PM UTC

BjoernKW wrote: post #56

dvfjsdhgfv wrote: post #34

Earlier quoted context omitted.

> However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers. Could you elaborate on that? From the point of view of the user, an app from the 90s works much faster than Google Docs. From developer's point of view, using a visual widget in an app was as simple as dropping it on a form,…

Yes, the 90s app is faster but can it consume and provide data over a network? Does it afford collaborative editing? Sharing data with others? You can now even use Google Sheets for creating web applications much like Excel has been used for creating desktop applications. Lazarus and Delphi in general certainly are great tools but they're also limited in terms of what types of user interfaces you can create with them…

I don't understand why you're downvoted, your concerns are valid. I don't see any problemw with sharing data over the network, but I don't thin collaborative editing of a standard table widget via network is possible in the current version of either Delphi or Lazarus. However, in the case of Google Sheets, the biggest advantage is not the ability to edit the sheet by many people at the same time (which causes new problems for anyone who tried), but the ability to share it with others once so that everybody has access to the most recent version, forever. This is definitely possible to implement in a RAD from the 90s.

Re: In web design, everything easy is hard again

#117

Post by dbrgn » Sat, Feb 10, 2018, 1:09 PM UTC

bitL wrote: post #103

pka wrote: 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…

Elm is the opposite. From this article:

https://medium.com/@eeue56/why-type-classes-arent-important-...

"Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right."

And

"Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses, but it is less likely that they are than Haskell developers. Alternatives like Purescript provide more abstractions and powerful type systems suited to those from the Haskell community. There are many of us Haskell users who sit happily with Elm too."

Elm favors simplicity and pragmatism over academic FP lingo. You need to change your way of thinking a bit, true, but it benefits the architecture. And it'll take weeks, not years!

You will not find the words "monad" or "category theory" or "algebraic datatype" used in the Elm docs.

Re: In web design, everything easy is hard again

#118

Post by gaius » Sat, Feb 10, 2018, 1:10 PM UTC

cousin_it wrote: post #105

randomsearch wrote: post #9

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 think JS is fine. The root of the "problem" is that the web is an unusual platform. It actually punishes bloat, in a way other platforms don't. A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly. That means web developers must learn that code reuse is a tradeoff instead of seeing it as a pure positive. That's a good thing in my book. Eithe…

* A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly.*

Except that native apps, in practice, don't do that, and websites routinely load 10Mb of JS when the user only wants to read a 5Kb article.

Re: In web design, everything easy is hard again

#119

Post by hnzix » Sat, Feb 10, 2018, 1:10 PM UTC

k__ wrote: post #107

hnzix wrote: post #81

Earlier quoted context omitted.

I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is b…

That's like saying group XY of people is bad because you got mugged by one person of that group one time. While I understand that a problem like this is unnerving, it isn't the rule.

Wait, did you just call me racist for not liking JavaScript?

Re: In web design, everything easy is hard again

#120

Post by undecidabot » Sat, Feb 10, 2018, 1:11 PM UTC

innocentoldguy wrote: post #48

k__ wrote: 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…

Just wanted to make a few counter-arguments:

> re: it doesn't have multiple ways of declaring a function...

Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?).

Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax).

> re: Python's datatypes are straight forward...

While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in.

> re: 9999999999999999 is precisely 9999999999999999

It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with.

FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.