8 ms·

>The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. This isn't wrong, but going one level down, this i

>The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. This isn't wrong, but going one level down, this is how it bites you: - The imperative DOM api just suuuucks. Please try it for yourself to see. Even if you're writing a very limited bit of reactivity in your app, you will be forced to invent your own declarative framework very soon. - Very hard to make reusable components (at least before webcomponents, which I haven't used personally) If you want to stay close to vanilla, I recommend one of the following solutions: 1) https://htmx.org/ https://htmx.org/ 2) https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript 3) https://github.com/vuejs/petite-vue https://github.com/vuejs/petite-vue

soulofmischief 4y ago
If you like hyperscript, it's worth checking out mithril. https://mithril.js.org https://mithril.js.org
- gzer0 4y ago
  What about adamant? I heard that is the next level above mithril.
  - Legion 4y ago
    This sequence of comments is the JS ecosystem in a nutshell. Hear about something new, then immediately hear about its multiple successors/replacements.
    - soulofmischief 4y ago
      Mithril uses hyperscript as its foundation, it builds upon it as opposed to replacing/succeeding it :) Check it out, it's the kind of framework you pick and stick with for 20+ years. Zero bullshit compared to its peers.
      - ovao 4y ago
        And in a month or two the new hotness’ll be something else built on top of Mithril, or something “like Mithril but a bit different”. Good frameworks are good, and I love a good hobby project in some new hotness, but ecosystems, developer tooling, backward compatibility guarantees, large corporate backing, developer conferences, and community are what makes frameworks adoptable are what makes them stick.
        soulofmischief 4y ago
        Mithril has been around for 7 years. How old does it need to be before it's not "the new hotness"? Just because you haven't heard of something doesn't mean it's new, and it would behoove you to not immediately dismiss things that are new to you as things that are new in general. Your heuristic that a large ecosystem is what makes a framework good precludes you from ever again touching any new project. It's a short-sighted approach. At some point, you have to grow up as a developer and try to understand the real world problems that modern declarative web frameworks have solved. I stated that mithril will be my tool of choice for hopefully 20+ years, so your framing this as me getting lost in the new hotness doesn't even hold up. This is about real tools, which are useful today and tomorrow, and which have slow API churn to facilitate longevity. It's just a bonus that mithril is also faster and far more terse than React and friends.
    - raffraffraff 4y ago
      Lol, to prove you're point even harder, your comment is not even the at the end of the list of successors/replacements.
  - testplzignore 4y ago
    Nah. orichalcum.js is the hot new thing. It's a fork of adamant with support for monads, generics, and native blockchain integration.
    - charrondev 4y ago
      For anyone wondering what are these new JS frameworks: - mithril.js is an actual web framework. I’ve not tried it myself. - the next comment referenced adamant as being better. There is an MMORPG called RuneScape in which weapons and armour can be smithed of various metals, and treats adamant as 1 tier better than mithril. - similarly orichalcum is a couple of tiers above mithril.
  - soulofmischief 4y ago
    Don't give anyone any ideas!
