I once worked at Chase Manhattan Bank and one of their internal networking teams had a web site for wiring requests. They didn’t want to work too hard so their UI was designed to make data entry as slow as possible, mostly by using huge multi-level drop down lists where the slightest twitch would make them collapse and you would have to start over navigating through them, repeat a dozen times for every run of cable, several runs required to make an end to end connection. It wasn’t custom programming, just taking full advantage of the browsers of the era’s inability to render the UI component for that. So I was building out a data center and needed Something like forty thousand cables run which translated into around one hundred and fifty thousand segments. I tried to give this info via a spreadsheet but they were steadfast that the web interface was the only way they could receive it. So I wrote a script to just post the data directly without going through the UI, ran it, and went home. Turns out all their web form did was e-mail the values to a half dozen people. The e-mail system was Lotus Notes (dates this) so each person got their own copy and there was a lot of overhead. The sudden influx of a million e-mail messages brought down Chase’s email system for two thirds of the country. They spent days clearing the mail queue and recovering - they had to fly in IBM techs with suitcases full of disk drives to add the storage needed. Everyone who received the wiring requests spent days deleting them with new ones arriving as quickly as they deleted the old ones. Then when things were finally normal again they asked me to resend them my spreadsheet.
Wonderful story - thanks! I was at Chase Manhattan in London from 1997-2000, and remember the Lotus Notes system well. I had Win NT and Solaris desktop systems. There was an appalling timesheet system called Agresso, the most counterintuitive Windows GUI I ever encountered. I guess the lesson is that mgmt diktat in corp envs repeatedly inflicts crappy solutions on captive users. Plus ca change!
No! It cannot be that Agresso was already around at that time. I still have to work with that horrific system, even though it is webbased now. It's still a horrible experience.
Agresso was my first job. I got to migrate customers off of Ingres, Sybase, Informix to either Oracle or SQL Server 6.5. After some time, I got the opportunity to build their Crystal Reports integration. This was 1997-1998.
Sorry, I have no insight in that. When I was there we were just upgrading to Agresso 5, and as I remember it, it was pretty much a win32 app talking directly to the database. Not sure how much, if any, server part was there in between. So it has probably changed when they switched to web.
Heroic! Lotus Notes was such a pile of junk. Every time I used it for the simplest task, the combative UI would cause my blood pressure to spike up. I would calm myself down by imagining the blissful life of the ex JPMorganChase IT boss who greenlighted the purchase, living off his giant kickback on some Caribbean island.
My favourite Lotus Notes fail was circa 2008, when the menu item for "Mark message as read" was next to "Mark all as read", which from memory was not undo-able.
Whole books could be written on the terribleness of Lotus Notes. For those too young to remember the 90s, LN really was as bad as everyone says, turning what should be simple (email, maybe a few custom forms) into swampy morasses of pain.
When intranet webapps came along everyone breathed a huge sigh of relief.
Notes was a double-edged sword. It could be as terrible as you've heard, but on the other had it also let non-programmers build surprisingly useful applications all by themselves. (Which is part of why it stuck around for so long -- being useful, those apps tended to get wedged into critical parts of the business process, which meant you couldn't just pull them out and throw them away.)
Notes was conceived in 1984 and at the time was an amazing platform which featured a secure client/server architecture, RSA encryption, data replication and offline support. Both the Notes client and the server (later renamed to Domino) needed to run on multiple platforms (Win 3.x, OS/2, Netware, NT, Alpha, RISC systems etc), and while the code was native C code on each platform, all UI of the client was implemented using an abstraction layer called NEM ("Notes Environment Manager"). Likewise, all database storage was abstracted in NSF ("Note Storage Facility"; and Notes databases to this day still have the .nsf extension). Long story short, the NEM layer was a trade-off between portability and consistency across platforms. And, Notes used F9 to refresh data, way before the Windows standard of F5 was a standard...
> When intranet webapps came along everyone breathed a huge sigh of relief.
Not entirely. Sometimes they were replaced by applets, which are just native application wrapped in a thin layer of html. This causes its own set of problems. At one place I worked (a large government agency), a critical spreadsheet ran as an applet which was only compatible with IE9. They couldn't upgrade anyone's PC's because they risked an auto-update of IE, which would break the ability to run that app.
At another job, a certain time tracking application ran as an applet, requiring a specific version of the jvm to be installed.
Deploying an application that runs in the browser using the browser's native capabilties - js, html, css works great. Using it to embed an applet doubles the misery, as in the short term management thinks they've purchased a portable, always-compatible "web-app", while what they've done is bought a native binary they can no longer properly provision their workstations to run.
> When intranet webapps came along everyone breathed a huge sigh of relief
Not so fast. As a web developer we still had to contend with the horror of IE5/6/7 for a few more years, and initially WITHOUT anything resembling the utility of something like JQuery!
I remember being happy when IE7 came out, because it fixed a bunch of CSS bugs in IE6, and also finally supporting PNG transparency meant that whole new kinds of design were actually possible ... feels so weird knowing what we can do today with CSS and be reasonably sure it works in three major browsers.
I was building "IE-only" internal web apps at the time (with increasing disgust) and having to support legacy browsers even if you knew they were just IE was hell. When I finally broke out into open-source and STILL had to support IE BUT ALSO firefox, safari and chrome (did chrome even exist yet? Mozilla maybe?)... it was not a happy time
I had to do something similar once with FRRs (firewall rule requests) as a F50. There is one official way of requesting a FRR. What that way is a matter of some debate. Theoretically you file a JIRA ticket with fqdn, ip/mask, port, protocol info. Anyways cutting a long rant short I eventually had to write a script to generate 100 SRC X 10 DST X 2 ports rules as csv pulled into a spreadsheet.
After a couple days it was assigned to an engineer for implementation and of course the first thing he did was unflatten it.
I mean yes... but recall that the entire point of the system was that it would make data entry slow. I think that whoever set it up probably felt that the clunky form was enough of a rate limiter and nothing further was needed on the back end.
Just to make sure I get this right - to make sure their team wouldn't get overwhelmed with work (how exactly? It's not like the demand for cable wiring would be too different at the end of a year in a frictionless system) they not only decided to create busywork for other departments, but this design also blew up impacting the entire company?
Do you know if there were any consequences for whoever created this monstrosity?
No, this is every day in Chase. They are basically the McDonalds of the financial services industry - everybody works there at least once, most people move on to better things, what you have left are the ones who know they will never succeed anywhere else. We convinced one manager at Chase that the reason her application crashed so much was because there wasn't enough gigawatts to power the flex capacitors. The guy who they hired for IT security in my department was a bricklayer who ran around with a dog-eared copy of Computer Security For Dummies trying to find out where we were hiding the NFS so he could turn it off (we kept telling him we didn't use NFS and he didn't believe us, so the hunt continued). Probably the worst story was this really portly fellow who couldn't fit into the bathroom stalls, and was too lazy to walk across the floor to the bathroom that had a handicap stall he could fit in, so he would just sort of stand in front of the stall door and cut loose, and every night some poor cleaning lady had to deal with that and it didn't raise any eyebrows at all. Sounds like an NBC sitcom, but it was real, places like this really do exist, stuff like this really does happen.
Sounds less NBC and more (in fact exactly) like It’s Always Sunny.
Specifically Charlie in the mailroom with Pepe Sylvia, and the pissing thing is just classic Frank.
In Germany, where I'm originally from, we have geizhals.de for product and price comparison that works a lot like these pages you linked and has been around for ages.
They have an English version you can check out here: https://skinflint.co.uk/?cat=nb (this links directly to the Laptop section so you can check out their filtering capabilities).
> In Germany, where I'm originally from, we have geizhals.de for product and price comparison that works a lot like these pages you linked and has been around for ages.
Geizhals is not only useful as a price aggregator, but also when it comes to product discovery itself - often I look for products with very specific attributes, which may be represented by different names and keys between sellers and manufacturers. Geizhals' ability to collect and aggregate them in such detail is second to none. At that point pricing information is just an extra.
These do not compare things such as sequential read, sequential write, random read, random write, temperature, MTBF, Backblaze outage percentages (statistical relevant), type of storage (SLC, MLC, AMLC, QLC, TLC, etc), chipset used, and so on, and so forth.
I'm scared shitless to check or use the battprices.com as it probably does not do anything like the above either. Which, in case of batteries, can cause something arguably more severe than bad performance or data loss: fire.
Don't use websites like these. Instead, read reviews and support websites which release quality reviews.
Is there a name for this kind of chart? It doesn't seem to be a scatterplot in the traditional sense because the axes aren't on a regular interval (If you look at adjacent phones the difference in prices aren't even).
OK this is awesome! Thanks for sharing, it fits my nerd-brain like a glove. Wish it would generalise to everything in life like my own spreadsheets (I say that as a compulsive data-collector)
So I checked the Smartphone section. Very limited amount of arguments. The visual representation is nice, but the Tweakers Pricewatch website [1] has a better search because it has better (more) arguments (they could however benefit from the scatterplot system).
Looks really nice! Wouldn't a simple table be a better option in this case though? I quickly got tired hovering over each icon (very small icons too) to look at the specs.
An impressive implementation of a web UI is Figma:
Figma is written in C++ code then run in the browser by cross-compiling it to a subset of JavaScript known as asm.js. The asm.js subset is basically JavaScript where you can only use numbers (no strings, objects, etc.). This is all you need to run C++ code since everything in C++ is either a number or a pointer to a number, and pointers are also numbers. The C++ address space is just a giant JavaScript array of numbers and pointers are just indices into that array.
Of course wasm is more performant as it matures, but they’ve been at this since 2015 and I’m impressed by how responsive the app is.
I used to work at a company that behind the scenes had to use a web UI in a weird/novel way for their system to work.
This company's web UI would allow its users to initiate bank transactions. Nothing weird from the user's end. However, the company had to "approve" the transactions in real time, synchronously. The company could do all sorts of programmatic verification on the user, recipient, transaction, etc, but we had to actually physically press a button on the screen of a smart telephone to approve the transaction. There was no programmatic way around this.
Some programmers at the company came up with a robotic arm which could be controlled programmatically, which would do the telephone screen pressing for us.
I came across this site a few weeks ago. And it's quite unlike anything I've seen. And try to inspect the site using browser inspector. It's a very different ui than I've ever seen before.
I don't know what's more amazing, that I can't figure out what I'm looking at, or that somebody worked on this extensively, and probably continues working on this. I have no idea what this is though.
This is a bit of an odd answer, even in a question that expects odd answers. That is because it sounds so normal, yet I have Googled for it and almost no one advocates for it. They do maybe advocate for it in terms of design, but I mean in making actual static websites.
Enter Google Slides: the product for your uncle Joe and aunt Lysa to create their own websites without knowing how to code!
I even have an example website for you that I made as it is a project that I'm working on in my free time. I already remade the website in actual HTML/CSS/JS but I was simply curious how well Google Slides would work. IMO, it has a thing or two over Sketch (such as displaying GIFs, having links) since I made the actual layout with Sketch, and then redid everything with Google Slides to do a side by side comparison (I went too far with this :P).
There are a few things to consider:
1. Every page needs to be made in its own slide show as you cannot have different document sizes.
2. You will be stuck with a slide viewer, but I figured for the industrious fellow, you could simply inject some JavaScript that disables that whole viewer when you iframe your Google Slides website.
3. There are zooming issues because the pages are of different document sizes.
4. The fact that you need to define document sizes is noteworthy in itself.
So yea, not super duper practical, unless you aren't a web designer and simply want a simple profile page online, but definitely weird :D
Wow, this idea brings me back to one of the moments that first inspired me to start down the path of web development. In 2007 I took a semester off and got a job as a teaching assistant for a special education classroom and was 1:1 with a child that LOVED computers but would get overwhelmed by the information density of your typical website - too many decisions would frustrate him.
One week, we were learning about farms which I was really excited for because his love for the computer was matched only by his obsession with animals. Sadly, his outbursts would require me to separate him from the group time where we would show them pictures of animals and learn about their sounds, functions, etc. This made me think of creating and interactive PowerPoint where I made a slide with options for “petting zoo”, “animals with jobs”, “wild cats”, etc. each choice would lead to a new slide with a set of photos, icons that played their sounds, and even tried creating a set of quizzes where I recorded an animal sound and he had to select a photo that matched.
I worked until 3 AM making this PowerPoint and was deliriously tired the next day, but man the joy this kid experienced while he got to play on the computer AND learn about animals without getting worked up over a multitude of decisions sparked something in me that made me decide I wanted to do something with IT.
Your idea really hit home for me and helped me remember one of the reasons I do what I do today - frontend and app development. Lowering boundaries and making technological concepts more accessible can inspire unexpected interest and adoption.
Note that there is a, less known, google site to make simple website with no coding skills and an interface similar to google slides : https://sites.google.com/new
I'm not old enough to have known Hypercard, though my thesis very adjacently touches on it (kind of, not really, but it talks about Douglas Engelbart and Ted Nelson and hyperlinked text and how it devolved -- according to Nelson -- to the www).
So it's really cool to see hyper card for real this time!
Oh! Of course! I presume you can also inject JS into Google Slides itself. Hmm... I'll see if I can make a simple game then, when I'm bored again.
That reminds me about one other use for the slides editor like power points and google slides: creating posters. It's much easier and faster for an inexperienced person to create a poster from scratch (for your paper, conference talks, etc) with those slides editor than using vector graphic editor like inkscape or coreldraw.
It's probably already obvious for people who regularly uses google slides / keynote / powerpoint, but for me who very rarely use them (but often use various graphic editors) it's quite a revelation.
Similar idea: I‘ve heard that Keynote is (was) popular as a protyping tool inside apple.
I think It‘s actually the best tool do this on the iPad right now. At first the links seem limited because you link to slide numbers, but they actually update when you move things around. Magic Move is beyond what any design/prototyping tool can do in terms of zero effort animation (though figma launched somehtng like this yesterday?).
Hey, I had the same idea long ago: creating a website-like functioning slide show. There was no Google Slides back then so I used Powerpoint and I had no way of putting the "website" on internet.
My wife was actually going to do this for a website. She is a teacher and wanted a small site for her classroom so that the kids and parents could keep up to date with the goings on in the classroom and she wanted to use Google Slides for this since she has used it for work before. I was shocked and was trying to talk her out of it. At the end of the day, she decided the site wasn't necessary or worth the effort so nothing came of it but I couldn't believe she thought to use Google Slides for that.
She wanted to create the site the day before parent orientation. She ended up not doing the site because she figured it wasn't worth the time to make something that the parents wouldn't even visit as the parents of her students are mostly not involved in their children's education.
My main argument against using Google Slides is the URL was not going to be easy to remember when telling parents. I pointed her to things like wordpress or wix that would allow her to have a free account but also would allow her to have a URL that would be easy to communicate. She didn't want to spend any money on a domain name either.
Not sure if this counts as weird or novel web UI, but I wrote a small library to stream Dear ImGui's vertex and index buffers to browsers via websockets, and just render them using WebGL's drawElements [0]. There a couple of examples linked in the README for anyone interested.
Crazy. I thought it was just 1 photo, then it turned into a gallery, then blew my mind when I saw I could see other viewers, then blew it again when I realized I could fly
I am losing my mind at this. I thought it would kind of interesting if it let me move the block around, but it has it's own rotation that you cannot control.
This isn't a weird UI as such, but it's probably a technology that isn't explored enough. Back in the very early 2000s before Javascript was universally available, we wrote a CGI-based technology that worked by persisting the entire state of the page between clicks. It was a true widget-based server-side GUI, so you could build single page UIs by composing widgets such as buttons, labels, and more complex things, hierarchically (like native GUIs). The whole page would reload between clicks but everything was so lightweight and tiny that wasn't actually much of a problem, at least by the standards of the day.
It's all open source but probably doesn't compile on modern machines, and of course for extra fun we wrote the entire stack including the webserver, CGIs, cooperative threading, database layer and C libraries from scratch. From top to bottom this is the entire stack:
Edit: I should say that it's obsolete if you can make the nowadays reasonable assumption that Javascript can be used on the client side. It's more like "this is the crazy shit that a team of developers in their 20s with VC funding, disfunctional management and time on their hands get up to".
Edit 2: It was used in production for quite a long time, certainly until the 2010s. If you were in a UK school in the mid 2000s there's a chance you might have used this.
If I'm not mistaken this is pretty much how ASP.NET Web Forms work(ed). I think Java Server Faces (JSF) uses a server rendered component approach also. The giveaway being the need for a ViewState.
So for a long time this has been a widely used pattern! With today's dominance of (MVC || SPA) architectures I agree it's not as widely known as perhaps it should be.
You could do some heinous, heinous stuff the Web Forms and UpdatePanels.
Interestingly, Blazor seems to be reviving the whole idea. With SignalR, it is actually not completely insane to handle events with the equivalent of code-behind.
Last time I checked Gtk has a web backend, meaning you can run basically any gtk app with the right environment variables and it'll pop open a browser with the app rendered pixel perfect into it.
I don't really think it's useful as an actual web technology since you'd need to spawn a process, reserve a port, and keep a connection open for each and every user which seems like it wouldn't be workable.
Oh awesome, I actually messed with broadway some yesterday on Gtk3 and while it works incredibly well it has some drawbacks to the point where I don't really see a use case so maybe you can enlighten me somewhat.
The main downside I see is that every single keystroke needs a roundtrip to the server. Given a ping time of ~200ms that already makes it nearly unusable. So that leaves running broadway on localhost but then why use broadway at all? You might as well run it normally.
Anyways it's a really cool backend and I feel like with a small amount of work it could actually be used for web-apps, with the amazing advantage of basically eliminating front-end programming entirely.
I’m already seeing this in the wild, at least for more artsy clients, museums, that sort of thing! I kinda like it. Some of their examples are over the top, of course, but think of it as the fashion show pieces that retail chains will digest into more realistic designs over the coming years. I think we kinda need this to escape the tacky, bloated default look that 99% of websites do, nowadays.
I think briefly it was considered cutting edge to have your page content be delivered as an XML document, with an accompanying XSL or XSLT file to mechanically translate the XML into a full-fledged XHTML page suitable for rendering in a browser. I even saw it once on some public website, I think maybe for a Blizzard game? The content XML looked great; very intuitive. The XSLT stuff for translating into XHTML, well, not so much.
The Swedish election authority builds its website like this: https://val.se/
XSLT is quite different and really powerful. I helped a friend once, he wanted to import his iTunes Db to Qlik for analysis. iTunes keeps its data, with number of plays and all statistics, in an XML file. Qlik has XSLT support. So it was just a matter of a couple of lines of XSLT to get all the data into Qlik. It literally went from a complete headscratcher to done with half an hour of studying MDN's XSLT documentation and some experimentation.
I helped maintain (and later started rewriting) a medical web platform that used XSLT for it's HTML exactly like you described. It was powerful for sure, but a nightmare to maintain, extend or add to.
This in house framework was written before the advent of major web frameworks (at least in C# at the time) so I can understand where it came from. In fact, I still consider it an impressive feat of engineering. But XSLT to this day makes me shudder..
For the comment system on my website I wrote a perl script that tails the nginx logs for all instances of /@say/ in the file path of requests. Anything after a /@say/ is considered comment. So the UI for commenting on my website is like,
It emulates a game UI, and uses background video to simulate physical movement when navigating between pages. It also incorporates some controls that are unusual for normal web applications like keyboard controls (shortcuts like 'Esc' to go back, 'Enter' to open chat).
It's a pretty old and very experimental project so some stuff is in a semi-broken state. I should revisit it sometime and clean up.
Animated backgrounds, infinite scrolling, elements that are only partially visible until you mouseover them, and uses zooming interface for opening individual posts.
Feels like a bastard child of GeoCities and modern web.
Careful: the further you dig, the weirder that site gets. Made by some guy (a "world famous artist") who uses the site as some weird recruitment tool for his cult. You could spend an entire day on that site and not see all of it.
Thanks, I found this site on HN a while back but have been unable to find it again when I wanted to show the ascii art in the source code to a friend. I've bookmarked it now so I won't lose it.
A classic from 1996. Olia Lialina (@GIFmodel on twitter) wanted to make a website that had the feeling of a movie, far before movies were feasible online. So she made My Boyfriend Came Back From the War. Here's a mirror: http://www.teleportacia.org/war/
Well, HN is pretty weird for the web of today. That's also why it's so nice to use it. I wish more sites had simple, lean UI that let the text communicate its message, instead of being interactive marketing brochures.
Bong International [1] has done interesting and weird stuff. One of my personal favorites of theirs is bo en's website [2]. They have also done stuff for Bloomberg.
I'm not ready to show it yet (#FML), but my interface renders everything in threads, including graphical controls, which yield messages.
Nothing happens outside the context of a thread. So it leaves a log of everything that happened in that context. Graphical elements can go full-screen... but you don't lose connection to the thread that they appear in.
It will tile these threads across all your (funky, heterogeneous) screens.
I think this will help you to organize things, and homogenize and simplify your experience with those things across devices.
Imagine actually knowing where everything is, and being able to see who, when, and why anybody touched it.
Weird UIs were what I miss the most about the web in the late 90s. There were no rules, and people were just winging it. I remember my friends making websites for their bands and bragging about how they made it so hard to use, that it was like a secret club if you figured it out.
repl.it's jobs page[1] is basically a bash terminal running on the web. You navigate it by using standard commands like cd and ls, and read files with cat, more or similar. This is NOT a bash emulator, this is an actual bash, running in a Docker container somewhere.
repl.it lets you build an app, in almost any language, on the web, and run it. If it's a console app using stdin/stdout, they even provide you with a terminal emulator. Well, that's some pretty impressive instance of dogfooding.
I think the main reason is because you have to build your entire back-end based on the assumption that you are using intercooler. It requires the responses to be formatted HTML for anything more complex than changing the content text. It ends up making the whole approach much more complex than it is advertised.
No, you really don't. What you do, is you write your back end based on the assumption that you have no JS at all, using a server-side MVC framework like Rails or Django or ASP.NET MVC. Make sure that your controllers and views are well-factored and that you're using partial views where appropriate. It's then almost trivial to apply intercooler to the front-end. In a lot of cases, you don't have to change anything at all in your controllers: just tell intercooler to select out the element you care about from the response (this is most appropriate when a lot of stuff on a page is changing at once, e.g. when you are PJAXing-away a full page refresh). In most others, you usually only have to tell a controller to check whether the request is being made by intercooler, and return a partial view rather than the full view.
The point is that you already have the infrastructure that is generating formatted HTML responses (partial views), and you are now re-using it. If you were trying to write a client-side application from scratch while avoiding the easy path of writing a server-side MVC app, then yeah, I can see how it would be more complex than advertised.
Source: I've built a couple of web apps using intercooler.
Would you still use it today? Sometimes I would like to write simple web apps behind a login page, but the complexity of mainstream frameworks (and their build systems!) makes it not worth it to me.
Love "low-tech" solutions to UI experiences. But to be sure, toggling the individual sections does use javascript (view-source -> see 'toggle_visibility').
Back in design school, web portfolios could get pretty interesting. One novel way was to put up a collaborative google doc with some initial info that visitors could edit.
An example of this was http://carlyayres.com/ though it has since been updated to a non-editable page.
One of my pet peeves are websites that use "ease-in" or "ease" transitions. IMO "ease-out" is always the way to go. I hate waiting for things to go full speed
Breezy's insight is that frontends are wildly complex due to the industry vertical (say.. childwelfare), so instead of shaping your state for business, breezy shapes it for content. Content being a header, footer, body as opposed to a post model or user model. This means each page is represented as a node in the Breezy Redux tree with its own header body and footer.
On one hand, it is annoying to traverse the pages to make updates, on the other, I can look at any running application and make close-to-correct assumptions on how to update the store. After all, most applications regardless of industry vertical has a header, body and footer somewhere.
Yes give it a go and ask me any questions :). I was hoping someone makes use of it. It's tightly coupled to Redux, but not React. I don't think it will work great with ember, and I say that because Breezy doesn't require any router or models (again Breezy is about the content state as opposed to business models). It reuses your Rails routes much like Turbolinks.
I once made a calendar UI that used D3 to animate little circles that represented days. Switching from e.g. week to month caused the circles to flow to new locations. It had a pastel color scheme and it was really beautiful. Everyone who came into the office and saw it said things like, "I've never seen anything like this on the web." It was just eye candy really. It never saw the light of day. I begged them to put it in front of users or investors but no dice.
The founders wouldn't show it to potential investors because IIRC they wanted to have some users first. I don't remember why they wouldn't go live with a beta and try to get users. It was a weird little "vanity project" startup and they made a lot of weird decisions (from my POV.)
I favor brutalism. A 1998 style design completely contained in inline code in the header. Using base fonts and features that are supported by all browsers.
The issue for me is, since it hooks into the current page, hence doesn't work if it's blank, slow loading etc, you end up reverting to basic shortcuts often enough, breaking flow.
Still well worth it just for d u j k and f, though :)
This library allows you to compile your winform C# gui app into a set of html, js, wasm and dll files and run them in the browser: https://github.com/roozbehid/WasmWinforms
Completely blew my mind! Probably not practical but really make me wonder if anything is possible with webassembly.
I've always loved the lifestreams metaphor, mental model.
I spoke to Gelernter at a conference, ages ago. His wares were being compared to JavaSpaces. IIRC, maybe because he had done some work on Linda, or his lifestreams was implemented using same, or something like that. No one really grokked what lifestreams was about or how you'd use it. (Jini and JXTA suffered similar befuddlement.)
Any way, I over enthusiastically encouraged him to repurpose lifestreams into a PIM (personal information manager, shows how old I am) unifying all one's communication and activities. To Gelernter's credit, he listened seriously and pondered.
An idea I read about long ago is ring-based context menus. So instead of getting a square list of choices, one per line, you get each choice arranged in a ring around your cursor. So maybe Copy is at 1 o'clock, Cut 2 o'clock, etc. It would be easier to "target" your choice, and even easier once you learned the position of things. I don't know if this has ever been tried. Maybe in a game? EDIT: apparently this is called a pie menu or radial menu: https://en.wikipedia.org/wiki/Pie_menu
I seem to remember trying at least one X11 window manager that used pie menus back in the early 90s - but unless the apps have small menus with small labels, you just get chaos.
I've seen a website favicon be used to show loading and other information at the top of the browser inside the tab. that was really cool. They made the emoji cycle through multiple so that the favicon was animated.
I created this SVG-based graph layout GUI [1] for our learning media website LunchBox Sessions [2]. The graph lets us visually express the prerequisites of each session. Using SVG meant I could do some fun animations to hide the load time when opening a session.
Using Behavioral Programming you can write UIs mainly using event traces. The state of the app is not really contained and managed in the usual way: it's based off of the state of many concurrent threads running at the same time. Here's a TicTacToe example: https://lmatteis.github.io/react-behavioral/
Ooh, 2advanced - as a high-school kid, I must have starred at versions of their "website" for more than 15h in total, in awe, and trying to soak in the pure awesomeness, hoping that it would affect how good early versions of my site will turn out :) Where "my site" was approx 200h of work over something like 15 revisions and complete redo's for a "portfolio" site with 1 design in it :D Good times - I think my parents would have preferred if I just hang out outside and did drugs at that point :D
Same, it really set the bar on what I would try and create during that time. I really liked Flash and its creative tools - I was really hoping the web would continue to make awesome sites with even better tools based on pure HTML.
Mobiles pretty much destroyed all of it as we focus on making sites that can render well on any screen size now.
ZUI huh? Thanks for introducing me to that term. I didn't know there was a name for a type of interface I've created in WPF a number of times. We've always called it a "semantic zooming" interface. WPF makes this super easy, but turns out it's a little harder in the web, but we've almost matched the UX!
My metabrowser [1] transludes webgl volumes into 3d space, and is navigated with FPS controls or VR. It’s ultimately a web site, but I’ve had chromium developers argue with me it’s not really “web”.
For little admin/monitoring ui for Linux servers this is crazy quick to build. Probably would not want such sites on the Internet. Pwnd instantly if you have shell shock
If you have a good set of cli admin tools #youmightnotneedphp :)
A novel way would be to create a UI using a UI that exports the UI code. Using one of these no code tools like Webflow or Handoff. (Disclaimer: I'm the founder of Handoff. Check: www.handoff.design)
Django and SQLite for the backend and jQuery for the front end. And a $5 a month server from pythonanywhere.com.
Also using a splash page from glitch.com using static html.
Even 1 million page views per day is only 12 page view per second on average. Unless your website traffic is really peaky, I don't think you would get too much trouble using sqlite over real db server. And if you do have a problem, swapping db in django is really easy anyway.
Most sites I manage usually only got ~10x increased traffic during their peak hour compared to their least busy hour.
back in 2007 I joined a company in a department where they wrote tailor made websites for clients. One of the sites was built to generate reports for ~50 customer's accounts. It was a single webpage with 50 buttons having the account name on each one of them. So you would see a bunch of different shape buttons on the page, you click a button and you would be redirected to another website. It was internally referred as Death By Buttons.
The only example I can think of is Miro (formerly realtimeboard), but it doesn’t feel like such a stretch there, since it makes sense for their product.
I've wanted to build an application like this for a while. Obviously nothing that would be actually be used, but maybe a personal tool or something. For many simple (probably most CRUD apps tbh) this would seem to work very well
A while back, just for kicks, I built a site whose UI is essentially a slideshow that takes the form of a draggable map. The content is sort of like a PowerPoint presentation, but user interaction is more like Google Maps.
This is more of a joke answer, but r/ProgrammerHumour recently underwent a spate of submissions competing to come up with the wackiest and "wrong" ways to do common UI elements, such as the slider or phone number inputs.
With a feature where arbitrary aspects "update" from under you in ways you could never expect and ensure beforehand are locked down in your favor in the contract/agreement.
For example, a widget might have a compile bug where the CSS rules to explicitly lay out component size only get included in media queries requested with devices using such low PPI that you never catch it in testing because your devices are not icky enough. This "bug" might then be "fixed" in an "improvement release" down the track that ships the explicit sizing to everybody... including your page layouts, which are now broken.
Or maybe you could ship a calendar control that includes a fuzzy date parser, and then remove the date parser "because it was confusing too many users". All emails from power users pointing out lost productivity because of their inability to specify dates like "2 1/2 days ago" or "-2h", or having "2018" map to today's date last year and "yesterday" also include the current time, are quietly sent to /dev/null. The calendar control is updated to use Material Design, two days of which are spent building a test jig to autoreload on 18 devices at once using remote debugging, as part of a subfeature sprint to ensure a certain cubic-bezier transition animation (which 4 people have collectively watched 537 times) "flows" correctly with the right... twang. A further day is spent turning an Arduino into a virtual bluetooth keyboard to ping the 18th device in the aforementioned testing rig; it stubbornly refused to not go to sleep, even when plugged in.
A decentralized bidding infrastructure could be implemented that uses Bitcoin to allow users to vote on which UI designs they like the most by sending money to different wallets. Much ado is had about how to rebuild a Merkle tree from first principles on top of the blockchain in order to implement the wallet tracking needed to power the aggregate collection needed to power the feature. After A/B testing (and some shady network sniffing) finds the UI library is only being used by people with 1Gbps (fiber/5G) Internet connections on devices with 8-core CPUs, it is decided to simply download the entire Bitcoin blockchain into the Web browser of every consumer of the UI toolkit to perform the analytics about which style to load on startup. No testing is performed on smartphones, and in the standup meeting for the sprint in question nobody remembers to point out that 8-core ARM CPUs are not the same as 8-core i9s. The stubborn team lead has sufficient karma to retain the feature even after the stunned bugreports flow in.
Craigslist. Here is something novel: let html and browsers do their job. Let your browser process simple html at light speed. Let GET be idempotent. Let users be anonymous while getting information.
That doesn't sound like it will let someone spend <2 years building their resume without regard to the consequences before moving on to repeat the process at a different SV company though.
The UI could be improved on mobile.
The links are quite close one to each other and I regularly tap the wrong one, especially when I want to hide a tree of comments or a topic on the main page.
It is, but unfortunately the HTML structure is quite horrible. It is built less like a web page and more like an Excel spreadsheet. Makes it terribly hard to parse automatically.
As a bonus, a normal website that doesn't do anything fancy generally has significantly better accessibility than a website that has a novel interface.
Having dependencies might not be a huge problem. But I've made some pretty complex interfaces using nothing but jquery, handlebars, and other util libraries. All patterns thought-out and written by myself. Not once did I feel I needed something more complex. I get the impression all the hype followers of front end frameworks might not have the best idea of what they're doing. Especially when you see people commenting about frameworks like angular/react/vue making jquery obsolete, because one is just a syntax enhancement library for dom manipulation, the others are predefined workflow patterns. I guess if you have to work on teams, or more corporate-y stuff, frameworks make sense, because programmers can be easily added or replaced. But luckily I've had the freedom to work on my own projects by myself, so I get the freedom to define whatever structure I see fit. Fun story: Somebody lectured me on how I should adapt my application to use one of those frameworks because it would reduce the code size according to him. Months later he complained about how he did just that with his application only to realize it made it more needlessly complicated and bloated.
It's exactly because I don't have to think about everything by myself, I'm completely happy using somebody else's well-maintained library and adding it in. It saves time, mine and everyone else's, and frees it up to do other things. "I guess if you have to work on team" - wait you never work with other people? I think that's kinda the basic requirement for many software projects that they scale outside one person coding in a basement or cafeteria.
It's just that if nobody except you can understand the patterns you've created the code is not very maintainable in the long run. Sure it's probably fast and slick, but when you're gone can the next guy read your code? And more importantly, build on top of it?
Try build a complex website with complex journeys and a component architecture and you'll be begging for React.
It's probably because you haven't seen the light. I'd never ever go back to using jQuery unless it was for a basic marketing site - even then I'd probably think of using Vue if anything got more complex than a carousel on the page.
Why would I choose server side rendering? If I build the site in vue with the most optimized output settings, append hashes to files for perfect caching, drop the files in an S3 bucket, throw a CloudFront CDN on top of it with gzip compression, and build the front end of my backend as a REST api sitting in a lambda function that serves HTTPS requests, I never have to worry about server costs being more than pennies a month unless I need to add on other services to my backend.
Having lived thru the hell of trying to deliver web apps via a thin client model I personally prefer rendering on the client for anything that is not a static web page intended for content only (which now days is rarely the case). Thin clients where an anti-pattern championed by the big server vendors, due to the need for big servers. At the time they where justifying the architecture based on the fact that PC hardware was expensive and thin clients would reduce the need for high end PC's. They where trying to sell it before the web, the web just gave them the vehicle to really push it. Those realities are gone and, decent power in pc's is a commodity. If the web where invented today, it would have been a mesh given the current realities of the proliferation of computing power. Unfortunately it has the law of inertia on it's side.
Lambda is great for infrequent, high CPU tasks such as batch processing. It isn't ideal for high frequency low CPU tasks like serving web requests. You'll pay a large percentage more doing it this way. Whether that extra expense is relevant to your business depends very much on your scale (or if you're sitting on a boatload of VC cash, I guess).
If your HTTP requests are high CPU and your doing standard crud type actions, there's something wrong with your codebase. High CPU tasks should be offloaded from the HTTP request into a queue.
Who said I was doing standard CRUD, and it seems like now you're defining HTTP requests as low-CPU activities just to make Lambda not fit explicitly. Nothing wrong with doing high-CPU activity in a request/response cycle if it's consistent and timely.
Sounds like in your case lambda might be a good fit? I'm not really sure because you're not really explaining your use case.
For the vast majority of crud based web apps that I've seen or worked on in the last decade, lambda would not have been a good fit. There's a lot of people drinking the serverless koolaid right now and applying it to scenarios that don't fit it well.
Just sounds like you're drinking the same koolaid, just the opposite flavor.
Have you actually built a lambda backed web service? Guessing no, or you'd know better than to complain about price. Plenty of better arguments to be had than the one lambda actually does decently on...
Yes, I have written lambda functions. In our case it was very cost effective because it was a batch processing job that was relatively infrequently accessed.
I'm not drinking any kool-aid, I've just broken down the math to see what it would actually cost. You can too if you know what your traffic looks like.
"Would" is not a phrase you'd use if you've actually written lambda functions the way we're talking about.
I have. It's pennies, literal pennies. None of those pitfalls actually end up adding up to more than pennies, everything there is entirely theoretical and does not actualize with substantial consequence, in my experience.
All the SPA apps I have worked on have been significantly slower than the server side rendered apps I have written myself.
Page refresh loads are rarely the problem, its usually a database issue, or just a shit load of API calls to load different menus that would be done in one call with server side rendering.
Actually rendering is something that would be better suited for client side. You can cut down on message sizes if you just fetch JSON and a small templating engine.
That doesn't mean it gets indexed the same. Consuming an SPA with rich UI interactions is much different than consuming a hypertext document that provides a conventional structure for content. SPA's like to do things such as introducing custom routing systems that hijack hyperlinks and simulate browser events through javascript. I'd be very skeptical that you'll end up with a result that's the same as plain old server side rendering.
I've been using Preact and the Parcel Bundler for my small projects, I'm able to build awesome stuff like I would with React, but with a few kbs of dependencies and no configuration file !
This is the way. Unfortunately, many people don't know about Parcel and assume that adding 20 Webpack plugins (plus their configuration) is a proper way.
It's pretty much been the standard way to develop UI's since smalltalk. If you look at the old Windows (IIRC 95) render loop, and squint just enough you see react. It's not the greatest, but no one has devised better way to do large app UI dev across teams other than component models. React is just that model bolted onto JavaScript much like the win api was for C++. Before jQuery there was Dojo and by a few months YUI, React is really just a focused and cleaned up version of Dojo's component lifecycle model. React's novelty was the virtual DOM and it was a big leap in realizing web components without sacrificing performance.
jQuery got popular because it was easy, and good for quick and dirties, but it fails when you try to scale it to more than a few developers. It's not a bad tech but you can paint yourself into a corner with it pretty quick if you have to scale it across a team. You see bad code happens. Black boxing is a way of limiting bad codes impact on the overall system, because it is easier to rip it out and replace it. Functional programming is black boxes for back end business logic. Components are black boxes for the UI. It protects me from you and you from me and therein lies the importance of it.
When I first started at my current company, everything was written in jQuery. It was a jumbled mess with thousands of duplicated jQuery code and HTML. The slightest change would make us cringe. Granted this was a poorly designed application from the start, but still.
I learned how to build dynamic web pages off of jQuery and for that I'm very grateful. I also appreciated the way there was little overhead if you just wanted to create something simple.
When HQ gave our business unit the task of redesigning the entire UI in whatever way we wanted - as long as it looked like the mockups - we decided it was time to move on from JQuery.
I had some experience with Angular 2+ at the time, so I tried that one first, but it was too heavy. Same with React for the reasons you outlined. The learning curve on both were steep as well.
Then I came across Vue. When I learned I could easily create an app as quickly as I could in jQuery, without all the dependencies, I knew I found a winner. We moved forward with Vue and although eventually we couldn't avoid npm/node, I still think it's the most beginner friendly and lightest JS framework of them all. That's just my opinion of course, i'm sure plenty will disagree.
EDIT: BTW that article includes Vue-Router and some other frameworks, but you don't have to use any of it. You can simply include vue.js into your HTML pages just like jQuery and write Vanilla JS for the most part, with the added benefit of turning duplicate code into components. Win-win.
If you generate a typical react app with create-react-app, you get ~1000 dependencies in node_modules:
`npx create-react-app some-app-name --typescript`
(it was actually exactly 1000 dependencies which is freaking me out because the number was so round. wondering if it am counting lines wrong `ls | wc -l`)
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.
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.
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.
>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:
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.
> ...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.
* 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...
> 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.
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.
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.
>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.
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.
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.
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??
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.
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.
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.
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?
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.
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.
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.
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.
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!
> ...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.
