3 ms·

Pretty much all mainstream frontend libraries have moved away from dom based templating (or augmenting dynamic behavior through attributes) for good reason. It

by lf-non 7y ago

Pretty much all mainstream frontend libraries have moved away from dom based templating (or augmenting dynamic behavior through attributes) for good reason. It simply becomes unmaintainable for anything more complex than basic interactivity. This approach can't leverage type systems for javascript (like TS, BS, flow etc.) It is easy to end up with mistakes that don't surface as javascript errors and are swallowed completely. You hit weird quirks when browser injects additional nodes (eg. tbody in tables) or restructures invalid markup (eg. div inside p). Ostensibly this approach would help with progressive enhancement, but too often careless usage results in flashes of broken UI which would then fix themselves when javascript kicks in. Then you need hacks to circumvent those with hacks like ng-cloak. Also, in an ideal world this would help with handoff when working with web-designers who are familiar with only html/css but that rarely happens in practice. Every time a web-designer rearranges things in the dom hierarchy the parent-child associations break and that again needs comprehensive testing. Having worked with applications written using knockoutjs as well angular 1 (both of which used similar approaches) which organically grew over multiple years and (to put gently) didn't age gracefully, I wouldn't recommend this approach to anyone. If you can't (or don't want to) go down the road of a full SPA but do want to build interactive applications with non-trivial amounts of javascript, lit-element [1], Vue [2], Strudel [3] and SPF [4] are much better solutions. [1] https://lit-element.polymer-project.org/ https://lit-element.polymer-project.org/ [2] https://vuejs.org/ https://vuejs.org/ [3] https://strudeljs.org/ https://strudeljs.org/ [4] https://github.com/youtube/spfjs https://github.com/youtube/spfjs

rolae 7y ago
Alpine.js really was created for javascript sprinkles, where even vue.js might be overkill. For example, if you have an app, but you need to have dropdowns and modals. Then something like alpine.js can be nice. So it is actually not intended for things more complex than basic interactivity. And what you build with it, should be simple enough you don't need any type system. For people interested, there is a good episode on FullStackRadio on the topic http://www.fullstackradio.com/132 http://www.fullstackradio.com/132
- kreetx 7y ago
  What about Svelte as a light-weight framework -- it compiles itself out (there is no library included in the final app).
  - ratww 7y ago
    Svelte is great but requires a compilation step, which is probably the kind of complexity that potential users of Alpine.js are trying to avoid.
- lf-non 7y ago
  Thanks for clarifying on this. This was not the message I inferred by browsing through the README and the examples. The wording in the README says that Alpine "offers you the reactive and declarative nature of big frameworks like Vue or React at a much lower cost" which seemed to indicate that it was targeting a similar audience as those libraries. The intro also didn't really mention anything about it being suited primarily for applications without needing complex composition of logic or any indication of what the authors feel about how big is too big to be suitable for alpine.
mstade 7y ago
I'm not the author and I've never used this library, but I think your comment is unnecessarily dismissive anyway. You're not necessarily wrong, but I feel there's ample room in the space between wanting to hack something together and built according to this week's best practices. Seems to me this tool sits squarely in that first category, enabling rapid prototyping at a lower cost, while still being flexible enough to allow for a wide range of capabilities. I don't get the feeling at all from the introduction that this is meant to compete with Vue, React, Angular et al. but rather be a complement – the tool to reach for when you have an idea and want to hash it out without being encumbered by process. For what it's worth, I work like this all the time. I have a collection of simple utility functions that I'll include in an html file – F5 is my build process. It's useless for building anything serious, that's when I reach for more structure. I can definitely see something like Alpine replace my homegrown tools for this.
ecmascript 7y ago
Wow, such an elitist comment. So you mean endless webpack configurations with tons of javascript libs are more maintainable? The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. I am using lit-html myself and like it, but it's not necessarily better than dom based templating imo. For some things I believe it to be worse. Right now I am on a slow and shaky connection and will be for a while, sites like HN which is a classic multi page app without any javascript loads fast and works great. Pages like youtube and the new reddit (old works great) works like total shite.
- eyelidlessness 7y ago
  Wow, you responded to a pretty thoughtful post with insults, hyperbole and strawmen, and FUD. > So you mean endless webpack configurations with tons of javascript libs are more maintainable? I don't think that's what the comment claimed at all. However, I think the answer to the less hyperbolic version of this question is: maybe. It's pretty orthogonal to the discussion though. > The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? I have no idea where you got the idea that this is some defining feature of SPAs, but this is something that can happen with jQuery spaghetti and it's something that almost never happens with React. > You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. So... I don't know how you're doing this, and admittedly I was away from frontend dev for a few years so I'm sure I missed some pain in the meantime, but I recently started a project with Next.js, and... this is the exact opposite of my experience. SSR is super fast, it only happens once, you get static HTML output and your site is basically as fast as your web server/CDN. All of this without any config.