nisegami 4y ago
Working on a project right now with htmx, hyperscript, tailwindcss (all new to me) and it's impressive how low the cognitive load is in a lot of cases.
- gremlinsinc 4y ago
  htmx and tailwindcss are great but hyperscript looks crazy evil. I hate mixing html and js though, even jsx rubs me wrong. This looks like pug/slim and other templating to remove xml from pages but instead of just something like body p | This is a test of the text block. you get something like: var h = require('hyperscript') h('p', "This is a test of the text block") and I want to know why would you want the entire page in JS objects? personally I like the way htmx, vue, alpinejs do things with basically embedding actions/events on the existing xml structures. It's more an abstraction over existing html, than totally redoing or replacing html. That seems like a case of 'we knew we could do it, but never stopped to ask ourselves if we should' ... Turbolinks + stimulusjs is also another great stack for mini-frontend frameworks. Also super fast.. turbolinks can go well w/ anything though including htmx or alpinejs, but there's a lot of tutorials on stimulus+turbolinks.
  - nisegami 4y ago
    When I first saw hyperscript in the HTMX docs (they're made by the same person), it also struck me as an unholy abomination. But in practice, it's been pretty nifty. It provides a concise way to perform common actions that adheres to the idea of locality of behavior that HTMX and Tailwind both offer as well. I still think I might come to regret it, but it doesn't seem like it would be hard to rip it out and replace it with plain JS. For example, I'm mostly using it to do stuff like: on click toggle .hidden on .modal
    - toastercat 4y ago
      I believe you are talking about this hyperscript: https://hyperscript.org/ https://hyperscript.org/ Whereas the parent post is talking about: https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript Unfortunately, the creator of https://hyperscript.org/ https://hyperscript.org/ hijacked the name even when the term "hyperscript" is still used to refer to dominictarr's project and the `h('p', 'hello world') API of declaring templates in JavaScript (as seen in React, Preact, Mithril, etc.).
athrowaway3z 4y ago
I'll throw in https://caldom.org/ https://caldom.org/
amadeuspagel 4y ago
If you want to stay close to vanilla, I'd recommend lit: https://lit.dev/ https://lit.dev/
- BenoitEssiambre 4y ago
  I sometimes use an even closer to vanilla option based on just the Lit templating engine: https://benoitessiambre.com/vanilla.html https://benoitessiambre.com/vanilla.html
- Existenceblinks 4y ago
  Or https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml
BenoitEssiambre 4y ago
On top of these options, with modern browsers, it's quite easy to make reactive components in plain vanilla ( https://benoitessiambre.com/vanilla.html https://benoitessiambre.com/vanilla.html ). I find this approach very usable for smaller simpler projects where you don't need a full framework.
tgflynn 4y ago
I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ https://tgflynn.github.io/AlgoVis/ (github link: https://github.com/tgflynn/AlgoVis https://github.com/tgflynn/AlgoVis). The fact that this works, didn't take long to write (though I'm very much still learning this stuff) and is very fast leads me to question your statement that "The imperative DOM api just sucks".
- guilherme-puida 4y ago
  > simple demo app I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.
  - tgflynn 4y ago
    All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?
    - arbitrage 4y ago
      so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time. as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect. beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it. you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth. in the end, frameworks aide results beyond the ability of a single coder to implement on their own.
    - guilherme-puida 4y ago
      If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?
dxchester 4y ago
We developed El to be as minimal as possible, while still solving the problem of keeping state and interface in sync: https://github.com/frameable/el https://github.com/frameable/el It's just ~150 lines / 2kb, and leverages existing browser functionality to accomplish most of the hard parts. Has observability, reactive templates, scoped CSS, no need for a build process, etc.
- acqbu 4y ago
  This looks very interesting, I'll give it a go
- hilti 4y ago
  Interesting - looks pretty similar to Framework7 components https://framework7.io/docs/router-component https://framework7.io/docs/router-component
- vinibrito 4y ago
  I have been reading into it for some time now, since I do not want to dive into a big framework with a huge learning curve for a side project that I have. I just feel afraid to run into a problem that has already been solved in a big framework and get stuck.
gremlinsinc 4y ago
wow thanks for this, I'm fullstack with tons of vue exp but have been 90% backend for the past 6 months or had my head in a hole or something -- this is the first i've heard of petite-vue. Looks pretty cool, maybe somewhat akin to alpinejs, which I have been using more lately also. I'd also put that on the list as it's a nice framework with a bit less footprint than vue/react etc.
sdwr 4y ago
Vue is right in the sweet spot for me doing solo stuff. Get all the reactive stuff with minimal additional complexity.
- datavirtue 4y ago
  I was about to use Vue for a new project but got pulled by the siren call of svelte. The other popular frameworks look ugly as hell by comparison.
  - sdwr 4y ago
    How is svelte? Heard someone give a talk about it a few years back, sounded like it was pared down/elegant. I wrote a project in Angular back when I was using it in my day job and shudder now looking back at the code. It's so bloated by default!
    - datavirtue 4y ago
      It appears as just another framework but once you dig in and start using it the elegance is ridiculous and addicting.
stakent 4y ago
https://unpoly.com/ https://unpoly.com/ is a good choice - it's description is true: "The unobtrusive JavaScript framework for server-side web applications Unpoly enables fast and flexible frontends for server-rendered HTML views. It has no dependencies and plays nice with existing code."
akpa1 4y ago
HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use! [0]: https://github.com/gofiber/fiber https://github.com/gofiber/fiber [1]: https://github.com/codemicro/go-neon https://github.com/codemicro/go-neon
- iamgopal 4y ago
  Goneon looks interesting. Is it trying to provide compatibility with quick templates etc or aim to reach jinja level features parity ?
  - akpa1 4y ago
    The aim is to be just as functionally similar to QuickTemplate, though not compatible. I like the idea of QuickTemplate a lot but the I find it lacking and annoying to use in various ways. For example, I find its syntax is annoying to write, I don't like having to re-declare the types of my variables whenever I use them and it's error reporting is near useless. Currently, Neon is just barely at MVP. I'm dogfooding it and adding to it as I find I need things.
- iamgopal 4y ago
  Try to release boiler plate template that uses these tech, if possible and convenient.
  - akpa1 4y ago
    Good idea! I'll remember that for when Neon is suitable for people other than myself to use, thanks :)
4m1rk 4y ago
I guess the original issue is that HTML/CSS is desgined for creating documents and standard forms not apps.

soulofmischief 4y ago

If you like hyperscript, it's worth checking out mithril. https://mithril.js.org https://mithril.js.org

gzer0 4y ago
What about adamant? I heard that is the next level above mithril.
- Legion 4y ago
  This sequence of comments is the JS ecosystem in a nutshell. Hear about something new, then immediately hear about its multiple successors/replacements.
  - soulofmischief 4y ago
    Mithril uses hyperscript as its foundation, it builds upon it as opposed to replacing/succeeding it :) Check it out, it's the kind of framework you pick and stick with for 20+ years. Zero bullshit compared to its peers.
    - ovao 4y ago
      And in a month or two the new hotness’ll be something else built on top of Mithril, or something “like Mithril but a bit different”. Good frameworks are good, and I love a good hobby project in some new hotness, but ecosystems, developer tooling, backward compatibility guarantees, large corporate backing, developer conferences, and community are what makes frameworks adoptable are what makes them stick.
      - soulofmischief 4y ago
        Mithril has been around for 7 years. How old does it need to be before it's not "the new hotness"? Just because you haven't heard of something doesn't mean it's new, and it would behoove you to not immediately dismiss things that are new to you as things that are new in general. Your heuristic that a large ecosystem is what makes a framework good precludes you from ever again touching any new project. It's a short-sighted approach. At some point, you have to grow up as a developer and try to understand the real world problems that modern declarative web frameworks have solved. I stated that mithril will be my tool of choice for hopefully 20+ years, so your framing this as me getting lost in the new hotness doesn't even hold up. This is about real tools, which are useful today and tomorrow, and which have slow API churn to facilitate longevity. It's just a bonus that mithril is also faster and far more terse than React and friends.
  - raffraffraff 4y ago
    Lol, to prove you're point even harder, your comment is not even the at the end of the list of successors/replacements.
