[HN Gopher] I fell in love with low-JS
___________________________________________________________________
I fell in love with low-JS
Author : im_dario
Score : 109 points
Date : 2022-05-03 15:00 UTC (1 days ago)
(HTM) web link (edofic.com)
(TXT) w3m dump (edofic.com)
| andrewstuart wrote:
| Scott Hanselman says "use the technology that makes you happy".
| Syonyk wrote:
| I'm not sure I agree with that in the slightest, given the way
| the tech industry has gone with software sizes/complexity/etc.
|
| I fundamentally use computers to do the same things I did in
| the late 90s - IRC, chat, some web browsing, development, etc.
| And due to things like Electron, a quad or hex core system with
| 4GB RAM struggles with a lot of these things now.
|
| The result of that is an awful lot of ewaste, as machines that
| were perfectly able to do things when they were released _lose
| that ability_ as the complexity of software goes up - for not
| that many new features, really. AIM back in the 90s fit on a
| floppy, Element is a bloated pig that mostly does the same
| thing - chat with people. At least there are some native
| clients.
|
| I think we should require developers to use gutless wonders
| once a week, instead of "Well, it works fine on my 16 core Xeon
| with 48GB RAM!"
| Ocha wrote:
| I tried to solve this problem for last two projects I worked on.
| Ended up using Rails that rendered Vue components with data
| already passed in the generated html.
|
| It works really well: adding new components or iterating over
| existing ones is super easy, nothing is brittle, UI/UX fidelity
| is great and very easy to implement, minimal to no API calls
| (depending on what components I have on the page). Rails views
| are smaller and much easier to refactor too.
| hu3 wrote:
| Do you have any example? Even a minimal non-working PoC would
| make my day.
|
| I've been dying to implement Vue component responses for my
| projects ever since I first heard about it because I believe
| that this is a way to keep things mostly on the backend while
| still preventing JS spaghetti on the frontend.
|
| I read about https://inertiajs.com/ but it seems too overkill.
| I'd prefer to keep things simpler.
| [deleted]
| theomega3 wrote:
| Do you have an example of how you did this?
| true_religion wrote:
| I was anti-SPAs until I started living permanently on a 2G
| connection. Now I love the few that I use.
|
| They cache _a lot_ of data, lazy load almost everything, and
| renders are much faster. Also, best of all, the experience when
| my internet goes down--which is often--is at least a partially
| functional page, instead of a total blank screen which is what HN
| and other sites that deliver full HTML or nothing gives me.
|
| I cannot count the number of times I have lost a long well-typed
| comment on HN, because my internet went down while sending it and
| my browser apparently considers that to not be situation that it
| can reload the page on using the data it was going to send.
|
| I think SPA's work better on low-data lines because they are apps
| and work just like other phone apps.
| hu3 wrote:
| The problem is that is doing SPA right is hard.
|
| This is the SPA frontpage of my newest client:
|
| https://i.imgur.com/7fbE4BH.png
|
| And their frontend devs are proud of their achievement.
| Apparently it used to be worse.
| madeofpalk wrote:
| This is Gatsby, no? Gatsby is a static site generator?
| gigel82 wrote:
| Oh, I thought this was going to talk about low.js
| (https://github.com/neonious/lowjs), the "node.js" runtime for
| micro-controllers and tiny embedded systems.
| tgb wrote:
| So how embarrassed should I be for using Vue for small, static
| websites? I made a results page for some data my colleagues and I
| processed and there'sa bunch of categories. So there's a selector
| and you pick one and Vue updates the page to show the data for
| that. It's deployed to GitHub pages and the data is static so no
| server needed. I could have made it server side rendered and done
| all 500 different pages ahead of time and gotten faster load
| times and supported JS disabled browsing. But Vue is what I knew
| so I didn't. I'm not a web developer, I just wanted to make a
| site. So have I sold my soul?
| CharlesW wrote:
| > _So how embarrassed should I be for using Vue for small,
| static websites?_
|
| Not at all, and don't let anyone tell you differently.
| dgb23 wrote:
| That seems like a fantastic use case for DIHYW (do it however
| you want).
| grayrest wrote:
| If you solved your problem then it's not a big deal. The web
| isn't that old and has been in constant churn. The signal for a
| shift in what's popular starts with articles like this one or
| the two dozen others I've seen with this same take. Over the
| next two years or so the zeitgeist will move into competing
| solutions, one will "win" and that'll propagate to later
| adopters as the new norm. At least that's how it's worked for
| *SP, Rails, jQuery, Backbone, and React. The current era has
| been unusually long/stable so it's likely that younger
| developers haven't run into the situation.
|
| If you do want to jump on the trend while keeping your Vue
| knowledge, check out Astro [1]. I'm provisionally in the Marko
| [2] camp, not so much for the current Marko but because Marko 6
| is looking good.
|
| [1] https://astro.build/ [2] https://markojs.com/
| Syonyk wrote:
| > _For starters: a lot can be done natively nowadays_
|
| I learned this recently on my personal site when I was going
| through and de-javascripting stuff. I more and more frequently
| run without scripting enabled, and it felt very wrong that my
| personal site had some JS requirements. The worst being that it
| wouldn't render without JS due to a slick little fade-in effect
| in the template...
|
| One of the things I do quite like (living on a low bandwidth
| connection a lot of the time) is lazy loading - and it turns out
| that you can do _that_ without JS too, now, at least in modern
| browsers.
|
| img loading="{lazy,eager}" will do this without needing JS.
| Combine it with picturesets for smaller images (you let the
| browser pick an image it supports and a size relevant to the
| display), and life is good without any JS.
|
| At this point, as far as I know, the only things on my site that
| _require_ JS are the "Make the image bigger when you click on
| it" feature, and then a JS based search function (which sucks
| down an awful lot of JSON, but it's fine, and beats an active
| server backend for a personal blog).
|
| It's also impressive just how responsive a browser on a gutless
| wonder ARM SBC is when all it's having to do is render content,
| not run a bunch of JS!
| zzo38computer wrote:
| Lazy loading could also be made as a user option in a web
| browser, too. (An implementation could also have an option to
| only use lazy loading if the dimensions of the picture are
| known.)
|
| "Make the image bigger when you click on it" also can be done
| without JavaScripts, in a few ways: One way is to just use a
| ordinary hyperlink directly to the image (and optionally you
| can override it if JavaScripts are enabled), another way is to
| just to use features that the web browser might have (if the
| user has them, they can be used; if not, then not), and a third
| way might be to use CSS (although I generally want to avoid CSS
| requirements, too).
|
| Fade-in effects can also be done using CSS, but may be
| undesirable (I am one who would prefer to reduce animation as
| much as possible, and other users too).
|
| For JS based search functions with JSON, you could do something
| that I mentioned before which is <link rel="data"> and the user
| can make their own search functions if wanted (maybe a browser
| or extension might have a JSON searching function with many
| options (that the web page might not necessarily implement; I
| do often find wanted to make queries that the web page does not
| implement)), but if JavaScripts are enabled then it will use
| that one.
|
| Even if the data is rendered into HTML in server-side scripts
| or generated static pages, you can still have <link rel="data">
| or <a rel="data"> to allow to access the raw data, too, since
| it will sometimes be useful.
|
| But in any case, you should almost always ensure that it works
| properly with JavaScripts disabled, and usually should work
| with CSS disabled too. Use <noscript> blocks if needed, and
| include API documentation or download links or whatever, not
| simply "This requires JavaScripts to work". For some types of
| web apps (e.g. interactive games), it might require JavaScripts
| but even then you can include links to documentation, and if it
| is open-source also source codes, even if scripts are disabled.
|
| In general, in my opinion, most web pages should need neither
| JavaScripts nor CSS (and often does not need pictures either).
| Syonyk wrote:
| Interesting - thanks, I'll take a look at some of these
| ideas. I don't care a bit about fade-in effects, though it
| looks like I might still have a "text shift in" effect I can
| get rid of. It's a nice looking template, and the main
| problem with too many tweaks is that I'm long, long out of
| web dev. So I just don't have the current skillset for it.
|
| Pictures aren't an option for my blog. It's very photo heavy
| as it's a lot of teardowns and analysis, and the bulk of my
| hacking effort has been ensuring that all the photos are run
| through the render pipeline and into photosets, to reduce
| bandwidth. I've debated adding AVIF images, but render time
| on _those_ is quite obscene compared to jpg /png/webp. I
| should probably add fallback hyperlinks to the original image
| if JS is disabled - for now it just displays them inline.
| hmsimha wrote:
| > the only things on my site that require JS are the "Make the
| image bigger when you click on it" feature
|
| You could actually do this without JS, just wrap the image in a
| label for an invisible input, and apply transform with a
| transition based on :focus or :focus-within.
|
| It would be ugly, sure, but so much of modern front-end
| development is already ugly.
| azemetre wrote:
| Couldn't you just use a any element with a focus pseudo
| selector? Or is there something in an input that's special?
| timando wrote:
| lazy loading images is only enabled when javascript is enabled
| because the assumption is that if you disable javascript, you
| don't want to be tracked and lazy loading images can track how
| far you scroll down.
| Syonyk wrote:
| Which browsers implement this? I've not seen that behavior in
| my testing.
|
| I was saying that "You don't need Javascript to do lazy
| loading," not making any claims about the privacy or lack
| thereof.
| hunterb123 wrote:
| So mo lo. No, we're lo so mo. No no wait, lo mo so.
| dgb23 wrote:
| Great article! It clearly shows the tradeoffs and isn't afraid of
| stating personal preferences where applicable.
|
| IMO there are a bunch of rules of thumb and use cases for
| choosing something like htmx (great library, I've been using it
| more and more) as opposed to something like React or a React
| based library or web components and so on (much more powerful but
| comes with a cost).
|
| - Progressive enhancement of a mostly static site.
|
| - Most interactions need to query the backend (or hit a cache) -
| typical for DB heavy sites. (Seems to be the case here.)
|
| - You have a fast backend and/or it doesn't make too much sense
| to offload computation to the client.
|
| - You don't have the expertise/willingness/requirements to
| implement advanced and/or bespoke interactive UI features AKA
| your UI is KISS. (Like the ones mentioned in the article.)
|
| - Your template/component library you use on the server is
| similarly productive and composable (was _not_ the case 10-8y ago
| IMO).
|
| - You don't need integration with something like Storybook or
| Workspaces to develop and test components in isolation.
|
| - You don't know if some of the above are true, but the way you
| develop your UI can be more or less easily extended or ported to
| a more frontend heavy solution without creating a JS spaghetti
| mess and spreading frontend logic across client and server.
|
| There are probably few more? But the general point is: Use the
| right tool for the job.
| nawgz wrote:
| > - You don't need integration with something like Storybook or
| Workspaces to develop and test components in isolation.
|
| You never needed this. Those things are pure bloat. If you're
| building React components... build a static CRA app out of
| those components. Voila, you have real-world React examples, no
| Storybook garbage creeping in, no 3minute compile times just to
| find you didn't configure their stupid webpack setup to
| actually catch your TS errors, just the literal environment
| you'll use them in perfectly ready to go
|
| Otherwise, I don't strongly disagree, I think that this point
| is the real key to all these non-framework libraries though:
|
| > - You don't have the expertise/willingness/requirements to
| implement advanced and/or bespoke interactive UI features AKA
| your UI is KISS. (Like the ones mentioned in the article.)
|
| I can promise you people like optimistic app behavior when you
| write it well. And that's not possible with backend rendering.
| krono wrote:
| http://vanilla-js.com/
|
| Criminally underrated, bit of a hidden gem I suppose!
| russtrotter wrote:
| haha! glad somebody linked this! i love how the site presents
| itself just as any "framework" would :-) well-played vanilla-js
| jacobsenscott wrote:
| This is great. I really hope using the architectures, tools and
| frameworks sh*t out by the FAANG companies will become generally
| recognized as an "anti-pattern", rather than the "3133t new way
| to build apps!". It happened before, with the move from the j2ee
| nightmare to rails. It appears to be happening again from the js
| nightmare to ... rails.
| tomatowurst wrote:
| Absolutely refreshing to read and I feel that many of us are fed
| up with the 2015 approach, two codebases, with much of the woes
| coming from the frontend.
|
| I'm super relieved to see that many of us are beginning to see
| the emperor without clothes.
| nasmorn wrote:
| The worst offenders are shitty SPAs that have less UI
| responsiveness than a good old school app. They are simply built
| because the new devs don't know anything else. My favorite is
| Circle CI where they don't even rate Limit the run button and the
| response from the server takes 5s. It's the worst of all worlds
| latchkey wrote:
| Not sure if it is still the case, but Circle used Clojure/Om
| [1]... when I heard them say they did that so many years ago, I
| knew right away it would end up being something nobody wanted
| to work on.
|
| Sure enough, just checked, Om was abandoned [2] and the person
| blogging about how great everything was is long gone [3]. This
| is the absolute definition of tech debt.
|
| [1] https://circleci.com/blog/how-circleci-
| processes-4-5-million...
|
| [2] https://github.com/omcljs/om
|
| [3] https://circleci.com/blog/why-we-use-om-and-why-were-
| excited...
| yawaramin wrote:
| > and the person blogging about how great everything was is
| long gone
|
| Umm, she left CircleCI last year after a 6-year stint. That's
| not exactly 'long gone'.
| valbaca wrote:
| If the project is completely abandoned, sounds more like tech
| bankruptcy rather than tech debt.
| bufferoverflow wrote:
| Serving HTML doesn't make sense. Serving data and rendering it
| client side is the reasonable solution.
|
| Author makes a mistake of mentioning dealing with GraphQL and
| getting and serving a bunch of unnecessary data. And then he
| completely ignores this, and keeps blaming single-page apps for
| his failure.
| jaredcwhite wrote:
| It's breathtaking to see the pendulum swing so obviously and
| definitively back in favor towards HTML-first and SSG/SSR-first
| solutions--to the degree that even the JS-framework-hotness-du-
| jour braintrust is going all-in on SSG/SSR.
|
| I'm still a bit steamed from being gaslit all throughout the
| mid-2010s years when we were told <div id="root"></div> + SPA was
| The One True Way of building web applications. Even now, I run
| into this mindset _in the Rails community_ of all places. But
| thankfully we know now how this story will end, because the
| advantages of wildly simpler stacks which work better with modern
| web specs AND offer improved performance in many cases are
| undeniable.
| madeofpalk wrote:
| I think this is a bit disingenuous and misstating (or not
| understanding) the evolution frontend-focused web development
| has been through over the past 10 years.
|
| There's no pendulum swing _back_ to server-rendering, but
| rather new frameworks and techniques that involve both in
| unison.
| CharlesW wrote:
| > _It 's breathtaking to see the pendulum swing so obviously
| and definitively back in favor towards HTML-first and SSG/SSR-
| first solutions..._
|
| Has it, for you? The pendulum has not begun to swing back from
| where I sit, and I don't see any indications that it ever will.
| dvt wrote:
| > I'm still a bit steamed from being gaslit all throughout the
| mid-2010s
|
| I get downvoted into oblivion every time I criticize React on
| HN (I mean, for one, Vue is like 10x better imo, but that's
| neither here nor there). Just too much money is poured into
| getting people trained on React and too many folks' livelihoods
| is directly tied to React for a serious critique of the
| monstrosity it turned into.
|
| Facebook really did take over the world.
| antihero wrote:
| Other than being owned by Facebook, I'm not sure how exactly
| React is a monstrosity. I think people downvote vue fans
| because it seems they can't help but tirelessly bring it up
| any time there's anything any React and a lot of people
| clearly don't feel that vue is "better", so it gets extremely
| irritating.
| nawgz wrote:
| > Vue is like 10x better imo
|
| That's very much here and there, and ridiculous. Vue offers
| an interface that is extremely heavily transpiled and
| modified before it actually resembles code that can run on
| the browser, and uses an entirely magic (read: opaque)
| rendering system, making performance analysis quite
| difficult. React offers a thin layer on top of JavaScript -
| look up what JSX actually does if you feel the need to
| contest this - and offers clear semantics on how a component
| will evolve over its lifecycle. Plus the TypeScript
| integration is way better.
|
| So now back to your point: what are you criticizing about
| React? That you want the batteries included? That you think
| the vDOM is too heavy? If you're praising vue, I can't
| imagine you have a single legit criticism
|
| > too many folks' livelihoods is directly tied to React for a
| serious critique of the monstrosity it turned into
|
| If other libraries were actually as good, they would take
| over developer mindshare. They're too thick and with too much
| magic you can't control, React is on the exact opposite end
| of that spectrum with being thin and unopinionated outside of
| its core semantics. Which is the right end to be on, and the
| reason it is winning the developer mindshare war. Not because
| of sunk cost fallacy.
| dvt wrote:
| I don't want to get in a whole Vue vs. React thing here,
| and I'm no megafan of Vue, either, but I just think it's a
| _lot_ better designed than React. In fact, I mostly still
| use React because, hey, just about everyone knows it.
|
| > If other libraries were actually as good, they would take
| over developer mindshare
|
| This is incredibly naive. React's sole success relies on
| Facebook heavily pushing it in the conference circuit. "How
| React Saved my Life" was the go-to talk title in the 2010s.
| brimble wrote:
| Redux is the only thing (sort of) from the React ecosystem
| that I'd save from a fire. But mine seems to be a minority
| opinion.
| dgb23 wrote:
| No pendulums are swinging here. What's happening is refinement
| and variation between two extremes.
| jonwinstanley wrote:
| Yes.
|
| I remember reading that this latest approach is only really
| viable because of the use of HTTP2 for the requests and the
| adoption of that technology.
|
| The swing towards frontend made sense before this step change
| in latency.
| brimble wrote:
| AJAX was originally about speed, but as soon as it changed
| from fetching and injecting HTML fragments, to fetching
| data (usually JSON) and performing a bunch of
| transformations and interpretations of it before finally
| modifying the DOM, it's been _in practice_ slow as hell
| compared with traditional server-side rendering.
| x3haloed wrote:
| Ugh. Even reading this article. There's always a The One True
| Way, even though there never really was. The right way always
| depends on the desired result.
| djbusby wrote:
| Too pragmatic, you'll never get clicks that way
| cyanydeez wrote:
| >1 Simple Trick To Adjust Your Attitude to the Task
| tomatowurst wrote:
| I'm still a bit steamed from being gaslit all throughout the
| mid-2010s years when we were told <div id="root"></div> + SPA
| was The One True Way of building web applications.
|
| omg. tell me about it. One CTO I remember flat out getting
| angry that his reason for using React was because Facebook was
| doing it. _that 's it_
|
| We are going to see more reversion to '05 days, with financials
| of SaaS as interest rates rise. I remember one CFO getting mad
| because spending $2 to make $1 doesn't make sense as an
| enterprise company and that his reason was because we are in a
| new economy.
|
| Perhaps I'm extrapolating but it seems that the boring,
| predictable and old is that way because it's been through
| market manias, both financially and technologically during
| periods of novelty recycling.
| cmroanirgo wrote:
| > _One CTO I remember flat out getting angry that his reason
| for using React was because Facebook was doing it_
|
| Lol.
|
| I find it ironic that from a developer standpoint, we're
| quick to jump with the latest FAANG libraries/cult thinking
| paradigms, but especially here on HN, we're equally quick to
| show the hate for those very same companies. Personally, I've
| found that all FAANG software is generally a good reason to
| _not_ use it! (My solutions are all bricks and mortar sized,
| rather than oligarchal /massive advertising globalist farms)
| nick_ wrote:
| > being gaslit throughout the mid-2010s
|
| This is exactly how it felt to me.
| LAC-Tech wrote:
| Is there a standalone way of preventing the white flash of a full
| page load when you navigate to another URL in an SSR app? Or are
| they all tied to pretty big backend frameworks like RoR?
| robgibbons wrote:
| You could use something like Hotwired Turbo. Personally I'm not
| a huge fan, but it easily turns "traditional" web apps into
| SPA-like experiences. Under the hood, it does full page
| requests, but then calculates a diff and only renders parts of
| the page that have changed.
| kall wrote:
| What browser does that? Don't they usually stay on the same
| page while it loads and then switch right to the nw one?
| jon_n wrote:
| https://web.dev/app-shell-ux-with-service-workers/
| marginalia_nu wrote:
| White flashes are usually a loading issue, like too much crap
| in the <head>-tag, or some critical resources aren't loading as
| early as they should.
___________________________________________________________________
(page generated 2022-05-04 23:00 UTC)