Hacker News Reader

Comment by mosselman | Hacker News Reader

I've heard that some people build UIs with thousands of dependencies, in JavaScript that hits the server for text that is then parsed to object that are then passed through all sorts of classes that each spit out HTML. They also do some weird stuff with events like key-ups in order to re-render input fields based on objects rather than letting the browser manage those kinds of things.

Sounds pretty weird to me.

View on HN

Yes! Web development is "weird" because we (developers) are basically constantly trying to put square pegs into round holes. Over the past ~25 years, a document delivery system has been perverted into a application delivery system. The underlying, fundamental technologies were not intended for "UI" app development.

99% of those "apps" are still just documents with client-side rendering, though. And the web was designed with the intent of running code practically from the beginning, albeit with support envisioned for multiple languages, so programmatic elements in a website aren't really a perversion of the original intent.

I didn't know that. Is there anywhere I can read about it?

https://eager.io/blog/a-brief-history-of-weird-scripting-lan... mentions support for multiple languages, including TCL.

And the possibility of scripts is mentioned at least as far back as HTML3[0] in 1996, with the script tag being added as a placeholder element in HTML 3.2[1], and Java applets were already supported.

So while it wasn't there at the very beginning, it's clear the architects of the web didn't consider running code in the browser to be antithetical to its purpose.

[0]https://www.w3.org/TR/WD-script-960131.html

[1]https://www.loc.gov/preservation/digital/formats/fdd/fdd0004...

The original thesis on REST by Fielding [1].

Section 5.1.7 Code On Demand

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

>And the web was designed with the intent of running code practically from the beginning

This is absolute nonsense. In the beginning the web didn't even have inline images. It was a text-only protocol.

https://www.wired.com/2008/09/history-of-img-and-embed-tags/

Cookies and script tags were hacks added by Netscape, IIRC.

>This is absolute nonsense. In the beginning the web didn't even have inline images. It was a text-only protocol.

Maybe you misinterpreted my comment. "practically from the beginning" does not mean the same thing as "from the beginning." I think something that was considered to be a part of the HTML spec, regardless of how it came about, since the 1990s counts as "practically from the beginning."

>Cookies and script tags were hacks added by Netscape, IIRC.

Tim Berners-Lee didn't seem to have a problem with the premise of embedded scripting in HTML in 1992[0], albeit not with the script tag and JS per se. And my comment was more referring to whether or not executing code in a browser was considered a legitimate use of HTML and the web at the time - and clearly it was, albeit not universally. That paradigm wasn't something Netscape just "hacked" in and entirely forced upon an unwitting web.

[0]http://1997.webhistory.org/www.lists/www-talk.1992/0064.html

The web is "weird" because it's not a platform with a monopoly owner, but the place where platform would-be monopolists fight. Microsoft had a go with ActiveX and lost. Then came back with IE6's incompatibilities and lost again. Adobe had a longer go with Flash and lost. Sun kind of tried with Java applets.

Now we can see the two big vendors Google and Apple trying to slip in features that help their apps or platforms. This is partly why some people worry about the dominance of Chrome; once it's totally dominant, Google can e.g. interfere with adblockers without worrying about losing users to the competition.

> ...a document delivery system has been perverted into a application delivery system...

I love it; this is great! I imagine somewhere in the world today, a witty instructor is teaching a computer basics or CIS 101 course and using something like your phrase above as the definition for the term "world wide web". lol :-)

Yeah, the main problem web apps were meant to solve was the delivering of a client and keeping that client up to date on the desktop. This was during the era where most client software was delivered on disk in a shrink wrapped box. But shortly after that software like iTunes essentially solved the problem. This is borne out by the fact that most users don't have a problem installing or keeping up to date the browser which is required for all these web apps. And of course there's phones, phablets, tablets, chromebooks and the like where it's essentially all client apps.

>Over the past ~25 years, a document delivery system has been perverted into a application delivery system.

...and a protocol for inter-object communication. That's probably the most important part, because that's what creates most of the complexity and security holes today. There is no end to this in sight.

Alan Kay warned web developers about this in 1997:

https://www.youtube.com/watch?v=oKg1hTOQXoY

Nobody listened. The majority of web devs still don't get it. (Can't wait for the arrogant replies here.) We ended up reinventing and re-implementing "internet objects" in the shittiest way possible.

I wonder, why you folks do not

  * build your own runtime
  * running in your own window
  * using your new protocol
  * using a sane UI language

Because the way it is now, the document centric web well may be destroyed, sooner or later by trying to fulfill more and more non-document needs. And we know, how that goes: where the money is...

I think the document centric ship sailed around 1993 when HTML forms became a standard.

I think it was somewhere between the introduction of Javascript, browser plugins, and/or XMLHttpRequest.

