[HN Gopher] The Return of the 90s Web
___________________________________________________________________
The Return of the 90s Web
Author : mxbck
Score : 134 points
Date : 2020-06-18 20:39 UTC (2 hours ago)
(HTM) web link (mxb.dev)
(TXT) w3m dump (mxb.dev)
| agumonkey wrote:
| swings and roundabouts
| ryanmarsh wrote:
| If we're going back to the 90's let this be your reminder we
| still don't have something for web dev as easy to use as VB6.
| toast0 wrote:
| We no longer have anything for the desktop as easy to use as
| VB6 (nor for mobile).
| [deleted]
| sbussard wrote:
| Social networks are failing us and we want independence and
| community. The web used to be that, then it turned into a gated
| gossip community.
| kickscondor wrote:
| I really like the turbolinks approach - you simply write HTML and
| then include the script in your head tags. However, I'm still
| hooked on Markdown. So I am still prerendering HTML - and then
| doing the routing with Hyperapp. (See
| https://href.cool/Tapes/Africa for an example - you get a
| prerendered static HTML page, but it uses JavaScript from there
| to render the other pages.)
|
| The ultimate approach is Beaker Browser though. You can actually
| just write your whole site in Markdown (/index.md, /posts/batman-
| review.md, /posts/covid-resources.md) and then write a nice
| wrapper for them at /.ui/ui.html. This means you can edit posts
| with the built-in editor - and people can 'view source' to see
| your original Markdown! It's like going beyond the 90s on an
| alternate timeline.
|
| (A sample of this is this wiki: hyper://1c6d8c9e2bca71b63f5219d66
| 8b0886e4ee2814a818ad1ea179632f419ed29c4/. Hit the 'Editor' button
| to see the Markdown source.)
| DoubleGlazing wrote:
| Maybe I'm missing something, the article isn't very clear. One of
| the reasons why we have front end apps pulling from an API is
| because it allows for interoperability.
|
| The same API that serves data to the web browser can serve that
| data to mobile apps and to third parties as well.
|
| The idea of bringing HTML rendering back on to the server just
| doesn't seem useful to me.
| JohnBooty wrote:
| One of the reasons why we have front end apps pulling
| from an API is because it allows for interoperability.
| The same API that serves data to the web browser can
| serve that data to mobile apps and to third parties as well.
|
| I agree with the benefit of API interoperability, but I'd call
| that orthogonal to server-side rendering. Your server-side web
| app could be just another consumer of that repurposable API.
| The idea of bringing HTML rendering back on to the server
| just doesn't seem useful to me.
|
| It's a streamlined developer workflow, for one. You have one
| renderer, not an infinite amount of client-side renderers.
| Easier one-stop-shopping debugging. And in reality, I feel that
| the promised performance gains of client-side rendering never
| truly materialized for many use cases.
|
| For projects involving small teams and non-trivial amounts,
| this is a boon. Any backend dev can, at least, write code to
| spit out some semantically correct HTML. Somebody is going to
| need to work on the UI/UX at some point but not necessarily
| full-time.
|
| Contrast with a client-side rendering approach. If there is any
| significant amount of backend engineering behind the site
| (there isn't always, of course) now you have two apps with two
| divergent skillsets and more often than not, you need a minimum
| of two developers.
| Karrot_Kream wrote:
| That's if you're making an application, sure, but on the web I
| view all sorts of sites and most of them are just styled text
| containers, maybe with an optional way to mutate things. HN,
| Reddit, News, recipes, forums, galleries, these are things I
| regularly consume that don't need APIs to return content. For
| applications, like Facebook, it's understandable, but if you
| don't spend all of your time in Social Media, then you probably
| are not really using an application.
| dndvr wrote:
| You must use old.reddit.com
| Karrot_Kream wrote:
| On mobile I just use a client that requests data from the
| API and renders it for me. On desktop, yes, for now, but
| I'm in the process of writing views that load faster and
| don't require a browser.
| bdcravens wrote:
| You're correct, but for many companies, APIs and multiple
| interoperable clients are a YAGNI.
| pgm8705 wrote:
| Having both is still an option with minimal effort. In Rails it
| can be as simple as adding .json to your request and you get
| the data, otherwise the HTML.
| deadbunny wrote:
| Maybe I'm being dumb (I'm a sysadmin, not a developer) but
| wouldn't you just shift those API calls to the server rendering
| the page rather than the browser?
| simias wrote:
| I'm not a web developer but my girlfriend needed a website to
| show her photography work so I decided to make it for her.
|
| It's the simplest thing in the world, basically just three
| columns with photo thumbnails and the only javascript is some
| simple image viewer to display the images full screen when you
| click the thumbnails.
|
| It's really, really basic but I was impressed with the feedback I
| received from it, many people were impressed by how slick and
| fast it was. And indeed, I went looking for professional
| photographer websites and indeed, what a huge mess most of them
| are. Incredibly heavy framework for very basic functionality,
| splash screens to hide the loading times etc... It's the
| electron-app syndrome, it's simpler to do that way so who cares
| if it's like 5 orders of magnitude less efficient than it should
| be? Just download more RAM and bandwidth.
|
| Mine is a bunch of m4 macros used to preprocess static HTML
| files, and a shell script that generates the thumbnails with
| image magic. I wonder if I could launch the new fad in the webdev
| community. What, you _still_ use React? That 's _so_ 2019. Try m4
| instead, it 's web-scale!
| throwawaysbsh wrote:
| Link?
| pgm8705 wrote:
| I'm glad this is the case. I've been a Rails developer for close
| to 10 years now, but 3 or 4 years back I got sucked into the
| React world. I bought right in and my company quickly adopted the
| "React on Rails" pattern. Looking back, it was one of the worst
| professional decisions I've made in my career. Now we're back to
| server side rendering and StimulusJS on the front-end when
| needed. Productivity is way up, and developer happiness is way
| up. With new tools like https://docs.stimulusreflex.com and
| https://cableready.stimulusreflex.com I'm very excited about what
| can be accomplished with minimal JS.
|
| (Note: I still think React is an awesome library! I'm sure there
| are devs that are super productive with it too. It just wasn't
| the best fit for me and my company)
| Animats wrote:
| Webflow is touted as "the new Dreamweaver". Of course, it's
| "software as a service", about 3x as expensive as basic web
| hosting.
| dvfjsdhgfv wrote:
| Can you self-host Webflow-generated content?
| Animats wrote:
| You have to pay $192/year before you can export what you
| created.
| hn_throwaway_99 wrote:
| > about 3x as expensive as basic web hosting.
|
| Good, that's a bargain IMO. I get way more than 3x the value
| out of webflow than I do "basic web hosting".
| JohnBooty wrote:
| I can't _wait_ for server-side rendering to take its place in the
| sun again.
|
| There are many use cases for which a client-side framework like
| React is eesential.
|
| But I feel the vast majority of use cases on the web would be
| better off with server-side rendering.
|
| And...
|
| There are issues of ethics here.
|
| You are kidding yourself to an extent when you say that you are
| building a "client-side web app." It is essentially an
| application targeted at Google's application platform, Chromium.
| Sure, React (or whatever) runs on FF and Safari too. For now.
| Maybe not always. They are already second-class citizens on the
| web. They will probably be second-class citizens of _your_
| client-side app unless your team has the resources to devote
| equal time and resources to non-Chromium browsers. Unless you
| work in a large shop, you probably don 't.
|
| Server-side rendering is not always the right choice, but I also
| do see it as a hedge against Google's, well, hegemony.
| tpmx wrote:
| Back in the 90s I was working on a commercial server-side
| rendering "content management solution". Revision control and
| team workflow (with quite nice conflict resultion UIs).
| Templating using XSLT (sadly, because it's insane). Super
| expressive and solid stuff in general though.
|
| Then the "PHP CMS" wave came, and dumbed everything down.
|
| Then the "reduce the server to an API" and "let insanely
| complex javascript frameworks/apps deal re-invent the browser
| navigation model" came... and here we are.
| untog wrote:
| I think there's a lot of truth in what you're saying and the
| core problem is that we somehow decided there was one correct
| way to make a web site, and that was to use React.
|
| Are you creating a complex webapp? Use React. Go nuts! But are
| you making a mostly static page (blog, marketing site,
| whatever)? Then don't use React. It adds entirely unnecessary
| bloat and complication.
| gpapilion wrote:
| The industry has gone back and forth here forever between
| thick and thin clients, and I view this as an extension.
| Largely we all use thick clients now (PCs, phones, and things
| with way too much compute power), and the move to chrome or
| chromium based browsers made the behavior predictable. The
| pendulum swinging back is really an acknowledgement that the
| advantages provided client side rendering, don't always
| outweigh the networking costs. Data visualization is one of
| these areas I wonder if the javascript methods provide a real
| advantage vs server side rendering.
| zozbot234 wrote:
| Except that phones have only gotten thinner and thinner
| since the 1990s... And PC's (laptops, at least) are not far
| behind.
| alphazino wrote:
| https://wikipedia.org/wiki/Thin_client
| https://wikipedia.org/wiki/Fat_client
| stickfigure wrote:
| This seems to be one developer's wishful thinking, without any
| evidence presented to back up the assertion. Pointing out "hey,
| here's a couple websites that do server side rendering" does not
| a trend make.
|
| We're ripping out webflow, if anecdata counts for anything (it
| doesn't). Webflow occupies the barren middle ground of "too
| complicated for marketing people, too simple for technical
| people". I find it much easier to write html than to figure out
| how to get their UI to make the html I want.
| armandososa wrote:
| This is a legitimate question apropos of OP's web ring: Who
| qualifies as a nerd of the 90s? Is it nerds born in the 90s or
| people who were nerds during the 90s?
| dndvr wrote:
| I did get a chuckle out of a page extolling the virtues of 'html
| over the wire' asking me if I was
|
| 'interested in things like front-end dev and the JAMStack'
| waltbosz wrote:
| What I miss most from the early days of the Internet is the
| content. It was all created with love.
|
| My theory is that the high barrier to entry of online publishing
| kept all but the most determined people from creating content. As
| a result, the little content that was out there was usually good.
|
| With today's monetized blogs, it is often content for content's
| sake. People don't try, or they write about topics which they are
| not really interested in, but did just to have a new post. Or
| often the writing is bad.
|
| Maybe today's problem isn't the blogs, but the SEO that puts the
| crap blogs at the top of the search results. Or maybe I'm
| misremembering and the old content was crap too, or maybe my
| standards are higher than they were in my teenage years.
| izietto wrote:
| My theory is that the more companies you throw in the less
| humanity you can find
| julianeon wrote:
| I had just started college and I remember going to the computer
| lab and clicking around for hours at a time, at night. Just
| going from blog to blog, reading interesting stuff. You didn't
| have to have a particular goal in mind - one blog would lead to
| another interesting blog would lead to another one, endlessly.
| They would all be engagingly written, to a high standard of
| quality.
|
| Like you, I know things have changed, but I still can't imagine
| I could do that today, going from blog to blog, without running
| low on material within ~60 minutes.
|
| EDIT: I see the webring links here now, I may try them.
| duxup wrote:
| I remember visiting big corporate websites and there was always
| a little corner for the 'webmaster' often with a photo of the
| server the site was running on... or a cat... or something like
| that.
|
| Geocities was a beautiful mess as ... it was just folks trying
| to figure out HTML and post silly stuff, but it was genuine.
| kickscondor wrote:
| People are still creating great stuff along these lines - you
| just won't find it through Google or Facebook or most of
| Reddit. Complex, interesting hypertext creations and web sites
| are still everywhere. But try typing "interesting hypertext"
| into Google or Facebook and see where it gets you. You can't
| search for something that's off the beaten track.
|
| This is where directories come back in. Check some of these
| out:
|
| * https://marijnflorence.neocities.org/linkroll/
|
| * https://neonaut.neocities.org/directory/
|
| * https://webring.xxiivv.com/ (which led me to this gem:
| https://dreamwiki.sixey.es/)
|
| Competing with Google in search has become an insurmountable
| task. Personal directories attack from the opposite direction
| (human curation, no algorithm) in a way that actually puts
| Google far behind. It's kind of exciting and unexpected.
| tomc1985 wrote:
| If DMOZ could have held on for a few more years...
| kickscondor wrote:
| I'm not certain DMOZ is the way to go. The big centralized
| directories are too hard to keep current. They get slammed
| with submission. And you end up with so many editors that
| no one has a sense of ownership.
|
| I mean - maybe it's possible. Perhaps a really focused team
| could figure it out. (The 'awesome' directories have kind
| of figured that out, by having specialized directory.) But
| these personal directories are really sweet because they
| don't have to cover a topic. They can just be a collection
| of good stuff, who knows what.
| zozbot234 wrote:
| Federation largely solves these problems. The biggest
| interop issue is sticking to a common/interoperable
| classification wrt. topic hierarchies, etc. and even then
| that's quite doable.
| kevin_thibedeau wrote:
| A solution would need crowdsourced collective vetting of
| sites along with a reputation system to keep out spam and
| bad actors without devolving into Wikipedia style
| personal fiefdoms.
| duskwuff wrote:
| DMOZ started stagnating around 2005. By the time it closed,
| it was already considered irrelevant, and much of the index
| had been unmaintained for years -- there was really nothing
| left to hold on to.
| nextaccountic wrote:
| What we really need is a new Google, built on open principles
| (decentralized / peer to peer, fully free software, backed by
| a nonprofit), and focused on indexing the long tail of
| insightful content that is neglected by Google because it
| lacks SEO, popularity, links, and other metrics that Google
| find interesting but we don't necessarily do.
| CJefferson wrote:
| The problem with any such system is there is money from
| capturing eyeballs, so once any system gets popular a lot
| of people will dedicate time to spamming it. I don't know
| how avoid that.
| slfnflctd wrote:
| It's a fuzzy concept, but I think you're pointing toward
| something there's a need for. PageRank is/was useful in a
| lot of ways, it's just not enough by itself. Its weaknesses
| have been ever more apparent, and it has become less
| effective over time.
|
| There are so many possible viable methods for ranking
| search results! Particularly now with higher level textual
| analysis using AI/ML/[buzzword], and perhaps more
| importantly, the resurgence of interest in curated content.
| People are getting better at discerning curated-for-revenue
| vs. curated-with-love.
| basch wrote:
| Agree on the long tail. And maybe a way to exclude bigger
| sites, and newer results (the time range search doesnt
| really work anymore.)
|
| I had a search today, and 7 of the top 10 results were from
| today. What I was looking for was NOT news, it was
| historical. If I wanted news, I would click the news tab.
| Having 7/10ths of the results come from today makes using
| google to search all of the web ever near useless, as
| todays noise is noisier than ever.
|
| I dont even care if they are defaults, but buttons to
| "exclude big sites" "exclude the news" or "exclude fresh
| results" would make search so much better.
| beamatronic wrote:
| There was less copyright concern back then too. Remember "Make
| James Earl Jones speak"? Or the Hamster Dance?
| inimino wrote:
| My only correction is that there was a _lot_ of content out
| there! We didn 't call it that, of course, because we're people
| and not corporations, so we just called it articles, blogs,
| rants and musings. A lot of it is still out there and a lot
| more is on the wayback machine!
| mtgp1000 wrote:
| I think what you're saying about reduced barriers to entry has
| lowered the standard of all popular media.
|
| It used to be expensive to publish anything - especially the
| further back in time you go. So classics for example typically
| represent particularly bright writers, as having something
| published before the printing press, and widely disseminated,
| was simply unlikely to happen.
|
| But today anyone can create an account on YouTube or stream on
| twitch and it doesn't matter if the content is of any
| particular quality or veracity, so long as the common man sees
| what he wants to see.
|
| I think there's a major secondary effect, in that now that we
| are surrounded by low quality media, the average person's
| ability to recognize merit in general is lessened.
| chrisjarvis wrote:
| The secondary effect you mention is absolutely the case.
| There is unlimited media and unlimited platforms on which to
| consume it. "Content" is truly a commodity now. I would like
| to try to make watching movies/tv a special thing again for
| myself, as opposed to little more than background noise. I
| think this will require careful curation and research, rather
| than just trusting an algorithm.
| dragandj wrote:
| Yes, there is unlimited media and content, but the thing is
| that _most_ of this content is either total crap, or
| polished content that was too much optimized for the median
| viewer. There _is_ great, non-polished but authentic
| content for every niche, but it is very, very difficult to
| find it. Such content is not a commodity, but
| unfortunately, it seems that the average content is good
| enough for the average viewer...
| kickscondor wrote:
| I don't quite follow - if low quality media is everywhere,
| doesn't high quality media stand out?
|
| Perhaps you're saying that so much low quality media drowns
| out the high quality media - such that it can't be found. The
| ratio is off, right?
| dragandj wrote:
| It stands out, but it's so far away from you when you
| search for it, that it's below the horizon...
| worble wrote:
| >if low quality media is everywhere, doesn't high quality
| media stand out?
|
| You would think so, but more often than not, most people
| don't want high quality. What happens is that the media
| that panders to the lowest common denominator stands out
| the most, since that what the majority focus on.
| yagodragon wrote:
| I really hope personal blogging becomes popular again!. Speaking
| of which, I still haven't found a really good alternative to the
| "horrible" WordPress for blogging. It has:
|
| - Integrated API, RSS
|
| - Tons of plugins
|
| - Accessibility, translations
|
| - Easy and powerful editor(Gutenberg)
|
| - Comments sections and forms w/ complete ownership and
| moderation
|
| - Easy data imports from multiple platforms.
|
| - Users and roles
|
| - 100% open source w/ GPL. You own your data
|
| - Extremely easy and cheap to host and move around.
|
| I love modern tooling and git based workflows for all my project
| but my "static" 11ty/Gatsby.js blog doesn't provide all these
| features out of the box. Instead of writing, you end up
| reimplementing basic cms features.
| movedx wrote:
| Have you considered something like Ghost? ghost.org
| aaronax wrote:
| Drupal is what I use. In addition to the blog part, have
| enjoyed creating custom content types to track some interesting
| things in my life (cars, phones, and computers for example).
| Then I add a view to show them all in a table with the columns
| and sorting that I want for that particular content type.
|
| In the past I have used the APIs to a very small extent. I
| stored license keys for an app as a content type so that they
| were easy to manage by employees, and the app connected to a
| service that called the API.
|
| Probably any fleshed out CMS will check all but the last one of
| your boxes (nothing is going to be "extremely" easy to host).
| usrusr wrote:
| Preloading on button-down, nice detail optimization. It's
| possible that you have to abort that request, but it will be the
| rare exception. It's my favorite thing I learned today.
| noisem4ker wrote:
| See previous discussion:
| https://news.ycombinator.com/item?id=23203658
| dhosek wrote:
| Funny that he started with the claim that the dancing baby gif
| wasn't coming back. Turns out, it's already back.
| https://twitter.com/JArmstrongArty/status/122590192989894656...
| purerandomness wrote:
| I recently watched the "Helvetica" documentary that was posted
| here a few days ago [0], where they briefly mention "Grunge
| Typography" [1], a seemingly dead-end branch of typography that,
| for some strange reason, became pretty popular for a short period
| of time.
|
| After some years however, consensus amongst designers formed that
| what they've created was a pile of illegible garbage, and
| realized that there was no other way than completely dismiss that
| branch, go back to the roots, and evolve from a few steps back.
|
| I feel the same kind of consensus is slowly forming around ideas
| like SPAs, client-side rendering and things like CSS-in-JS.
|
| We saw the same happen with NoSQL and many other ideas before
| that.
|
| We recently deployed an entire SaaS only using server-side
| rendering and htmx [2] to give it an SPA-like feel and immediate
| interactivity where needed. It was a pleasure to develop, it's
| snappy and we could actually rely on the Browser doing the heavy
| lifting for things like history, middle click, and not break
| stuff. I personally highly recommend it and see myself using this
| approach in many upcoming projects.
|
| [0] https://www.hustwit.com/helvetica/
|
| [1] https://www.theawl.com/2012/08/the-rise-and-fall-of-
| grunge-t...
|
| [2] https://htmx.org/ (formerly "Intercooler")
| trimbo wrote:
| > After some years however, consensus amongst designers formed
| that what they've created was a pile of illegible garbage
|
| Really? Citation needed?
|
| I guess I have never heard graphic designers say anything about
| David Carson except that he's one of the most innovative and
| influential designers in the past 30 years. IMO his graphic
| design was amazing and perfect for the context (music and surf
| magazines). I loved getting my monthly issue of Raygun and
| marveling at what neat designs they had done this time.
|
| The decline of it is pretty easy to explain: the same thing
| that killed print altogether also killed print music magazines
| (i.e. the internet).
| purerandomness wrote:
| You might want to give the two first sources I've linked a
| visit. Both mention David Carson, and the Raygun magazine.
|
| The sentiment I paraphrased was stated by designer Maximo
| Vignelli, although he didn't single out David Carson.
| lawik wrote:
| I've spent a lot of time thinking about getting back to what I
| find a healthier set of trade-offs in development and healthier
| product. I lile this idea that the current pushback against
| modern JS trends is simply backing up and setting out again in
| a new, hopefully better direction.
|
| I'm invested in Elixir and there are some interesting,
| different trade-offs being made there for highly interactive
| things with Phoenix LiveView. And there is the Lumen compiler
| to potentially in the future not need JS as one could write
| Elixir to get WASM for the interactivity needed.
|
| My bet is still mostly on server side rendering and static as
| much as possible. Current JS does have the JAMstack ideas that
| I find a healthier direction.
| dewey wrote:
| I have fond memories of creating images with Grunge fonts in
| some pirated copy of Photoshop and then positioning them with
| HTML tables and Dreamweaver.
| themodelplumber wrote:
| Those were good times in a lot of ways!
|
| Also I may be an outlier, but IMO grunge as a textural
| expression still benefits lots of contemporary design
| projects. In fact if you know how to work within broader
| principles of design, maybe you stop caring as much about
| what's current, because that's just one of many outcomes that
| may or may not be appropriate for the message...
| binarytox1n wrote:
| This is how I learned web development. Don't forget
| photoshopping the glossiest buttons possible. Not sure if
| that fad was before or after the grunge.
| sidpatil wrote:
| Gloss was a trend in the mid 2000s, if I remember correctly
| --around the same time that AJAX started becoming really
| popular
| brandonhorst wrote:
| Web 2.0. Such a bright outlook in those days :)
| clivestaples wrote:
| I began developing apps the "old-fashioned" way over a year
| ago. My day job is React but for my side businesses, it's all
| PWA and Rails. Light React/Vue (depending on my mood) when I
| need a fine-grained interaction or a slick animation.
| hoorayimhelping wrote:
| > _We recently deployed an entire SaaS only using server-side
| rendering and htmx [2] to give it an SPA-like feel and
| immediate interactivity where needed. It was a pleasure to
| develop, it 's snappy and we could actually rely on the Browser
| doing the heavy lifting for things like history, middle click,
| and not break stuff._
|
| I'm glad we're coming back to server side rendering with some
| JavaScript for interactivity, but from about 2005 - 2015 this
| was simply known as web development. You didn't need to worry
| about breaking the back button or middle mouse or command
| clicks because they just worked.
|
| I feel like with React, we made the actual JavaScript code
| simpler at the expense of everything else in the system
| becoming way more complex.
| yoz-y wrote:
| Depends on what you build. I find a REST server + client side
| rendered frontend quite simpler to grok than a server side
| rendered page. Mostly because the separation between UI and
| data is really clear and all of the CLI interfacing comes
| free as well. There is certainly a way to split this well
| with SSR, but it's also easier to fall into the trap of
| tightly coupling the parts.
___________________________________________________________________
(page generated 2020-06-18 23:00 UTC)