[HN Gopher] AlpineJS
___________________________________________________________________
AlpineJS
Author : monkey_monkey
Score : 74 points
Date : 2021-06-11 07:40 UTC (15 hours ago)
(HTM) web link (alpinejs.dev)
(TXT) w3m dump (alpinejs.dev)
| tutfbhuf wrote:
| In a few year we are back at jQuery.
| yunohn wrote:
| This looks a lot like Vue. Is there a comparison somewhere maybe?
| werdnapk wrote:
| I'd say the big difference is alpinejs uses the DOM and not a
| VDOM like vuejs, but alpinejs is meant for smaller use cases.
| monkey_monkey wrote:
| AlpineJS was inspired by Vue's syntax. It's meant to be a much
| lighter and smaller 'framework' that sits in the space between
| vanilla JS and Vue/React/Svelte.
|
| Not sure there are any direct comparison tables, but this might
| help:
|
| https://medium.com/@wearethreebears/a-comparison-of-a-simple...
| sometimesshit wrote:
| The JS ecosystem always want to start simple tools, but they
| forget that every simple tool has become complex so reinvent the
| wheel again.
|
| You see that programs written in C (Simple language) tend to be
| more complex than one written in C++
| MattIPv4 wrote:
| This looks like an awesome candidate for being the perfect
| balance on a project that's too small for Vue or React, but too
| big to want to write all the logic by hand.
| cute_boi wrote:
| Vue started with same simplicity but now its big. People were
| saying same it looks perfect balance on small project.
|
| Looks like it is inevitable in Javascript ecosystem to reinvent
| the wheel again and again.
| string wrote:
| Isn't Vue like 13kb? By what measure is that considered big?
| ddek wrote:
| The fundamental difference is that vue and react uses a
| virtual DOM, which alpine does not.
|
| This is important when you consider _why_ alpine exists -
| IIRC, it was created with LiveWire in mind. In LiveWire, the
| changes to state run through websockets to the server rather
| than being held in JS. In this situation you can 't use vue
| or react, because v-dom frameworks need exclusive control
| over the physical dom.
| mixedCase wrote:
| Vue 1 did not use a VDOM
| tpetry wrote:
| LiveWire state changes are done by simple ajax calls, no
| websockets are used.
| ipaddr wrote:
| Why not use jQuery?
| BareNakedCoder wrote:
| The website being announced in this post, alpinejs.dev, is new
| for V3 of AlpineJS which was launched just yesterday. I've been
| using it since V1 and I can say it doesn't just look like but
| really _is_ a perfect balance for projects too small for Vue or
| React but to big for VanillaJS. I would also argue that small
| and simple is better for most websites.
| aitchnyu wrote:
| What kind of page is between VanillaJs and Vue?
| BareNakedCoder wrote:
| Let me take a stab at explaining how AlpineJS is different.
| First, let me talk about the two "modes" of front-end frameworks,
| what I'll call: "FPC" and "Sprinkled":
|
| FPC or Full Page Components: the original HTML source (as seen
| from "view page source", not "inspect") usually contains a tag
| like `<div id="app"></div>` which simply serves as the place
| where the FPC-oriented framework inserts its magic. All the magic
| happens in the JS (possibly generated by compiling from something
| else like JSX or a component DSL). Note that a FPC is not
| necessarily a SPA; you could have multiple pages with one FPC
| each.
|
| Sprinkled: the original HTML source has the framework's tags,
| attributes, and/or other markup sprinkled throughout it. The
| framework will search for these sprinklings in the original HTML
| and do as they direct. Usually the framework only looks within an
| encapsulating tag so the original HTML might have something like
| `<div id="app">...more HTML with sprinklies...</div>`.
|
| React and Svelte are FPC frameworks. All the exciting stuff is in
| the code: JS, JSX, or a JS-like component DSL.
|
| VueJS can be used in multiple modes. It can be used in pure FPC
| mode. It can be used in hybrid mode: with both components and
| sprinklies in the original HTML, including sprinklies between a
| component's start and end tag. And it can (almost) be used in
| pure sprinkled-mode. I say "almost" because you do need some JS
| code to define the mount point and the data. (VueJS also has two
| sub-modes for components: compiled client-side and pre-compiled
| during the build. The later requires a more complex build step).
|
| AlpineJS is (mostly) for pure sprinkled-mode. It is easy to write
| non-trivial function with no JS at all, other than loading
| AlpineJS itself from a CDN. On page load, AlpineJS will
| automatically do the needful; no bootstrapping JS is required.
| When re-use and/or complexity requires it, you can move some or
| much of the code from HTML to your JS. For even more complex
| stuff, the new plugin ability in V3 of AlpineJS makes adding your
| own directives/attributes or magic variables/functions easy. This
| extra ability in V3 just means although you can do 80% with no or
| very little JS, you still have room to grow for the other 18-20%.
|
| AlpineJS is great for and focuses on the needs of simpler apps.
| And most of the apps we develop _should_ ... _be_ ... _SIMPLE_.
| gervwyk wrote:
| Excellent comment and breakdown! 100% agree most apps should be
| simple, if you think / design on a "page" level, most apps
| actually are simple.
|
| SPA easily confuse designers and often users, but both SPA and
| multi-page apps (MPA) has its place..
| Scarbutt wrote:
| FPC doesn't sound right since you can have a react component
| for just a single part of a page, it doesn't necessarily need
| to take control of the whole page.
| BareNakedCoder wrote:
| Yes of course the components are usually not the entire page;
| don't take the terms too literally. I'm still searching for
| the best name for these modes ("sprinkled" isn't quite right
| either). Although "full body component" or "big section
| component" might be a little better, I suggestion not missing
| the underlying idea or point due to imperfect terms.
| mands wrote:
| Very true, and is a highly useful tool to add interactive
| content to a section of an MPA - React used in this way,
| without requiring a state library and everything else is
| actually quite nice to work with.
| geenat wrote:
| Similar to https://htmx.org/
| felipeccastro wrote:
| It seems a lot more similar to Vue.js than htmx.
| recursivedoubts wrote:
| I'd say alpine is more front end oriented and better compared
| with vue.js or maybe react. htmx is for driving server
| interactions via dom events, within the hypermedia network
| model.
|
| The htmx and alpine pair very well together, we have a lot of
| folks on the htmx discord who are passionate about the
| htmx/alpine/tailwinds, so you can do all your work in HTML
| (locality of behavior[1]).
|
| The htmx sibling project, hyperscript (https://hyperscript.org)
| would be a more direct comparison with alpine, but it isn't
| reactive at all, so it would be better thought of as a jQuery
| replacement for light front end scripting.
|
| [1] - https://htmx.org/essays/locality-of-behaviour/
| mands wrote:
| Agreed, we're using both htmx and alpine (along with
| tailwind) for a Django MPA and they pair together very well -
| htmx for new server rendered content, and alpine for purely
| FE-related interactions.
| Scarbutt wrote:
| Have you tried the https://hotwire.dev/ stuff? If so why
| did you pick htmx over it?
| mands wrote:
| Not yet, I was unsure how stable the Hotwire support for
| Django is. Another approach I'm quite excited by is
| django-unicorn (https://www.django-unicorn.com/), which
| is an implementation of LiveWire / LiveView and overlaps
| with Hotwire in some respects.
| uptime wrote:
| I am tempted to see how far I can get with an IBM carbon design
| component set using this.
| ducharmdev wrote:
| After hesitating with Tailwind I did come around to loving it,
| but I've had a much harder time getting over my initial
| impressions of Alpine. I recognize that one, it targets a very
| specific type of website, and two, it's easy to let subjective
| feelings about what makes for readable & maintainable code get in
| the way of an unbiased take on the framework. But writing
| JavaScript in strings is unappealing to me, even for server-side
| sites that just need some sprinkling.
|
| Some questions that come to mind that would sway me one way or
| another:
|
| - How is the tooling and debugging experience?
|
| - Do you get intellisense with the VSCode extension within x-for,
| x-show, etc. expressions?
|
| - Can you easily set breakpoints in devtools and step through
| your code?
|
| - In reference to the issue below, how susceptible would I be to
| XSS attacks in using this framework?
|
| https://github.com/alpinejs/alpine/issues/237#issue-57653341...
| stefanfisk wrote:
| The link seems to be dead, this was the most recent copy I
| could find:
| https://web.archive.org/web/20210529012746/https://github.co...
| ducharmdev wrote:
| Weird, not sure why that happened - maybe it's just cached
| for me? But yeah that's the thread.
| stefanfisk wrote:
| This seems to be the reason
| https://github.com/alpinejs/alpine/discussions/1423
| adamredwoods wrote:
| Also, I think conditional logic in HTML attributes is difficult
| to read. I just prefer having logic separate from html layout.
___________________________________________________________________
(page generated 2021-06-11 23:02 UTC)