I disagree. Nobody said, a document can not be "interactive". With new technologies, old terms expand.

What I am talking about is the total applification of the web, as it happened in the last decade.

> document delivery system has been perverted into a application delivery system

The Web is much more than a document delivery or archiving system, it is hypertext and the boundary between hypertext and apps is fluid. Is Wikipedia an app or a collection of articles? Is HN an app or a collection of comments and links? There is no precise boundary.

When Berners-Lee invented the Web he was heavily inspired by Hypercard [1], an app development kit based on linking cards together.

Web development is "weird" because the web tries to be device- and platform-agnostic. The web works on large widescreens, laptops, smartphones, in text mode or on a Braille display.

Other technologies that have been used to develop UI apps from the beginning, such as Adobe Flash, assume that the display is a kind of fixed screen on which you can draw, with little or no accessibility and linking in mind.

[1] https://en.wikipedia.org/wiki/HyperCard

There is no precise boundary, you are correct. However delivering a blob of minified, obfuscated Javascript code that renders the entire UI is obviously an "app", not a document. Web stuff that does entirely client side rendering is an abomination, IMO.

Sounds weird if you phrase it in a weird way, yes.

Just like communicating with strangers via on-demand electric currents is weird as well, if you phrase it like that.

I have been thinking about this weirdness a lot. In my book communicating via electric currents while seeming weird, isn't because of it's pure practicality. Digitizing these currents instead of transmiting an analog signal seems weird, but isn't because it allows faster, errorfree and more diverse communications etc.

You can go on and follow the technical developement, but you will inevitably reach a point where people stopped understanding the whole stack below them and instead started to cobble together new abstractions from the things they did – until the next generation came and abstracted that. We all know this – it is far easier to add onto something existing, than removing or changing existing things that are just not good enough for the things we want.

So at a certain point you stop doing the rational and efficient thing to solve a problem, but react to more or less organically grown structures and go a extra mile to solve problems you might have never had if you included these capabilities in the existing layers below. But the existing layers below were written ages ago in languages you hate by obscure circles talking on mailing lists, so we don't even bother. The resulting Rube-Goldberg-Machine is weird in that sense: nobody rational who understands all the layers would plan it like it is from the ground up if they had the choice.

> "In my book..."

As I was reading, for a second there I thought you'd actually written a book called "Communicating via electric currents seems weird". Sounds amazing! Where can I buy this book??

Haha sounds amazing indeed, I'll put it on my list : )

I parsed the book name as 'Communicating via electric currents' then my brain threw an exception.

https://www.goodreads.com/book/show/382507.The_Telephone_Boo...

A 10X programmer or 100X programmer finds a way to remove layers of abstractions.

Just hide the nasty layers behind more facades or layers of abstraction. Please never reinvent the wheel, we need more layers, its better software design to reuse the old stuff.

yep, I mean technically you could directly write the UI directly to IP packets and cut out the whole stack, but it's a step in the wrong direction, abstraction allows people to specialize and focus on their domain.

For a non technical example we could communicate via math for all human interaction, it would be more efficient, and truthful, it would also limit though and transfer of knowledge as it puts difficult constraints on expression.

Stacks are good, the web got screwed up by SUN, IBM, and Oracle's insistent vision of a thin client world, that needed lots of servers.

I'm actually shocked at the downvotes. The previous post was discussing the problem of all the layers of abstractions, and I was pointing out that a "10x programmer" could be getting 10x results by finding ways around those abstractions.

Probably because HN is mostly frequented by programmers, and not managers or "startup entrepreneurs" who throw around terms like "10x programmer" as if it's a thing that actually exists, and not a harmful concept that at best promotes gatekeeping and at worst promotes egotists who believe that their sloppy shortcuts won't have to be cleaned up by everyone else when they inevitably fail.

I thought I originally heard about the 10x programmer thing from some of Chuck Moore's talks on Forth. So I went to re-find this article.

But as it turns out he was arguing against 10x complexity and advocating avoiding abstractions with "1x" coding.

http://www.ultratechnology.com/1xforth.htm

I'd argue, one is simply weird because you're (or your hypothetical audience) is not used to it. The other is weird because it's mainly that way due to path dependency.

I can push ideas into other people mind by sending carefully created pressure waves at them

Yep even explaining what happens to give you a dial tone on a landline is pretty crazy when you first look into it.

It surprises many people to learn that the tone isn’t “always there” and that signalling happens with the exchange to create it. This includes checking billing status and other things.

These systems are so robust we mostly take them for granted.

All the critical comments on this. Why are all these critics so scared that there might be an easier way to do web dev?

Are they really just protecting their archane methods because they see that as protecting their income and any simplification a threat to that?

Or is it more tribal, cult like adherence to an overbloated way of creating web UIs?

