[HN Gopher] UnsuckJS: Progressively enhance HTML with lightweigh...
___________________________________________________________________
UnsuckJS: Progressively enhance HTML with lightweight JavaScript
libraries
Author : vmoore
Score : 193 points
Date : 2023-06-15 17:06 UTC (5 hours ago)
(HTM) web link (unsuckjs.com)
(TXT) w3m dump (unsuckjs.com)
| tln wrote:
| I'd love to see a list of heavily interactive sites that use the
| HTMX technique.
|
| I believe Github uses something like HTMX + ActionCable, and it
| shows how good that experience can be (and some limitations).
|
| But I think it's in the small minority. It'd be nice to know of
| more examples, instead of just more libs.
| danielvaughn wrote:
| Same, it seems like the kind of thing that would be highly
| useful with light interactivity, but may not scale well. I also
| haven't really spent much time in it, so idk.
| caseyf wrote:
| Hey.com is one.
| tln wrote:
| Good example, thanks. Also Basecamp
| mikepurvis wrote:
| I haven't studied the guts of it, but I've been impressed
| recently with Github. It feels like a normal, page-by-page
| application, with human-readable URLs, and none of the usual
| SPA shenanigans as far as after-page loading, infinite-scroll
| nonsense, or broken back button behaviour... but then stuff
| happens like a page that's sitting open on a PR automatically
| pulls new comments as they are posted, and it looks identical
| to if that page was loaded afresh. Spiffy.
| canadiantim wrote:
| I very much agree. GitHub is always a source of inspiration
| for me design-wise
| satvikpendem wrote:
| I can do the same thing via NextJS and output pure HTML and CSS
| without any JS at all. Or with server components, output only the
| minimal JS needed. Not sure why everyone wants to write a
| programming language inside HTML like lit does.
| spankalee wrote:
| How is Lit's use of JS in templates any different than JSX?
| Both use JS for expressions and control-flow.
| ReD_CoDE wrote:
| JSX is expensive than JS, because JSX first needs to become
| JS, then other things happen
| spankalee wrote:
| That doesn't speak to this comment:
|
| > Not sure why everyone wants to write a programming
| language inside HTML like lit does
|
| When that's exactly what the OP's suggestion of React does.
| FireInsight wrote:
| The king of "use JS frameworks, output pure HTML" is Astro.
| (https://astro.build/) It's basically an SSG where you can use
| a number of frameworks to write your components, and shipping
| any JS is explicitly opt-in.
| satvikpendem wrote:
| Astro is pretty nice too, I was going to write my blog with
| it but I liked the instant page transitions that NextJS
| provides out of the box for which I couldn't find a suitable
| solution in Astro.
| toddmorey wrote:
| Astro is adding (optional) client-side routing. I'm excited
| about that.
| jen729w wrote:
| Doesn't NextJS do that with client-side JS though?
|
| I recently moved from Gatsby, which did that -- and the
| transitions sure are instantaneous -- to Astro, which
| outputs plain HTML pages. Each navigation is a request to
| the server. Yeah, they take a touch longer. But the
| response is tiny.
|
| You could always `preload`?
| satvikpendem wrote:
| I tried preload, it doesn't work as well as with NextJS
| which, yes, uses client side JS. But critically, the
| pages still work without JS if one so chooses. It's
| progressive enhancement which Astro does not yet have.
| colesantiago wrote:
| Why Astro instead of say, Svelte?
| FireInsight wrote:
| Astro is a metaframework that among others can use Svelte
| for both static and interactive components. Plain Svelte
| without a metaframework is not suitable for normal websites
| with multiple pages, but Astro is.
|
| As for Astro vs SvelteKit, I generally prefer Astro's
| approach to filesystem based routing (no +page etc.), I
| prefer it's MPA approach to the clientside routing
| SvelteKit and others use OOTB, I like that it's very
| tailored towards content and being an SSG (content
| collections, MD and MDX support ootb, currently
| experimental automatic image optimization), and the
| "integrations" are a huge time-saver. Some common ones you
| can add with `astro add`, and many others are just a quick
| config edit away. I recently built a pretty performant
| portfolio site with Astro in a single day using DecapCMS
| and UnoCSS, both as integrations, all the client had to do
| was accept the invite from Netlify Identity and start
| adding content to their site!
| password54321 wrote:
| No advantage if you just want to use Svelte when SvelteKit
| does everything Astro does and more while having less
| dependencies.
| FireInsight wrote:
| Well, dependency count is not the metric on which I base
| my tech decisions on. After all, you could do everything
| Svelte does with VanillaJS.
|
| I just prefer the DX of Astro and MPA routing instead of
| client-side.
| password54321 wrote:
| A fresh install of NextJS is roughly 150MB. You realise that's
| mostly code that all needs to work right?
| robertoandred wrote:
| Next doesn't ship 150MB of JavaScript to browsers...
| wg0 wrote:
| > A fresh install of NextJS is roughly 150MB. You realise
| that's mostly code that all needs to work right?
|
| Really??
| satvikpendem wrote:
| That's all on the backend so it doesn't really matter to me
| as long as no JS is sent on the frontend. For the benefits
| NextJS gives me, like TypeScript, I'm fine with that.
| e111077 wrote:
| In that case why not just SSR lit on the backend and send
| that? It sounds like an unfair criticism otherwise
| satvikpendem wrote:
| I have the full React framework and ecosystem if I so
| choose to use it. For example, I could use something like
| react-three-fiber to add 3D or Framer Motion to add
| animations yet fall back to not having those when JS is
| disabled. Sure you could do the same in Lit but those
| libraries aren't present or as robust as in React.
| robertoandred wrote:
| It's easy to add interactivity to a NextJS site when you
| need it.
| e111077 wrote:
| Likewise with Lit, but that is besides the criticism that
| he was making earlier
| meowtimemania wrote:
| An installation of chrome is roughly 1,500mb. You realize
| that's mostly code that all needs to work right?
| password54321 wrote:
| Yeah and an operating system has 10s of millions of lines
| of code. Does that mean everything else comes without a
| cost? Also point here is you got options for a much lighter
| framework, which you bluntly missed.
| silentprog wrote:
| chrome and nextjs do not share a use case. Whereas chrome
| is a web browser nextjs is a framework for building web
| applications.
| wsatb wrote:
| You can use lit components within Next, or within anything
| really. If you're building a single app, use what you're
| comfortable with. At my job, we're often creating components
| that need to be used within an increasing number of frameworks
| because every client is using something different. Having a
| custom element instead of needing to load React on every
| client's website is huge.
| satvikpendem wrote:
| Interesting, at the workplaces I've been at, we only used
| React, nothing else, in order to make the code-sharing
| problem much easier, as well as not have developers learning
| many different frameworks just to get work done.
| dmje wrote:
| So interesting, and refreshing, to see the tide gently turning in
| this direction :-)
| 11235813213455 wrote:
| Where is preact?
| adamzochowski wrote:
| I don't think preact is part of the "progressive enhance html"
|
| Progressive enhance HTML means whatever backend you use, it
| spits out html, and the HTML is rendered without Javascript.
| Preact fails this.
|
| The libraries are meant to progressively enhance html by
| replacing or enhancing certain actions with small javascript.
| For example, with htmx, usually clicking on html link would
| load complete page, but with clever htmx directive, the link
| onclick will only load/replace what is needed.
|
| Think of progressive enhance html as html first. As the page
| working even if javascript is disabled.
| examplary_cable wrote:
| Awesome list!
|
| I love that the cognitive overhead for web apps now is so great
| many people are "returning to monke" and coding in simple
| HTML/CSS/JS haha.
|
| Question: Shouldn't the items be in the row so I can see all of
| them at once? Why are the items in the columns? I'll open a issue
| (:
| FireInsight wrote:
| On mobile, I actually think it's pretty good like this. The
| names of the fields should stay visible when scrolling, though.
| Maybe this could be made reactive?
| adparadox wrote:
| >Shouldn't the items be in the row
|
| Maybe! I was messing with different UI approaches to relay this
| data and this made sense to me, but I'll see if switching to
| rows is more clear. Thanks for the idea!
| mNovak wrote:
| The column layout is basically impossible for me to
| meaningfully navigate on my laptop -- the scrollbar and
| descriptions don't both fit on the screen (appreciate the
| repeated titles at the bottom, but ultimately they don't say
| much)
| bmacho wrote:
| Don't you have horizontal scrolling on your laptop? Edge of
| the trackpad, or 2-3 fingers?
| examplary_cable wrote:
| > The column layout is basically impossible for me to
| meaningfully navigate
|
| Same. Somebody said it was done this way because of mobile.
| I'm not sure.
|
| It's just weird to see "items" horizontally and properties
| vertically. I'm usually familiar with:
|
| prop | prop | prop
|
| item | value| value
|
| item2| value| value
| robertoandred wrote:
| None of these are simple HTML/CSS/JS.
| examplary_cable wrote:
| It's part of the new modern WebDev semantical lexicon:
|
| !React = HTML/CSS/JS
|
| -\\_(tsu)_/-
| Blackthorn wrote:
| Htmx kinda is. I don't really know alpine but the GitHub docs
| remind me a bit of jQuery plugins.
| nathias wrote:
| do not use lit and webcomponents under any circumstances, please
| markhesketh wrote:
| Why not?
| nathias wrote:
| It sucks so much its unreal, forces OOP JS, which causes
| extreme amounts of boiler plate code and mutation bugs,
| making a simple change becomes a one week task. I'm just
| doing a complete rewrite of a legacy codebase made with TS,
| webcomponents and lit into a modern framework, which is about
| the only sane thing to do with it.
| amadeuspagel wrote:
| The table is a bad format for this.
| [deleted]
| drschwabe wrote:
| Nice to see sprae on there it's handy when you want reactivity
| with minimal fuss.
|
| I would lobby for featuring Webreflection's uhtml it is a
| workhorse for me personally.
| adparadox wrote:
| Thanks for the recommendation! I'll add it to the list as soon
| as possible.
| DaiPlusPlus wrote:
| The bottom row of the table is "IE11 Compatible".
|
| ...IE11 hasn't been relevant on the public-web for at least a
| decade now, and I'm fairly sure it's now entirely gone from
| corporate/enterprise situations now too, given MS' even-more-
| aggressive-than-usual campaign to kill it off in Feburary of this
| year: https://www.cnet.com/tech/services-and-software/rip-
| internet...
|
| ...why is that there? It's weird - it's like saying iPhone 14 is
| not compatible with 30-pin dock-connectors.
| adparadox wrote:
| It's there because some libraries explicitly call it out as a
| benefit so I included it. The code is OSS
| (https://github.com/adamghill/unsuckjs.com) -- feel free to
| make a PR to be the change you want to see in the world.
| tylerrobinson wrote:
| Not true. There are still legacy use cases where IE11 is
| required for support in enterprise and regulated businesses.
| Ending soon? Hopefully. But not gone.
| SkyPuncher wrote:
| Healthcare. It's still used in Healthcare. Unfortunately.
| dheera wrote:
| Oh I've seen IE8 in healthcare.
| Zelphyr wrote:
| Sadly, that is a commentary on the quality and efficiency
| of the US healthcare system.
|
| Before I get an onslaught of downvotes: my wife is a Nurse
| Practitioner and her and literally every provider she knows
| that I have met agrees that our healthcare system is
| backwards, inefficient, and anything but caring for or
| about peoples health.
| daveoc64 wrote:
| Internet Explorer 11 is still supported in Windows Server 2022,
| which goes out of support in October 2031. It's also supported
| in Server 2016 and 2019.
|
| It's also supported in Windows 10 LTSC versions for large
| companies.
|
| IE 11 mode for Edge is also supported until at least 2029 on
| all currently in-support Windows operating systems.
|
| So it can be very relevant if you have legacy systems that
| still need to be maintained.
| Blackthorn wrote:
| It's good that I know what htmx is already, because that
| description is kinda bad it doesn't really describe what htmx
| actually does to progressively enhance html.
| FireInsight wrote:
| I get these for when your stack contains python/go/ruby and your
| page is SSR. But more recently I've just come to enjoy the full
| blown Javascript Framework. I use Svelte exclusively, and the
| bundle sizes aren't too large thanks to the compiler. I can write
| TS which is way more comfortable than JS or even Python or Go
| IMO.
| spankalee wrote:
| You can get small sizes, great DX, first-class TypeScript
| support, all without the compiler though.
| FireInsight wrote:
| But I like the compiler.
| tbeseda wrote:
| For the sake of a compiler? I'd rather not add complexity
| for complexity's sake. Or does it give you another
| advantage not mentioned above?
| PaulHoule wrote:
| Yep.
|
| Myself I am working with HTMX and thinking about how the back
| end framework changes to make the most of HTMX.
|
| For instance I have a screen that has a bunch of dropdown
| inputs that automatically post changes to the server when you
| flip them and sometimes the options change when you flip them.
| The dropdown is defined in a macro that can be used in a
| template or that can be directly sent to the server. HTMX also
| can update several things in one request: for instance when I
| add a new RSS feed to YOShInOn it has to (1) insert the item
| into the feed, (2) tear down a modal dialog, and (3) update the
| count of the number of feeds. You very much need a server-side
| framework that makes it routine to do all that.
| [deleted]
| vxNsr wrote:
| Cool idea! nice to see these all in one place.
|
| one suggestion, on non-ultrawide screens when you scroll you no
| longer see the left labels, would be cool to have them float when
| you start scrolling left so they're always visible.
| KennyBlanken wrote:
| > Zero-dependency, build-free framework for the artisanal web.
|
| It's extremely difficult to take anyone seriously when they claim
| their framework is for the "artisanal web."
| WinstonSmith84 wrote:
| Surprised to not see Qwik. It's probably more a framework than
| just a HTML enhancer, yet it fits very much in that philosophy of
| reducing JS to the very bare minimum
| xnx wrote:
| Great resource. I initially skipped clicking on this because I
| thought "UnsuckJS" was yet another JavaScript framework.
| smusamashah wrote:
| There should be another row that which of these can be included
| as a standalone javascript lib in html instead of requiring NPM.
| spankalee wrote:
| For Lit, you can use pre-bundled versions from a CDN:
| https://lit.dev/docs/getting-started/#use-bundles
| adparadox wrote:
| Not requiring NPM was one of my original requirements for
| anything on this list. All of these libraries should be
| available from HTML directly -- let me know or make a PR if
| that isn't the case.
| vxNsr wrote:
| Maybe you can add that somewhere in subtitle somehow? as it's
| not immediately clear
| adparadox wrote:
| Good idea! I'll add it to the subtitle.
| smusamashah wrote:
| I looked at the first one on the list "lit" and the very
| first thing it says on github is to install via npm.
| spankalee wrote:
| That's because the _vast_ majority of the JS ecosystem
| installs libraries via npm.
|
| We can't really put all of the different ways to use Lit on
| the front page, but we document how to use Lit from a CDN
| right on the getting started page:
| https://lit.dev/docs/getting-started/#use-bundles
| [deleted]
| robertoandred wrote:
| Which means any content would be rendered after page load,
| worsening performance compared to frameworks like Next.
| Zizizizz wrote:
| No it doesn't, for some of these at least you can render the
| page server side and the reactive components become reactive
| a bit later on, isn't that how next would work as well? It's
| a blend of server side and front end interactivity right?
| robertoandred wrote:
| You can't render server side if you only use the library in
| a client-side script tag.
| coreyp_1 wrote:
| It would be handy to see the license.
|
| It's becoming increasingly more dangerous to use anything in the
| GPL family for anything but the narrowest of use cases. It's to
| the point that, even now, if it's GPL I refuse to incorporate it,
| even in personal projects. And I'm not against open source...
| Everything I write is MIT.
| musicale wrote:
| What changed to make GPL more "dangerous" - and to whom?
|
| I was under the impression that nearly every Linux distro uses
| GPL code in the kernel and/or userland.
| coreyp_1 wrote:
| https://www.gnu.org/licenses/gpl-
| faq.en.html#SystemLibraryEx...
|
| The GPL carves out exceptions for the use of system
| libraries.
|
| But, as for the "dangerous" part:
|
| * I work in an industry in which software patents are
| required to survive. Personally, I hate software patents, but
| it _is_ a reality until the law changes. As such, the GPL
| invalidates patents, making anything GPL completely off
| limits. That means that I would not have a job, and then
| there would be fewer competitors in the marketplace, which
| would make prices rise considerably. Too bad, too, because we
| would donate back improvements that are general enough to
| benefit others. Rather, now we just use proprietary solutions
| wholly because GPL is a minefield for us.
|
| * I have personal projects. I write code that I want to use
| myself as well as allow others to use. I use MIT because GPL
| discourages that somewhat (the point above). I may want to
| use my personal projects commercially some day. MIT allows
| that; GPL makes it impossible. In other words, if I choose
| GPL today, I have poisoned that code from myself for the rest
| of my life.
|
| In short GPL is not "free" as in freedom, because it comes
| with strings attached. It's communist in philosophy, but I
| hesitate to say that because then everybody jumps to some *a
| priori* conclusion of what they are now convinced that I'm
| saying, without listening to what I'm actually saying.
|
| GPL says, in short, that the software is freely available for
| public use, but not for private use. (Yes, there are nuances
| to that, so much so (and so confusing) that most people
| either just ignore it, or say "IANAL...") It demands that
| 100% of the work of anyone in the future must be donated back
| to the collective for free. That is not freedom.
|
| Create as much GPL code as you like. I create MIT. You can
| use mine (and I'm happy for you to!), but I can't use yours
| because of the restrictions you put on it. We can let the
| future decide which is more "free".
| musicale wrote:
| > I work in an industry in which software patents are
| required to survive
|
| Thanks for the explanation! I wonder what the industry is
| (maybe finance or law or ??) It seems that in most of the
| tech industry software patents are primarily used as a war
| chest for large companies or for non-practicing entities
| focused on litigation. Usually execution is more important.
| openthc wrote:
| IIRC, it's not about private use but about distribution. We
| publish libraries under MIT, since other corporate users
| would very likely need to distribute those.
|
| But the higher-level Apps we publish under GPL, so that
| downstream is obligated to keep it open-source (but there
| is no obligation to submit a PR upstream).
|
| And there are more than a few companies that use our GPL
| stuff, internally and don't redistrubute and therefore
| don't have to make their internal modifications available
| under GPL -- because there is no distribution happening.
|
| I'm not a lawyer but our decision was informed by one who
| has prior experience in IP, licensing and specifically
| FOSS-style licenses.
| coreyp_1 wrote:
| Yes, distribution is the key.
|
| Suppose that my company has powerful video editing
| software that we sell (which is distribution). Consider
| that it has unique functionality and has taken a decade
| to develop by a team of developers, all of whom have
| salaries, insurance, retirement, etc. that need to be
| paid, otherwise the software would not exist. Proprietary
| code and profit are more than appropriate in this
| situation, as I believe that workers should reap the
| reward of their labor and investment.
|
| Now, suppose that a new feature is wanted. There is a
| project that provides that functionality, but it is
| licensed GPL. Can I use it?
|
| Absolutely not!
|
| Because, if I do, then I am obligated to release all of
| my source code in addition, because it integrates with
| the GPL code. It is financial suicide for my business to
| do so (which, btw, is a political preference for many of
| the GPL proponents). What will I do instead? I will
| probably just have my developer write our own version,
| adding in the extra features that we need.
|
| Contrast that with the MIT-licensed code. We can use it
| without fear, and we will probably even submit
| enhancements back to the project, simply because it makes
| our lives easier in the future for maintenance.
|
| GPL poisons downstream, simple as that.
|
| You are correct that there is no obligation to submit a
| PR upstream, but there is a requirement for my source
| code to be made available under the same GPL license. GPL
| is "infectious" (or "viral", take your pick of words).
|
| The funny thing is, I believe in freedom with software,
| but my interpretation of "free" is vastly different than
| the GPL interpretation of "free". And, as I said, I put
| my money where my mouth is... almost everything I write
| (except for my job) is MIT licensed code.
| BeefySwain wrote:
| Great list, I went ahead and added it to the bottom of my
| "Awesome" Python HTMX page: https://github.com/PyHAT-
| stack/awesome-python-htmx/tree/main
| recursivedoubts wrote:
| great list but needs https://unpoly.com, which is explicitly
| focused on progressive enhancement in a way that htmx is not
|
| yeah, it's bigger than most of the other libraries, but it does
| an absolutely excellent job on progressive enhancement
|
| source: i'm the creator of htmx
|
| edit: PR here: https://github.com/adamghill/unsuckjs.com/pull/13
| canadiantim wrote:
| Looks great, love the list so thanks for putting it together.
|
| In an ideal world your table would also have a first commit row
| that way I can better compare how well established each library
| is (GitHub stars mostly does this but date of first commit would
| help give sense of momentum too)
| adparadox wrote:
| I didn't post the site to HN, but I did create it. Adding the
| first commit is an interesting idea. Or some way to measure
| longevity (i.e. how long has the library been worked on). I'll
| try to figure out a good way to do that or if you put up a PR I
| will take a look at it:
| https://github.com/adamghill/unsuckjs.com.
| noizejoy wrote:
| Nice idea! I was just surprised to see the table rows and
| columns opposite of what I'm used to seeing in lists where
| one dimension is more likely to grow much longer than the
| other.
|
| i.e. I would have expected the libraries as rows, rather than
| columns. More like such lists are typically done in
| Wikipedia.
| adparadox wrote:
| It definitely might make more sense that way! I was playing
| around with different ways to display the data and landed
| on this approach even though maybe it's a little clunky. I
| could flip it and see how it feels -- thanks for the
| suggestion!
| ilrwbwrkhv wrote:
| What's great about Mithril is that is squeezes a router in that
| tiny size.
|
| None of the others have that I imagine. If you do need a full
| blown single page app, Mithril takes care of it all.
| nullwarp wrote:
| Yes! I don't think Mithril gets enough attention. It's my go to
| JS framework when I need more than Vanilla JS but don't need
| something like React.
| ilrwbwrkhv wrote:
| Why would you ever need React over Mithril?
| jrajav wrote:
| The ecosystem, if you're building a product of a certain
| complexity and can't afford writing large, complex, un-
| battle-tested views from scratch.
| ilrwbwrkhv wrote:
| What's an example of a large, complex, unbattle tested
| view?
| skrebbel wrote:
| Colleagues, ecosystem
| slmjkdbtl wrote:
| Did you ever run into performance problem with Mithril? I
| like how simple it is to use but the idea to run / diff the
| entire component tree on every user interaction kinda scares
| me
| keb_ wrote:
| I've been using Mithril since 2017 or so. The answer is:
| no. To give you a production example, Mithril is used in
| the video game Guild Wars 2 to render the marketplace in-
| game and the lead web engineer reported that it was
| performant enough for their use-case [1]. (I've played
| Guild Wars 2 and never noticed any issues with it, so good
| enough for me).
|
| In most cases, your bottleneck won't be Mithril (or React
| for that matter), but instead what expensive computations
| you're doing in your components. While React has
| React.memo, Mithril has the `onbeforeupdate` hook [2] you
| can use to memoize components if you need it.
|
| [1] https://carlmungazi.github.io/sourcecodeadventures/post
| s/pat... [2] https://mithril.js.org/lifecycle-
| methods.html#avoid-prematur...
| endofreach wrote:
| Haven't heard of it yet. Sounds exactly like what i needed
| many times lately. Thanks!
| timlwhite wrote:
| Great list. Site is clear and easy to read!
| moozeek wrote:
| unpoly.com would fit this list (can't PR on mobile)
| adparadox wrote:
| Nice, thanks for reminding me of unpoly! I will add it soon.
| cassiogo wrote:
| Stimulus would probably also fit the list
| Danjoe4 wrote:
| You can do a lot with Django templates. Sprinkle in any of these
| and I find it unlikely you'll be reaching for React. Although if
| you have lots of React experience I am a believer in "use what
| you know". Tool familiarity > trimming dependencies
| LordDragonfang wrote:
| Django templates are nice, but fall flat if you want to do
| anything remotely dynamic with your model. The fact that you
| need to define custom template tags for things as simple as
| getting an attribute from a dict in your model is a real pain
| point.
| no_wizard wrote:
| If you use the Jinja bridge you'll have an easier time all
| around I think
| LikeAnElephant wrote:
| Completely agree. I honestly always thought Django
| Templates mostly were Jinja2, until I looked more closely
| and realized how wrong I was.
|
| Since then I exclusively use Jinja2 in my Django apps and
| my life is so much better.
| endofreach wrote:
| I love that so many here share the sentiment. I never liked
| reactjs. Started to use vue for almost all frontend needs. But
| even knowing what i do, it's way too much tooling just to get
| started.
|
| Now i despise all the frameworks & libraries and go vanilla 9/10.
| acaloiar wrote:
| Great list!
|
| To the maintainer: Cloudflare is mangling your HTML and redacting
| lit's `@version` with `[email protected]`.
| adparadox wrote:
| Yikes! Thanks for letting me know. I'll fix that asap.
| l5870uoo9y wrote:
| Lightweight is good, but above all I want a productive JS
| library. Perhaps I should just make the switch from React to
| Svelte.
| samwillis wrote:
| This is a brilliant list, I'm a particular fan of HTMX and
| Alpine.js.
|
| The move back towards small dependancy free JS libs, in
| combination with modern JS ES Modules, is absolutely brilliant.
|
| I learnt web dev back in the late 90s by doing "view source", and
| was still learning about new things that way well over a decade
| later. If we can move back towards that, by not having a build
| step, it will be amazing for new devs starting out and learning
| new things.
|
| Obviously larger apps, with many dependancies, will require all
| the incredible work thats gone into modern JS tooling, but for so
| many simpler (and not so simple) sites this process really does
| make sense.
| sureglymop wrote:
| If you use htmx what backend technology do you choose?
| acaloiar wrote:
| The beauty of htmx is that it doesn't matter what you use on
| the backend.
|
| Literally anything that'll render HTML will suffice. Even
| static HTML files on a web server will do. No need for an
| application server at all if you're clever and your needs are
| simple.
| sureglymop wrote:
| What if I want the website to work even when JavaScript is
| not turned on? I'd need a backend server and some frontend
| logic handling that case.
| kitsunesoba wrote:
| > I learnt web dev back in the late 90s by doing "view source",
| and was still learning about new things that way well over a
| decade later. If we can move back towards that, by not having a
| build step, it will be amazing for new devs starting out and
| learning new things.
|
| Same here, and I couldn't agree more. Had minified library soup
| with dynamic page content been the norm back then it would've
| been much harder to get started, and there's a high chance I
| would've just given up somewhere in the process.
|
| Having a build step also increases activation energy and
| friction which impedes the sort of in-the-moment tinkering that
| often sparks projects.
| jabart wrote:
| Irony is that javascript handlers on elements were frowned
| upon in 90s/00s because of separate of concerns that HTML
| should be HTML and JS should attach it's events in a separate
| file. Now all of these libraries have an onclick that mirrors
| those original JS event handlers in the same html with no
| separation!
| samwillis wrote:
| Only thing missing is inlining your css styles on each
| element, only a mad man would try that though... [cough]...
| https://github.com/samwillis/x-style
| endofreach wrote:
| Or, tailwindcss...
| dheera wrote:
| > Having a build step also increases activation energy and
| friction
|
| Yes this! As an interpreted language it should not need a
| build step. Every project should be git
| clone https://github.com/user/foo && cd foo && google-chrome
| index.html
| Zelphyr wrote:
| You guys are singing the song of my people. For years I've
| been confounded at the idea that we need to be
| building/compiling interpreted code.
|
| And the tooling... my God! I know this makes me sound like
| an old man (because I am) but, it used to be all I needed
| was an editor, an FTP client, and a browser. write-upload-
| refresh. Today, I find VS Code, `git push`, and a browser
| still serves me very well.
| nektro wrote:
| rows and columns should be switched
| kurokawad wrote:
| am i the only one who finds weird the table distribution? like
| having the libs on the horizontal axis
| aarpmcgee wrote:
| Perhaps Crank.js[1] would belong on this list
|
| [1]: https://crank.js.org/
| adparadox wrote:
| Thanks for the recommendation -- looking through the docs, it
| seems like it fits! I'll add it in a few or feel free to make a
| PR.
___________________________________________________________________
(page generated 2023-06-15 23:00 UTC)