- testplzignore 4y ago
  Nah. orichalcum.js is the hot new thing. It's a fork of adamant with support for monads, generics, and native blockchain integration.
  - charrondev 4y ago
    For anyone wondering what are these new JS frameworks: - mithril.js is an actual web framework. I’ve not tried it myself. - the next comment referenced adamant as being better. There is an MMORPG called RuneScape in which weapons and armour can be smithed of various metals, and treats adamant as 1 tier better than mithril. - similarly orichalcum is a couple of tiers above mithril.
- soulofmischief 4y ago
  Don't give anyone any ideas!

nisegami 4y ago

Working on a project right now with htmx, hyperscript, tailwindcss (all new to me) and it's impressive how low the cognitive load is in a lot of cases.

gremlinsinc 4y ago
htmx and tailwindcss are great but hyperscript looks crazy evil. I hate mixing html and js though, even jsx rubs me wrong. This looks like pug/slim and other templating to remove xml from pages but instead of just something like body p | This is a test of the text block. you get something like: var h = require('hyperscript') h('p', "This is a test of the text block") and I want to know why would you want the entire page in JS objects? personally I like the way htmx, vue, alpinejs do things with basically embedding actions/events on the existing xml structures. It's more an abstraction over existing html, than totally redoing or replacing html. That seems like a case of 'we knew we could do it, but never stopped to ask ourselves if we should' ... Turbolinks + stimulusjs is also another great stack for mini-frontend frameworks. Also super fast.. turbolinks can go well w/ anything though including htmx or alpinejs, but there's a lot of tutorials on stimulus+turbolinks.
- nisegami 4y ago
  When I first saw hyperscript in the HTMX docs (they're made by the same person), it also struck me as an unholy abomination. But in practice, it's been pretty nifty. It provides a concise way to perform common actions that adheres to the idea of locality of behavior that HTMX and Tailwind both offer as well. I still think I might come to regret it, but it doesn't seem like it would be hard to rip it out and replace it with plain JS. For example, I'm mostly using it to do stuff like: on click toggle .hidden on .modal
  - toastercat 4y ago
    I believe you are talking about this hyperscript: https://hyperscript.org/ https://hyperscript.org/ Whereas the parent post is talking about: https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript Unfortunately, the creator of https://hyperscript.org/ https://hyperscript.org/ hijacked the name even when the term "hyperscript" is still used to refer to dominictarr's project and the `h('p', 'hello world') API of declaring templates in JavaScript (as seen in React, Preact, Mithril, etc.).

athrowaway3z 4y ago

I'll throw in https://caldom.org/ https://caldom.org/

amadeuspagel 4y ago

If you want to stay close to vanilla, I'd recommend lit: https://lit.dev/ https://lit.dev/

BenoitEssiambre 4y ago
I sometimes use an even closer to vanilla option based on just the Lit templating engine: https://benoitessiambre.com/vanilla.html https://benoitessiambre.com/vanilla.html
Existenceblinks 4y ago
Or https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml

BenoitEssiambre 4y ago

On top of these options, with modern browsers, it's quite easy to make reactive components in plain vanilla ( https://benoitessiambre.com/vanilla.html https://benoitessiambre.com/vanilla.html ). I find this approach very usable for smaller simpler projects where you don't need a full framework.

tgflynn 4y ago

I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ https://tgflynn.github.io/AlgoVis/ (github link: https://github.com/tgflynn/AlgoVis https://github.com/tgflynn/AlgoVis). The fact that this works, didn't take long to write (though I'm very much still learning this stuff) and is very fast leads me to question your statement that "The imperative DOM api just sucks".

guilherme-puida 4y ago
> simple demo app I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.
- tgflynn 4y ago
  All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?
  - arbitrage 4y ago
    so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time. as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect. beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it. you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth. in the end, frameworks aide results beyond the ability of a single coder to implement on their own.
  - guilherme-puida 4y ago
    If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?

dxchester 4y ago

We developed El to be as minimal as possible, while still solving the problem of keeping state and interface in sync: https://github.com/frameable/el https://github.com/frameable/el It's just ~150 lines / 2kb, and leverages existing browser functionality to accomplish most of the hard parts. Has observability, reactive templates, scoped CSS, no need for a build process, etc.

acqbu 4y ago
This looks very interesting, I'll give it a go
hilti 4y ago
Interesting - looks pretty similar to Framework7 components https://framework7.io/docs/router-component https://framework7.io/docs/router-component
vinibrito 4y ago
I have been reading into it for some time now, since I do not want to dive into a big framework with a huge learning curve for a side project that I have. I just feel afraid to run into a problem that has already been solved in a big framework and get stuck.

gremlinsinc 4y ago

wow thanks for this, I'm fullstack with tons of vue exp but have been 90% backend for the past 6 months or had my head in a hole or something -- this is the first i've heard of petite-vue. Looks pretty cool, maybe somewhat akin to alpinejs, which I have been using more lately also. I'd also put that on the list as it's a nice framework with a bit less footprint than vue/react etc.

sdwr 4y ago

Vue is right in the sweet spot for me doing solo stuff. Get all the reactive stuff with minimal additional complexity.

datavirtue 4y ago
I was about to use Vue for a new project but got pulled by the siren call of svelte. The other popular frameworks look ugly as hell by comparison.
- sdwr 4y ago
  How is svelte? Heard someone give a talk about it a few years back, sounded like it was pared down/elegant. I wrote a project in Angular back when I was using it in my day job and shudder now looking back at the code. It's so bloated by default!
  - datavirtue 4y ago
    It appears as just another framework but once you dig in and start using it the elegance is ridiculous and addicting.

stakent 4y ago

https://unpoly.com/ https://unpoly.com/ is a good choice - it's description is true: "The unobtrusive JavaScript framework for server-side web applications Unpoly enables fast and flexible frontends for server-rendered HTML views. It has no dependencies and plays nice with existing code."

akpa1 4y ago

HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use! [0]: https://github.com/gofiber/fiber https://github.com/gofiber/fiber [1]: https://github.com/codemicro/go-neon https://github.com/codemicro/go-neon

iamgopal 4y ago
Goneon looks interesting. Is it trying to provide compatibility with quick templates etc or aim to reach jinja level features parity ?
- akpa1 4y ago
  The aim is to be just as functionally similar to QuickTemplate, though not compatible. I like the idea of QuickTemplate a lot but the I find it lacking and annoying to use in various ways. For example, I find its syntax is annoying to write, I don't like having to re-declare the types of my variables whenever I use them and it's error reporting is near useless. Currently, Neon is just barely at MVP. I'm dogfooding it and adding to it as I find I need things.
iamgopal 4y ago
Try to release boiler plate template that uses these tech, if possible and convenient.
- akpa1 4y ago
  Good idea! I'll remember that for when Neon is suitable for people other than myself to use, thanks :)

4m1rk 4y ago

I guess the original issue is that HTML/CSS is desgined for creating documents and standard forms not apps.