Or is it people don't want to learn yet another tool and they're just resigned to the fact the these are the tools they have because really, they don't get to decide that anyway, their employer does?

Or is it people don't like being reminded that actually, they're "forced" to use these tools (which they perhaps wouldn't if it wasn't mandated), but because the workplace uses them, they use them, so the existence of other options while accurate is a painful reminder of their own limited autonomy to individually decide the tools they use for their work?

Is the same cultish zealotry seen in other languages and frameworks or is it just (what compiles to) ECMAscript and Web UI/state frameworks?

Not to mention how weird speech is if you try to explain it to in a similar manner.

Well, I can think of good reasons for communicating using electricity. It's fast. The infrastructure is available. I can think of good reasons to communicate with strangers. It's interesting, strangers are interesting.

I can't think of a good reason for depending on thousands of libraries to aid you in laying out and presenting a document, if you are using a language and a platform specifically designed for that purpose.

Says everyone on HN while relying on these weird UIs to do their job daily.

Not only that, - I sometimes create them as well. At least I try to avoid it where possible.

Yeah and I hate that I have to rely on them. They are usually terrible.

They're terrible because Google and Facebook keep swinging their weight around and everyone is following in suit. The actual web specs are actually pretty awesome and can do amazing things with reasonable efficiency.

Server side rendering is very underrated.

It's true! For details, just ask anyone you know who was evangelizing client-side rendering three years ago, they'll tell you all about it.

Not really, PHP is used on 80% of the web. I know, some of it are API-s, but it's still huge. PHP is SSR by design.

Because it works. Things that just work and aren't new are underrated. Like HTML tables.

That's indeed weird. How would they not lose track of their dependencies? How do they keep their code lean and load times fast?

They just hope that Google will keep pouring infinite money into making their JavaScript engine faster.

And they never kept track of their dependencies in the first place. That's the job of some build tool. Whatever it pulls in is fine.

What Google giveth, NPM taketh away.

We target IE11 with angular1.6, React and Vue and it all runs very fast. The only time we ever had trouble were lists over a few hundred items long that our internal customers didn’t want paginated. But delivering those more demanding apps in react and vue solves all our IE11 is slow problems. On any other brothers the code might as well be native.

Wait why are you using all three of AngularJS, React, and Vue?

They probably have a giant AngularJS stack and wanted to slowly migrate to a new framework and they couldn't reach consensus on either React or Vue :D

We have one small piece written in React. It will be replaced when the Angular is finished being moved to Vue, and all new dev is in Vue. It’s a nearly 8 year old bundle of over 56 and counting HR apps and is a feather in our department’s cap for how much money it has saved.

I wanted to move to React initially but after adding a single new app my boss hated the syntax and we switched to Vue. Vue is good too.

That would indeed be impressive, IE surely needs a ton of polyfills?

Lol yes it definitely does. But we still get to use all the syntactic sugar of es latest and IE11 stays very fast. We’re happy and so are our customers.

> lists over a few hundred items long that our internal customers didn’t want paginated.

Does it not bother you that a machine that can do at least a billion computations in a second struggles with a list that short?

Only on IE11 and only in angular1.6. Vue and React it is lightning fast.

Please view the source of this HN page. It has hundreds of elements and images, and renders instantly.

Relatedly, how do they track security issues in their dependencies?

npm does this for you.

They don't need to keep their code lean and load times fast because the speed of their average target CPU doubles every two years anyway... oh wait!!

If you think that's bad you do not want to know what's happening in the code for a desktop or a native app.

Given that the last job I had was maintaining ancient MFC-era C++, the nativest of native apps .. actually, it's pretty straightforward, because so much of it dates from the era when there weren't cycles to waste, but as soon as you touch COM the insanity creeps back in.

Uhm, I do know what happens and it's fine? I mean yeah, today we're using X11 to push application-created images even though the protocol encourages you to render applications from lines, horribly rendered text, and ellipses or something... Btw lines can be stippled, wow!

That is insane!

> ...passed through all sorts of classes that each spit out HTML.

They generally don't spit out HTML, that's how you get XSS. Rather, they turn the data into DOM nodes, dynamically. In theory, that's more efficient, because the data should be smaller than the marked-up data. That's also how you get a UI to sort of rival a Desktop application, you cannot do this all server-side.

Also, all your server-side code that renders HTML is usually more privileged than your client code, unless you did your job very well, which I know you didn't, because you don't have the time and/or money. That's a huge risk surface area. There's a reason why Wordpress instances (which also have "thousands" of components) get hacked all the time, while static-site-generator sites don't.

> They also do some weird stuff with events like key-ups in order to re-render input fields based on objects rather than letting the browser manage those kinds of things.

The browser doesn't manage those things, or if it does, it's very limited and likely different for each browser. You need some amount of Javascript for all but the most trivial forms.

Reply on news.ycombinator.com