jmull 7y ago
No general purpose framework (or language or process or runtime model) will prevent you from making a project unmaintainable over time if you don't have a design and otherwise keep things organized. It's inherent in the flexibility that a general-purpose framework provides. Conversely, if you stay organized, you can maintain long lived complex systems based using frameworks of a variety of styles. I can assure you there are plenty of old DOM-template-based systems around.
spankalee 7y ago
Hi. Author ot lit-html here. While for things like full apps, complex components, or any project leaning heavily on type-checking, I obviously mostly agree with you... I'm very intrigued by projects like this and Intercooler.js. I think there's a lot to like here. JavaScript is a great place to merge data and DOM because data is so much easier to work with in JS than HTML, but if you're starting from HTML already and just want to incrementally add a bit of interactivity these approaches are really appealing. I think we should strive to make the complexity and learning curves as smooth as possible from static pages to full apps. These do that. lit-html and React do in some ways (you can almost copy and paste HTML into JS and have it work) so long as you're very comfortable in JS to begin with. I've experimented with plain HTML dialects of lit-html and hope to get back to that so that we can have templates-in-HTML and templates-in-JS share semantics and implementation.

by lf-non 7y ago

rolae 7y ago

Alpine.js really was created for javascript sprinkles, where even vue.js might be overkill. For example, if you have an app, but you need to have dropdowns and modals. Then something like alpine.js can be nice. So it is actually not intended for things more complex than basic interactivity. And what you build with it, should be simple enough you don't need any type system. For people interested, there is a good episode on FullStackRadio on the topic http://www.fullstackradio.com/132 http://www.fullstackradio.com/132

kreetx 7y ago
What about Svelte as a light-weight framework -- it compiles itself out (there is no library included in the final app).
- ratww 7y ago
  Svelte is great but requires a compilation step, which is probably the kind of complexity that potential users of Alpine.js are trying to avoid.
lf-non 7y ago
Thanks for clarifying on this. This was not the message I inferred by browsing through the README and the examples. The wording in the README says that Alpine "offers you the reactive and declarative nature of big frameworks like Vue or React at a much lower cost" which seemed to indicate that it was targeting a similar audience as those libraries. The intro also didn't really mention anything about it being suited primarily for applications without needing complex composition of logic or any indication of what the authors feel about how big is too big to be suitable for alpine.

mstade 7y ago

I'm not the author and I've never used this library, but I think your comment is unnecessarily dismissive anyway. You're not necessarily wrong, but I feel there's ample room in the space between wanting to hack something together and built according to this week's best practices. Seems to me this tool sits squarely in that first category, enabling rapid prototyping at a lower cost, while still being flexible enough to allow for a wide range of capabilities. I don't get the feeling at all from the introduction that this is meant to compete with Vue, React, Angular et al. but rather be a complement – the tool to reach for when you have an idea and want to hash it out without being encumbered by process. For what it's worth, I work like this all the time. I have a collection of simple utility functions that I'll include in an html file – F5 is my build process. It's useless for building anything serious, that's when I reach for more structure. I can definitely see something like Alpine replace my homegrown tools for this.

ecmascript 7y ago

Wow, such an elitist comment. So you mean endless webpack configurations with tons of javascript libs are more maintainable? The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. I am using lit-html myself and like it, but it's not necessarily better than dom based templating imo. For some things I believe it to be worse. Right now I am on a slow and shaky connection and will be for a while, sites like HN which is a classic multi page app without any javascript loads fast and works great. Pages like youtube and the new reddit (old works great) works like total shite.

eyelidlessness 7y ago
Wow, you responded to a pretty thoughtful post with insults, hyperbole and strawmen, and FUD. > So you mean endless webpack configurations with tons of javascript libs are more maintainable? I don't think that's what the comment claimed at all. However, I think the answer to the less hyperbolic version of this question is: maybe. It's pretty orthogonal to the discussion though. > The reverse can be said for SPA-like frontends in which you put forward as the better choice. It's unnecessarily complex and one error and the whole page becomes unresponsive and crashes. How many times haven't we all clicked on a button and because the developer didn't handle some error in a good way the entire page must be reloaded and all state is lost? I have no idea where you got the idea that this is some defining feature of SPAs, but this is something that can happen with jQuery spaghetti and it's something that almost never happens with React. > You want a good placement on search engines? Well, good luck chuck. Unless you utilize server rendered pages you are out of luck basically. This is also a big hassle. Also server rendered pages are usually slow as fuck compared to a normal multi page app. So... I don't know how you're doing this, and admittedly I was away from frontend dev for a few years so I'm sure I missed some pain in the meantime, but I recently started a project with Next.js, and... this is the exact opposite of my experience. SSR is super fast, it only happens once, you get static HTML output and your site is basically as fast as your web server/CDN. All of this without any config.

jmull 7y ago

No general purpose framework (or language or process or runtime model) will prevent you from making a project unmaintainable over time if you don't have a design and otherwise keep things organized. It's inherent in the flexibility that a general-purpose framework provides. Conversely, if you stay organized, you can maintain long lived complex systems based using frameworks of a variety of styles. I can assure you there are plenty of old DOM-template-based systems around.

spankalee 7y ago

Hi. Author ot lit-html here. While for things like full apps, complex components, or any project leaning heavily on type-checking, I obviously mostly agree with you... I'm very intrigued by projects like this and Intercooler.js. I think there's a lot to like here. JavaScript is a great place to merge data and DOM because data is so much easier to work with in JS than HTML, but if you're starting from HTML already and just want to incrementally add a bit of interactivity these approaches are really appealing. I think we should strive to make the complexity and learning curves as smooth as possible from static pages to full apps. These do that. lit-html and React do in some ways (you can almost copy and paste HTML into JS and have it work) so long as you're very comfortable in JS to begin with. I've experimented with plain HTML dialects of lit-html and hope to get back to that so that we can have templates-in-HTML and templates-in-JS share semantics and implementation.