19 ms·

Show HN: Skruv – No-dependency, no-build, small JavaScript framework

123 points by SahAssar 6y ago

Zobat 6y ago
Googled: "no dependency" javascript framework 37k+ results. "no build" javascript framework 45k+ results. At this point I'd be seriously impressed by someone saying "I didn't create a new JS framework, instead I contributed to an existing one".
- SahAssar 6y ago
  Yeah, I try to address this on the start page. I did contribute a bit to hyperapp for a while and used it professionally. They took a different path with v2 though and forking v1 to add the features listed proved to have a similar diff to writing it from scratch.
- skinkestek 6y ago
  Did you try looking past page three in the search results? And did you verify that at least a few of those pages contained the search terms? Because in my experience that is not given: - Google used to brag about crazy number of results but if I tried to go to page 5 it would admit there weren't any. I guess it was a naive bloom filter or something out of my league that caused it - and those that knew didn't care because it looked good for 99,999% of the users. - Google has happily ignored double quotes for well over a decade now. Lately I've had some success by using the plus operator immediately in front of the doublequotes. Side note: I feel hesitant to write that. An UX-er from Google might notice it and fix that bug to make it consistent (consistently useless, that would be) :-/ These days I use DDG as default though and after being fooled a lot of times and one too many I don't even bother to look behind page 2 on Google since years ago.
- lucideer 6y ago
  Ah yes, the three levels of laziness: - writing new frameworks - contributing to existing frameworks - commenting on HN deriding those writing new frameworks I don't know what the keywords are to Google for the 3rd type, but I suspect the result count would be the highest of all.
- mszcz 6y ago
  Yeah, same here. This framework development frenzy seems to me like procrastination from doing actual work. 'Gee, I finally have time to do this web site I always wanted! Well, let's start with the OS my custom browser will run on!'. Please note, that this is not a dig at this particular project. I'm sure it's nice and all but I'm never going to use it because 1) what's the chance this'll be around and maintained in 6 months time? 2) no community support, probably no way to ask questions or see other people's questions, 3) what's the chance that 1 & 2 will change in a couple of months? This line of reasoning can be applied to most of the new frameworks out there I think.
  - majkinetor 6y ago
    Its not exactly procrastination because while creating framework you are deep into topic and amassed knowledge helps you in general, no ? You can't understand anything until you build it.
    - javajosh 6y ago
      In general you shouldn't be creating a framework, you should be making an application.
      - majkinetor 6y ago
        In general, any non-trivial application uses micro-frameworks (that you write) and macro-frameworks (that you use or write).
        creshal 6y ago
        Not every reusable piece of code is a framework.
        atat7024 6y ago
        It kinda is, if someone packages it up and calls it that
- dang 6y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html There are also additional guidelines for Show HN threads: Be respectful. Anyone sharing work is making a contribution, however modest. Ask questions out of curiosity. Don't cross-examine. Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more. When something isn't good, you needn't pretend that it is, but don't be gratuitously negative. https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
genericstorage3 6y ago
Can't read tutorial on mobile
- SahAssar 6y ago
  Yeah, I couldn't make the tutorial work well on mobile since it has to show quite a lot at the same time. Rather than forcing it into a mobile view I decided to keep it as is. I might revisit that in the future and do something similar to svelte's tabbed interface.
  - SPBS 6y ago
    The website is completely blank white for my samsung s7 android edge browser (but works fine on android chrome). If this was written using your framework, there's probably a bug that's causing it not to render.
    - SahAssar 6y ago
      Do you perhaps know the version of the browser? Thank you for reporting anyways and I'll take a look!
exdeve 6y ago
Is this for real?
dmos62 6y ago
The top nav bar gets duplicated vertically many times for me. Seems to only happen when Dark Reader is enabled. Weird. I might be wrong, didn't examine what's happening.
- SahAssar 6y ago
  Yep, seems like dark reader injects some elements that the site does not like. I'll look into it, thanks for reporting!
- SahAssar 6y ago
  Fixed now!
croon 6y ago
I get ERR_SSL_VERSION_OR_CIPHER_MISMATCH from the website.
- SahAssar 6y ago
  What browser, version and OS? The server is setup with pretty strict TLS settings, but modern browsers should work.
  - croon 6y ago
    Edge 89.0.774.54 64-bit on Windows 10. Can't rule out group policy settings fudging something though. I'll try another machine.
    - SahAssar 6y ago
      Just tried it on Edge 85 & Edge 89 and "it works on my machine". Please let me know if you find what the issue is!
    - SahAssar 6y ago
      (Can't edit the previous comment anymore) I switched to allowing TLS-v1.2, hopefully that fixes the issue for you. Let me know if it doesn't and I can take another look!
      - croon 6y ago
        Works fine now, thanks!
  - shaicoleman 6y ago
    The site is TLS 1.3 only. Please make sure you understand the unintended consequences of doing that https://news.ycombinator.com/item?id=26559869#26560889 https://news.ycombinator.com/item?id=26559869#26560889
    - SahAssar 6y ago
TekMol 6y ago
Everything that does not let me define the interface in HTML is a no-go for me. HTML and CSS are a very good approach to define a GUI. And they will be around for a very long time. This is the reason why I also don't use React, Flutter and all the other ways to build web/mobile/whatever applications. I am torn on Vue. It is kind of ok because it lets you work with HTML templates with placeholders. Great. But it alters your data (puts getters/setters on everything) even when you don't need that. The best solution in my book is to use a javascript template engine like handlebars.
- kondu 6y ago
  What's your opinion on svelte?
  - TekMol 6y ago
    Svelte seems to be set on having a server side build process for the front end. That is an even bigger no-go for me. The complexity of React and the OPs framework at least be contained in the frontend. With a server side build step, the complexity of the frontend spoils over to the backend.
  - BiteCode_dev 6y ago
    One big selling point on vue is that you can just use a tag script and map a vue object on your regular HTML page. Ne need for build steps. No need for html in the JS script. It feels like JS from the 2000, simple and light, but with reactivity and speed. Of course, once you need it, you can just use the awesome ViteJS to get your backend build with SFC files. This makes vue scale up, but also scale down, which is equally important.
- valenterry 6y ago
  HTML is a text markup language and hence not very well suited to build a logical structure for the same reason that xml is not very well suited to describe data. And that is not because it cannot do it, but because it is too powerful. What is better in my opinion is a mix. Use one language or specification to model your architecture and structure and then, strictly on top of that, write (x)html to define your content. (you could also use markdown, just choose a markup language) Then, for the layout/design, use CSS that is completely separate from your site's structure and content; read: separate file, not embedded in the rest. Well, maybe CSS is insufficient and you also need to use Javascript or some language on top of it because the CSS is still lacking of lot of important things, but that's not a principal problem but a specific problem of CSS as a language.
queuep 6y ago
Why is this syntax so popular? I haven't used it but it smells so weird.. https://skruv.io/Tutorial/step3/ https://skruv.io/Tutorial/step3/ (Inside the renderNode) Nontheless, I like this direction of a small framework keeping it simple, like Vue was initially.
- Oddskar 6y ago
  Because you can pretty easily add a layer on top to make it nicer (like JSX). And it has the benefit of working with e.g. Typescript and give you type safety out of the box, unlike Frameworks that have their own template systems.
  - skinkestek 6y ago
    Agree: Once one deliberately throws out support for all but JS-enabled browsers, HTML doesn't matter that much anymore and at that point tooling support like making it possible to work in TypeScript becomes a nice bonus. (Note however that while enjoy projects like these and also don't vilify most people who wrote JS-dependent websites, not even in my thoughts, I might think of those who write html with optional js-features as nicer people, more thoughtful/considerate and less childish ;-)
    - strogonoff 6y ago
      Throwing out support for HTML-only browsers is not a prerequisite for authoring a reactive UI with JS. Using Next.js, react-static, or even plain ReactDOM’s renderToString() you can generate static HTML+CSS for your pages, which would then be hydrated and become interactive only in user agents with JS enabled. Authoring components with awareness of that, you can degrade gracefully while reaping the benefits of type checking, reusable components etc. at development stage.
      - skinkestek 6y ago
        No, but the moment you depend on Javascript being enabled in the client, why not get rid of as much of html as possible and use a sane language like TypeScript?
notum 6y ago
I've come to expect the "why another JS framework" paragraph on project websites. For me, more attention garbing and unusual would be omitting it.
tlamponi 6y ago
First: I find the diff to the previous step in the tutorial really nice, it helps to grok what changed nicely for me, well, similar to patch series do. Never saw that used in a general framework tutorial, or at least I do not remember doing so. The framework itself looks OK from a quick glance, I'll see if I can give it a try sometime. I'm searching a small and modern framework since a bit, for hacking together quick small prototypes, personal status-page frontends, and the like. I do not like using bigger frameworks there as after digging around in huge frameworks in the past for work, I want it really just end-to-end understandable. I actually thought about hacking the few helpers together myself, but I rather like to reuse something to avoid combating different browsers (even that landscape isn't as colourful as it was), and the like. Also, I wanted also to avoid inventing "yet another minimal JS framework". So, FWICT, Skruv seems to fit my bill actually quite nicely. Two questions, just out of interest: Any plans about how to develop and/or maintain this in the future? Is this anyhow involved in a commercial operation, i.e., where you or other devs can get paid to invest some (maintenance) work into it?
- SahAssar 6y ago
  > Any plans about how to develop and/or maintain this in the future? Yes, I plan to continue developing and supporting it although I don't think I'll add too many features since I try to keep it focused. > Is this anyhow involved in a commercial operation, i.e., where you or other devs can get paid to invest some (maintenance) work into it? Yes, I use it professionally and can use some paid time to work on it. One of the reasons to post it here was to get some other devs eyes on it and to make it easier to bring on new hires by hopefully building a small community.
Bootvis 6y ago
Doesn’t work for me on Firefox 68.7.0 esr.
- SahAssar 6y ago
  The current Firefox ESR release is 78.9.0 unless I'm mistaken, it should work on that. Currently I only support recent/current versions of browsers.
gervwyk 6y ago
Would be great if the docs was mobile friendly.
megous 6y ago
At this point what would be interesting would be some framework that doesn't use vdom. :) Kinda sad how little diversity of foundational concepts of the framework there is these days. ES modules, because we can. vdom, because that's what everybody is doing, and async/await everywhere. Kinda boring. I like the minimalism of this one though.
- Johman10 6y ago
  This is what Svelte does today. I think Svelte is the innovative one in the current state of things. :) https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
  - DrStartup 6y ago
    I agree about svelte. It leverages the foundations of the web - html and css - and adds some amazing reactive sugar!
- ser0 6y ago
  If you want a simple library that doesn't use vdom, have a look at RE:DOM https://redom.js.org/#introduction https://redom.js.org/#introduction
- jeswin 6y ago
  There are plenty of frameworks which don't use vDOM. In fact, if someone is coding up something new today they're less likely to use vDOM.
- kigiri 6y ago
  Also, solid.js
noscripter 6y ago
I get: > Sorry, this site is about a JS framework and requires JS. Perhaps the only time such a message is reasonable?
forvelin 6y ago
can anybody who uses it compare it with mithril.js ?
progx 6y ago
Why is vDom an advantage?
- nandi95 6y ago
  https://www.codecademy.com/articles/react-virtual-dom https://www.codecademy.com/articles/react-virtual-dom
  - progx 6y ago
    Found this: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead https://medium.com/@hayavuk/why-virtual-dom-is-slower-2d9b964b4c9e https://medium.com/@hayavuk/why-virtual-dom-is-slower-2d9b96...
tobr 6y ago
This looks nice, especially how it deals with async functions and scoped styling out of the box. It’s to be expected that a submission like this prompts people skeptical of yet another JS framework, but I feel like it’s been a few years since the JS-framework-of-the-week phenomenon peaked.
maskros 6y ago
The font-family list in the stylesheet is both too long and weirdly specific, yet incomplete. I don't have any of these very specific Windows, Apple, or Android fonts installed on my machine, so it picks the first one it can find which is "Noto Color Emoji" and uses that as the main font. The end result that all the space characters are about two miles wide, and the rest is rendered using the browser default "sans-serif". You list 13 different sans-serif fonts, and two emoji fonts. The browser is perfectly capable of picking its own Emoji font for emoji characters so this is all completely unnecessary. Please just use "font-family: sans-serif" if that's what you want, otherwise use web fonts. There's no need for this level of complicated font family micro-management, that doesn't even work.
- deleted 6y ago
  [deleted]
- SahAssar 6y ago
  I used the base stylesheet from https://github.com/kognise/water.css https://github.com/kognise/water.css, but I'll prune down the list. Thanks for the feedback! EDIT: The font list is now down to 'sans-serif', so the issue should be fixed!
faraaz98 6y ago
Can we start getting frameworks in other languages that compile to WebAssembly instead. We already have enough JS frameworks
- eingaeKaiy8ujie 6y ago
  Rust compiles to WebAssembly and has a few web frameworks already. Many other languages also have web frameworks and compile to JS. Today it is possible to do web development and avoid JS entirely.
  - MH15 6y ago
    Codebases compiled to WebAssembly still cannot access the DOM directly. So yes, for now you still need JavaScript. https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts#porting_from_cc https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...
    - eingaeKaiy8ujie 6y ago
      Yes, but languages/frameworks can provide their own abstractions to access the DOM and web platform so that you can avoid writing any JavaScript yourself, for example `web_sys` in Rust.
  - SCLeo 6y ago
    I have tried writing websites with rust instead of JavaScript. Unfortunately, the tooling is just not there. More specifically, I am talking about wasm-bindgen, which provides two-way bindings. The problem with it is that since all the declarations are generated with build.rs, there is no autocompletion. Since I am spoiled by modern tooling, no autocompletion to me means not feasible pass demo stage. (https://github.com/rust-lang/rls/issues/1489 https://github.com/rust-lang/rls/issues/1489) Aside from the lack of autocompletion, passing rust closures to js land (DOM) is extremely janky as well. However, that might be caused by my lack of experience with rust. (If you are curious, this is what I made: https://github.com/SCLeoX/non-grid-path-finder https://github.com/SCLeoX/non-grid-path-finder)
kreetx 6y ago
I get this error on console (Firefox 83): Uncaught TypeError: Error resolving module specifier “skruv/html.js”. Relative module specifiers must start with “./”, “../” or “/”. index.js:3:64
- SahAssar 6y ago
  Yeah, that's expected. It comes from the shim I'm using to support import maps, it's explained why the error is "wanted" here: https://github.com/guybedford/es-module-shims#polyfill-mode https://github.com/guybedford/es-module-shims#polyfill-mode I could probably silence it, but since I have examples with that module in the tutorial it felt dishonest to do so.
  - kreetx 6y ago
    Thanks! More feedback from my Firefox (Chrome appears ok): spacing between words is really large. Ticking off font-family (or having it just sans-serif) in developer tools seems to fix it.
    - SahAssar 6y ago
      Yeah, I got some other feedback that the font declarations from the base stylesheet I pulled in was a bit much. I'll fix it, thanks for letting me know! EDIT: The font list is now down to 'sans-serif', so the issue should be fixed!
      - kreetx 6y ago
        Looks great now, thanks!
high_byte 6y ago
{}... {} everywhere why wouldn't you switch the attributes to the second param and set default value {}? seems really redundant this way
- SahAssar 6y ago
  All the HTML functions are variadic, so you can write section({}, h1({}, 'text'), article({}, 'text'), footer({}, 'text') ) instead of section({}, [ h1({}, 'text'), article({}, 'text'), footer({}, 'text') ]) It's a choice, but I think without it you would have a lot more array openings/closings, and they would be more spread out instead of the empty objects, which are kept in the same place.
  - abraxas 6y ago
    Your answer makes a lot of sense. I think you've made the right compromise.
pgt 6y ago
Reagent (& Rum) are still IMO the state of the art in frontend web development: https://reagent-project.github.io/ https://reagent-project.github.io/
- iterati 6y ago
  I prefer re-frame over rum, but Reagent is amazing. So little churn over the life of the library is a great accomplishment.
- wffurr 6y ago
  You have to buy into ClojureScript though. Nothing wrong with ClojureScript per se, but adding a build step back in (plus the occasional transpilation weirdness) is pretty far afield from a native no-build JS system. I’m not trying to say that Skruv is state of the art either, maybe it is, I don’t know. But using ClojureScript definitely raises the bar for who has the ability to use Reagent and who is willing to.
  - jacobobryant 6y ago
    Yes, exactly. I did SPAs with ClojureScript for a while, but lately I've switched to server-side rendering with Rum. This post popped out at me since I've been thinking about options for adding interactivity to the front end without adding a build step.
seer 6y ago
Hah last year I did my case study of building an app with only web tech - no dependencies, build steps etc. - https://github.com/ivank/vanilla-teuxdeux https://github.com/ivank/vanilla-teuxdeux Figured out virtual dom is the one big missing piece to make webdev workable without any dependencies at all. I can see other people are getting to similar conclusions:)
ddevault 6y ago
Oh good. Another one.
collyw 6y ago
Just what we need, another JS framework.
d--b 6y ago
At this stage, it's so easy to create a new "framework" that they shouldn't be called frameworks anymore. They're just a way to organize code. I mean I've probably made one of these for each app I built. It takes a couple of days to write and then you can modify it to fit your very needs...
- madeofpalk 6y ago
  Isn't "a way to organise" (code) exactly what a framework is?
simplify 6y ago
For those who have these requirements, you should try Mithril.js. It's small, robust, stable, has a strong community, and has been around since 2014. It's as close to plain JavaScript as you can get. Mithril's flexibility is so well designed, we're still finding new and innovative ways to use it, even though the base library rarely changes. Having used React and other libraries for many years, Mithril is still the simplest and most pleasant library out there.
- noir_lord 6y ago
  lichess uses it (mithril) for what is one of my absolute favourite examples of a truly well done web application - everything about lichess is just so well executed that if the author of a product like that chose mithril that's a strong indicator it's at least worth a good look.
madeofpalk 6y ago
> uses plain JS for building up the DOM tree (normal functions, no JSX or template tags) body({ oncreate: (e) => { console.log(e, 'was just added to the DOM') } }, 'Hello world!'), heh. I find it mildly funny when people recreate JSX from from first principles
- blacktriangle 6y ago
  I find it funny that JSX even exists when writing helpers to build html with functions is such a trivial exercise and easy to read, but nope, lets add in some wonky XML with weird corner cases.
  - williamdclt 6y ago
    > and easy to read Very arguable. I'll take "wonky XML" over JS function calls any day for readability, and apparently most people would too given that they write JSX rather than use `React.createElement` and that all major frontend view libs (angular, react, vue, svelte, mithril...) offer XML-like templating and people overwhelmingly use it.
- SahAssar 6y ago
  JSX basically compiles down to function calls, so this is more like taking the JSX out of the loop. In react the equivalent JSX would basically compile to React.createElement("body", { oncreate: (e) => { console.log(e, 'was just added to the DOM') } }, 'Hello world!'), which does not seem that different, right? If you want to you can use JSX with skruv as long as you tell the JSX compiler to use `h` instead, in which case it will produce this: h("body", { oncreate: (e) => { console.log(e, 'was just added to the DOM') } }, 'Hello world!'), which works with skruv.
  - madeofpalk 6y ago
    Yes this was kind of my observation.
- dang 6y ago
lhorie 6y ago
(Disclaimer: I'm author of mithril.js, another minimalist JS framework) I'm curious why you decided to export multiple tag names as opposed to using hyperscript. Something that helped mithril.js gain more traction was that while it is idiomatically meant to be used as plain JS, it's also compatible with JSX tooling for the folks that want that. Also, some things are a bit awkward to express in terms of tag-names-as-functions (most notably, custom components require a hyphen in their names, and SVG tags need to be created with a different DOM API, and some have name collisions with HTML tags, e.g. `title`)
- SahAssar 6y ago
  Skruv's html lib evolved from how I used hyperapp v0 and v1 a couple of years ago. It seems from what I can tell that hyperscript, hyperapps `h` function and skruv's `h` function follow similar ideas and signatures and I got my inspiration from hyperapp which I guess got at least some inspiration from mithril. One thing I like about exporting multiple tag names is that it (to me at least) makes it more readable. When I switched over my last team from JSX to JS (that was in hyperapp v1) they did not like writing `h('div')` but were fine with `div()` so I put that together and over time it grew on me. I also kinda like being able to see what elements are used based on the import at the top of the file, but that's secondary. Skruv still exposes a `h` function that is used for web-components, like `h('my-component')` and you can use it for all HTML elements or for JSX. The rest are just for readability and convinience (and are really just curried versions of `h`). As for SVG I mostly do that by tracking if a parent was a SVG element and if so I assume all children are SVG namespaced (again, inspiration taken from hyperapp) until I hit a foreginObject element which means to switch out of the SVG namespace. If you have better ideas or feedback on that I'd be happy to listen. Thank you for taking a look and I'd love to hear any other thoughts you have!
  - lhorie 6y ago
    I believe jorgebucaran (hyperapp author) was aware of mithril.js' existence and may possibly have been inspired by it, but I don't take credit for hyperscript itself (it was already a concept used by various other systems - the word "hyperscript" itself comes from the name of a project[0], and there were already other similar frameworks like mercury[1] at the time). For mithril.js specifically, the hyperscript variation offers an extra feature that AFAIK not many other libs do: the ability to write emmett-like CSS expressions as the tag name (e.g. `m('input.required[type=password]')`). Totally understandable if you think that's too much sugar for your lib, but I've found it handy for usage with CSS frameworks like bootstrap. Mithril.js users also appreciate it and some interesting unexpected patterns came out of that (e.g. `const Foo = '.some.tailwind.thing'; <Foo />`) BTW, funny story: mithril.js partially took inspiration from an ancient library called dōmo[2] which - as it turns out - uses the tags-as-functions pattern. [0] https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript [1] https://github.com/Raynos/mercury https://github.com/Raynos/mercury [2] https://jed.github.io/domo/ https://jed.github.io/domo/
xyst 6y ago
https://xkcd.com/927/ https://xkcd.com/927/ going to make a hello world app using skruv so I start the timer on my skruv exp
pjmlp 6y ago
Love it, that is how I do Web development when I control the development stack.
h3rald 6y ago
Interesting project! I recently created something similar[1] because I wanted a simple, easy to use, bloat-free micro framework to create single page applications. I also wanted it to be somewhat "battery-included" and provide things like routing and state management out of the box. I think skruv comes with even bigger batteries (SVG support, Shadow Dom integration and additional vdom related apis), and I am curious to see how they all play together. The one thing that does seem a bit weird is the html helper functions... like Mithril, I went straight for hyperscript: I think it is very underrated right now but it is actually a good way to write a dom tree -- and you also get JSX support (nearly) for free. Anyhow, keep up the good work, I think the world needs more micro frameworks like these: powerful but simple enough to be understood and extended easily if needed. [1]: https://h3.js.org https://h3.js.org
- SahAssar 6y ago
  Thanks! I haven't built in a router yet, but I'll publish the one in the Tutorial as a separate package as soon as I feel it covers enough use-cases. On hyperscript: I prefer to keep the tag name separated from selectors, to me stuff like element type and classes/id's belong in different places and with css scoping built in I think you won't need as many classes so hopefully it won't be a big issue. In general I want the vDOM/HTML stuff to be a pretty direct abstraction on the HTML/DOM in the browser. On JSX: There is a generic `h` function builtin that can be used as a target for JSX. I'll put together an example of it in the coming days. I still want the recommended way to use the framework to be without build steps, parsing or dependencies though.
phpisatrash 6y ago
YAJF - Yet Another JavaScript Framework
Semiapies 6y ago
A framework to do... What? Is this another view layer? "Framework" actually has a meaning beyond "JS library". I'd normally not make this complaint, but the entire home page only tells me what it isn't and some traits it doesn't have, aside from the hint it does weird things to CSS. (I tried to look at the tutorial, but it was a mess on my tablet.) It doesn't tell me why I might actually want to use it. After all, there's no library so concise that it wins the LOC comparison against not including it in a project.
ipaddr 6y ago
You're framework doesn't render on an older chrome android browser.

123 points by SahAssar 6y ago

Googled: "no dependency" javascript framework 37k+ results. "no build" javascript framework 45k+ results. At this point I'd be seriously impressed by someone saying "I didn't create a new JS framework, instead I contributed to an existing one".

SahAssar 6y ago
Yeah, I try to address this on the start page. I did contribute a bit to hyperapp for a while and used it professionally. They took a different path with v2 though and forking v1 to add the features listed proved to have a similar diff to writing it from scratch.
skinkestek 6y ago
Did you try looking past page three in the search results? And did you verify that at least a few of those pages contained the search terms? Because in my experience that is not given: - Google used to brag about crazy number of results but if I tried to go to page 5 it would admit there weren't any. I guess it was a naive bloom filter or something out of my league that caused it - and those that knew didn't care because it looked good for 99,999% of the users. - Google has happily ignored double quotes for well over a decade now. Lately I've had some success by using the plus operator immediately in front of the doublequotes. Side note: I feel hesitant to write that. An UX-er from Google might notice it and fix that bug to make it consistent (consistently useless, that would be) :-/ These days I use DDG as default though and after being fooled a lot of times and one too many I don't even bother to look behind page 2 on Google since years ago.
lucideer 6y ago
Ah yes, the three levels of laziness: - writing new frameworks - contributing to existing frameworks - commenting on HN deriding those writing new frameworks I don't know what the keywords are to Google for the 3rd type, but I suspect the result count would be the highest of all.
mszcz 6y ago
Yeah, same here. This framework development frenzy seems to me like procrastination from doing actual work. 'Gee, I finally have time to do this web site I always wanted! Well, let's start with the OS my custom browser will run on!'. Please note, that this is not a dig at this particular project. I'm sure it's nice and all but I'm never going to use it because 1) what's the chance this'll be around and maintained in 6 months time? 2) no community support, probably no way to ask questions or see other people's questions, 3) what's the chance that 1 & 2 will change in a couple of months? This line of reasoning can be applied to most of the new frameworks out there I think.
- majkinetor 6y ago
  Its not exactly procrastination because while creating framework you are deep into topic and amassed knowledge helps you in general, no ? You can't understand anything until you build it.
  - javajosh 6y ago
    In general you shouldn't be creating a framework, you should be making an application.
    - majkinetor 6y ago
      In general, any non-trivial application uses micro-frameworks (that you write) and macro-frameworks (that you use or write).
      - creshal 6y ago
        Not every reusable piece of code is a framework.
        atat7024 6y ago
        It kinda is, if someone packages it up and calls it that
dang 6y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html There are also additional guidelines for Show HN threads: Be respectful. Anyone sharing work is making a contribution, however modest. Ask questions out of curiosity. Don't cross-examine. Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more. When something isn't good, you needn't pretend that it is, but don't be gratuitously negative. https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html

genericstorage3 6y ago

Can't read tutorial on mobile

SahAssar 6y ago
Yeah, I couldn't make the tutorial work well on mobile since it has to show quite a lot at the same time. Rather than forcing it into a mobile view I decided to keep it as is. I might revisit that in the future and do something similar to svelte's tabbed interface.
- SPBS 6y ago
  The website is completely blank white for my samsung s7 android edge browser (but works fine on android chrome). If this was written using your framework, there's probably a bug that's causing it not to render.
  - SahAssar 6y ago
    Do you perhaps know the version of the browser? Thank you for reporting anyways and I'll take a look!

exdeve 6y ago

Is this for real?

dmos62 6y ago

The top nav bar gets duplicated vertically many times for me. Seems to only happen when Dark Reader is enabled. Weird. I might be wrong, didn't examine what's happening.

SahAssar 6y ago
Yep, seems like dark reader injects some elements that the site does not like. I'll look into it, thanks for reporting!
SahAssar 6y ago
Fixed now!

croon 6y ago

I get ERR_SSL_VERSION_OR_CIPHER_MISMATCH from the website.

SahAssar 6y ago
What browser, version and OS? The server is setup with pretty strict TLS settings, but modern browsers should work.
- croon 6y ago
  Edge 89.0.774.54 64-bit on Windows 10. Can't rule out group policy settings fudging something though. I'll try another machine.
  - SahAssar 6y ago
    Just tried it on Edge 85 & Edge 89 and "it works on my machine". Please let me know if you find what the issue is!
  - SahAssar 6y ago
    (Can't edit the previous comment anymore) I switched to allowing TLS-v1.2, hopefully that fixes the issue for you. Let me know if it doesn't and I can take another look!
    - croon 6y ago
      Works fine now, thanks!
- shaicoleman 6y ago
  The site is TLS 1.3 only. Please make sure you understand the unintended consequences of doing that https://news.ycombinator.com/item?id=26559869#26560889 https://news.ycombinator.com/item?id=26559869#26560889
  - SahAssar 6y ago

TekMol 6y ago

Everything that does not let me define the interface in HTML is a no-go for me. HTML and CSS are a very good approach to define a GUI. And they will be around for a very long time. This is the reason why I also don't use React, Flutter and all the other ways to build web/mobile/whatever applications. I am torn on Vue. It is kind of ok because it lets you work with HTML templates with placeholders. Great. But it alters your data (puts getters/setters on everything) even when you don't need that. The best solution in my book is to use a javascript template engine like handlebars.

kondu 6y ago
What's your opinion on svelte?
- TekMol 6y ago
  Svelte seems to be set on having a server side build process for the front end. That is an even bigger no-go for me. The complexity of React and the OPs framework at least be contained in the frontend. With a server side build step, the complexity of the frontend spoils over to the backend.
- BiteCode_dev 6y ago
  One big selling point on vue is that you can just use a tag script and map a vue object on your regular HTML page. Ne need for build steps. No need for html in the JS script. It feels like JS from the 2000, simple and light, but with reactivity and speed. Of course, once you need it, you can just use the awesome ViteJS to get your backend build with SFC files. This makes vue scale up, but also scale down, which is equally important.
valenterry 6y ago
HTML is a text markup language and hence not very well suited to build a logical structure for the same reason that xml is not very well suited to describe data. And that is not because it cannot do it, but because it is too powerful. What is better in my opinion is a mix. Use one language or specification to model your architecture and structure and then, strictly on top of that, write (x)html to define your content. (you could also use markdown, just choose a markup language) Then, for the layout/design, use CSS that is completely separate from your site's structure and content; read: separate file, not embedded in the rest. Well, maybe CSS is insufficient and you also need to use Javascript or some language on top of it because the CSS is still lacking of lot of important things, but that's not a principal problem but a specific problem of CSS as a language.

queuep 6y ago

Why is this syntax so popular? I haven't used it but it smells so weird.. https://skruv.io/Tutorial/step3/ https://skruv.io/Tutorial/step3/ (Inside the renderNode) Nontheless, I like this direction of a small framework keeping it simple, like Vue was initially.

Oddskar 6y ago
Because you can pretty easily add a layer on top to make it nicer (like JSX). And it has the benefit of working with e.g. Typescript and give you type safety out of the box, unlike Frameworks that have their own template systems.
- skinkestek 6y ago
  Agree: Once one deliberately throws out support for all but JS-enabled browsers, HTML doesn't matter that much anymore and at that point tooling support like making it possible to work in TypeScript becomes a nice bonus. (Note however that while enjoy projects like these and also don't vilify most people who wrote JS-dependent websites, not even in my thoughts, I might think of those who write html with optional js-features as nicer people, more thoughtful/considerate and less childish ;-)
  - strogonoff 6y ago
    Throwing out support for HTML-only browsers is not a prerequisite for authoring a reactive UI with JS. Using Next.js, react-static, or even plain ReactDOM’s renderToString() you can generate static HTML+CSS for your pages, which would then be hydrated and become interactive only in user agents with JS enabled. Authoring components with awareness of that, you can degrade gracefully while reaping the benefits of type checking, reusable components etc. at development stage.
    - skinkestek 6y ago
      No, but the moment you depend on Javascript being enabled in the client, why not get rid of as much of html as possible and use a sane language like TypeScript?

notum 6y ago

I've come to expect the "why another JS framework" paragraph on project websites. For me, more attention garbing and unusual would be omitting it.

tlamponi 6y ago

First: I find the diff to the previous step in the tutorial really nice, it helps to grok what changed nicely for me, well, similar to patch series do. Never saw that used in a general framework tutorial, or at least I do not remember doing so. The framework itself looks OK from a quick glance, I'll see if I can give it a try sometime. I'm searching a small and modern framework since a bit, for hacking together quick small prototypes, personal status-page frontends, and the like. I do not like using bigger frameworks there as after digging around in huge frameworks in the past for work, I want it really just end-to-end understandable. I actually thought about hacking the few helpers together myself, but I rather like to reuse something to avoid combating different browsers (even that landscape isn't as colourful as it was), and the like. Also, I wanted also to avoid inventing "yet another minimal JS framework". So, FWICT, Skruv seems to fit my bill actually quite nicely. Two questions, just out of interest: Any plans about how to develop and/or maintain this in the future? Is this anyhow involved in a commercial operation, i.e., where you or other devs can get paid to invest some (maintenance) work into it?

SahAssar 6y ago
> Any plans about how to develop and/or maintain this in the future? Yes, I plan to continue developing and supporting it although I don't think I'll add too many features since I try to keep it focused. > Is this anyhow involved in a commercial operation, i.e., where you or other devs can get paid to invest some (maintenance) work into it? Yes, I use it professionally and can use some paid time to work on it. One of the reasons to post it here was to get some other devs eyes on it and to make it easier to bring on new hires by hopefully building a small community.

Bootvis 6y ago

Doesn’t work for me on Firefox 68.7.0 esr.

SahAssar 6y ago
The current Firefox ESR release is 78.9.0 unless I'm mistaken, it should work on that. Currently I only support recent/current versions of browsers.

gervwyk 6y ago

Would be great if the docs was mobile friendly.

megous 6y ago

At this point what would be interesting would be some framework that doesn't use vdom. :) Kinda sad how little diversity of foundational concepts of the framework there is these days. ES modules, because we can. vdom, because that's what everybody is doing, and async/await everywhere. Kinda boring. I like the minimalism of this one though.

Johman10 6y ago
This is what Svelte does today. I think Svelte is the innovative one in the current state of things. :) https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
- DrStartup 6y ago
  I agree about svelte. It leverages the foundations of the web - html and css - and adds some amazing reactive sugar!
ser0 6y ago
If you want a simple library that doesn't use vdom, have a look at RE:DOM https://redom.js.org/#introduction https://redom.js.org/#introduction
jeswin 6y ago
There are plenty of frameworks which don't use vDOM. In fact, if someone is coding up something new today they're less likely to use vDOM.
kigiri 6y ago
Also, solid.js

noscripter 6y ago

I get: > Sorry, this site is about a JS framework and requires JS. Perhaps the only time such a message is reasonable?

forvelin 6y ago

can anybody who uses it compare it with mithril.js ?

progx 6y ago

Why is vDom an advantage?

nandi95 6y ago
https://www.codecademy.com/articles/react-virtual-dom https://www.codecademy.com/articles/react-virtual-dom
- progx 6y ago
  Found this: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead https://medium.com/@hayavuk/why-virtual-dom-is-slower-2d9b964b4c9e https://medium.com/@hayavuk/why-virtual-dom-is-slower-2d9b96...

tobr 6y ago

This looks nice, especially how it deals with async functions and scoped styling out of the box. It’s to be expected that a submission like this prompts people skeptical of yet another JS framework, but I feel like it’s been a few years since the JS-framework-of-the-week phenomenon peaked.

maskros 6y ago

The font-family list in the stylesheet is both too long and weirdly specific, yet incomplete. I don't have any of these very specific Windows, Apple, or Android fonts installed on my machine, so it picks the first one it can find which is "Noto Color Emoji" and uses that as the main font. The end result that all the space characters are about two miles wide, and the rest is rendered using the browser default "sans-serif". You list 13 different sans-serif fonts, and two emoji fonts. The browser is perfectly capable of picking its own Emoji font for emoji characters so this is all completely unnecessary. Please just use "font-family: sans-serif" if that's what you want, otherwise use web fonts. There's no need for this level of complicated font family micro-management, that doesn't even work.

deleted 6y ago
[deleted]
SahAssar 6y ago
I used the base stylesheet from https://github.com/kognise/water.css https://github.com/kognise/water.css, but I'll prune down the list. Thanks for the feedback! EDIT: The font list is now down to 'sans-serif', so the issue should be fixed!

faraaz98 6y ago

Can we start getting frameworks in other languages that compile to WebAssembly instead. We already have enough JS frameworks

eingaeKaiy8ujie 6y ago
Rust compiles to WebAssembly and has a few web frameworks already. Many other languages also have web frameworks and compile to JS. Today it is possible to do web development and avoid JS entirely.
- MH15 6y ago
  Codebases compiled to WebAssembly still cannot access the DOM directly. So yes, for now you still need JavaScript. https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts#porting_from_cc https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...
  - eingaeKaiy8ujie 6y ago
    Yes, but languages/frameworks can provide their own abstractions to access the DOM and web platform so that you can avoid writing any JavaScript yourself, for example `web_sys` in Rust.
- SCLeo 6y ago
  I have tried writing websites with rust instead of JavaScript. Unfortunately, the tooling is just not there. More specifically, I am talking about wasm-bindgen, which provides two-way bindings. The problem with it is that since all the declarations are generated with build.rs, there is no autocompletion. Since I am spoiled by modern tooling, no autocompletion to me means not feasible pass demo stage. (https://github.com/rust-lang/rls/issues/1489 https://github.com/rust-lang/rls/issues/1489) Aside from the lack of autocompletion, passing rust closures to js land (DOM) is extremely janky as well. However, that might be caused by my lack of experience with rust. (If you are curious, this is what I made: https://github.com/SCLeoX/non-grid-path-finder https://github.com/SCLeoX/non-grid-path-finder)

kreetx 6y ago

I get this error on console (Firefox 83): Uncaught TypeError: Error resolving module specifier “skruv/html.js”. Relative module specifiers must start with “./”, “../” or “/”. index.js:3:64

SahAssar 6y ago
Yeah, that's expected. It comes from the shim I'm using to support import maps, it's explained why the error is "wanted" here: https://github.com/guybedford/es-module-shims#polyfill-mode https://github.com/guybedford/es-module-shims#polyfill-mode I could probably silence it, but since I have examples with that module in the tutorial it felt dishonest to do so.
- kreetx 6y ago
  Thanks! More feedback from my Firefox (Chrome appears ok): spacing between words is really large. Ticking off font-family (or having it just sans-serif) in developer tools seems to fix it.
  - SahAssar 6y ago
    Yeah, I got some other feedback that the font declarations from the base stylesheet I pulled in was a bit much. I'll fix it, thanks for letting me know! EDIT: The font list is now down to 'sans-serif', so the issue should be fixed!
    - kreetx 6y ago
      Looks great now, thanks!

high_byte 6y ago

{}... {} everywhere why wouldn't you switch the attributes to the second param and set default value {}? seems really redundant this way

SahAssar 6y ago
All the HTML functions are variadic, so you can write section({}, h1({}, 'text'), article({}, 'text'), footer({}, 'text') ) instead of section({}, [ h1({}, 'text'), article({}, 'text'), footer({}, 'text') ]) It's a choice, but I think without it you would have a lot more array openings/closings, and they would be more spread out instead of the empty objects, which are kept in the same place.
- abraxas 6y ago
  Your answer makes a lot of sense. I think you've made the right compromise.

pgt 6y ago

Reagent (& Rum) are still IMO the state of the art in frontend web development: https://reagent-project.github.io/ https://reagent-project.github.io/

iterati 6y ago
I prefer re-frame over rum, but Reagent is amazing. So little churn over the life of the library is a great accomplishment.
wffurr 6y ago
You have to buy into ClojureScript though. Nothing wrong with ClojureScript per se, but adding a build step back in (plus the occasional transpilation weirdness) is pretty far afield from a native no-build JS system. I’m not trying to say that Skruv is state of the art either, maybe it is, I don’t know. But using ClojureScript definitely raises the bar for who has the ability to use Reagent and who is willing to.
- jacobobryant 6y ago
  Yes, exactly. I did SPAs with ClojureScript for a while, but lately I've switched to server-side rendering with Rum. This post popped out at me since I've been thinking about options for adding interactivity to the front end without adding a build step.

seer 6y ago

Hah last year I did my case study of building an app with only web tech - no dependencies, build steps etc. - https://github.com/ivank/vanilla-teuxdeux https://github.com/ivank/vanilla-teuxdeux Figured out virtual dom is the one big missing piece to make webdev workable without any dependencies at all. I can see other people are getting to similar conclusions:)

ddevault 6y ago

Oh good. Another one.

collyw 6y ago

Just what we need, another JS framework.

d--b 6y ago

At this stage, it's so easy to create a new "framework" that they shouldn't be called frameworks anymore. They're just a way to organize code. I mean I've probably made one of these for each app I built. It takes a couple of days to write and then you can modify it to fit your very needs...

madeofpalk 6y ago
Isn't "a way to organise" (code) exactly what a framework is?

simplify 6y ago

For those who have these requirements, you should try Mithril.js. It's small, robust, stable, has a strong community, and has been around since 2014. It's as close to plain JavaScript as you can get. Mithril's flexibility is so well designed, we're still finding new and innovative ways to use it, even though the base library rarely changes. Having used React and other libraries for many years, Mithril is still the simplest and most pleasant library out there.

noir_lord 6y ago
lichess uses it (mithril) for what is one of my absolute favourite examples of a truly well done web application - everything about lichess is just so well executed that if the author of a product like that chose mithril that's a strong indicator it's at least worth a good look.

madeofpalk 6y ago

> uses plain JS for building up the DOM tree (normal functions, no JSX or template tags) body({ oncreate: (e) => { console.log(e, 'was just added to the DOM') } }, 'Hello world!'), heh. I find it mildly funny when people recreate JSX from from first principles

blacktriangle 6y ago
I find it funny that JSX even exists when writing helpers to build html with functions is such a trivial exercise and easy to read, but nope, lets add in some wonky XML with weird corner cases.
- williamdclt 6y ago
  > and easy to read Very arguable. I'll take "wonky XML" over JS function calls any day for readability, and apparently most people would too given that they write JSX rather than use `React.createElement` and that all major frontend view libs (angular, react, vue, svelte, mithril...) offer XML-like templating and people overwhelmingly use it.
SahAssar 6y ago
JSX basically compiles down to function calls, so this is more like taking the JSX out of the loop. In react the equivalent JSX would basically compile to React.createElement("body", { oncreate: (e) => { console.log(e, 'was just added to the DOM') } }, 'Hello world!'), which does not seem that different, right? If you want to you can use JSX with skruv as long as you tell the JSX compiler to use `h` instead, in which case it will produce this: h("body", { oncreate: (e) => { console.log(e, 'was just added to the DOM') } }, 'Hello world!'), which works with skruv.
- madeofpalk 6y ago
  Yes this was kind of my observation.
dang 6y ago

lhorie 6y ago

(Disclaimer: I'm author of mithril.js, another minimalist JS framework) I'm curious why you decided to export multiple tag names as opposed to using hyperscript. Something that helped mithril.js gain more traction was that while it is idiomatically meant to be used as plain JS, it's also compatible with JSX tooling for the folks that want that. Also, some things are a bit awkward to express in terms of tag-names-as-functions (most notably, custom components require a hyphen in their names, and SVG tags need to be created with a different DOM API, and some have name collisions with HTML tags, e.g. `title`)

SahAssar 6y ago
Skruv's html lib evolved from how I used hyperapp v0 and v1 a couple of years ago. It seems from what I can tell that hyperscript, hyperapps `h` function and skruv's `h` function follow similar ideas and signatures and I got my inspiration from hyperapp which I guess got at least some inspiration from mithril. One thing I like about exporting multiple tag names is that it (to me at least) makes it more readable. When I switched over my last team from JSX to JS (that was in hyperapp v1) they did not like writing `h('div')` but were fine with `div()` so I put that together and over time it grew on me. I also kinda like being able to see what elements are used based on the import at the top of the file, but that's secondary. Skruv still exposes a `h` function that is used for web-components, like `h('my-component')` and you can use it for all HTML elements or for JSX. The rest are just for readability and convinience (and are really just curried versions of `h`). As for SVG I mostly do that by tracking if a parent was a SVG element and if so I assume all children are SVG namespaced (again, inspiration taken from hyperapp) until I hit a foreginObject element which means to switch out of the SVG namespace. If you have better ideas or feedback on that I'd be happy to listen. Thank you for taking a look and I'd love to hear any other thoughts you have!
- lhorie 6y ago
  I believe jorgebucaran (hyperapp author) was aware of mithril.js' existence and may possibly have been inspired by it, but I don't take credit for hyperscript itself (it was already a concept used by various other systems - the word "hyperscript" itself comes from the name of a project[0], and there were already other similar frameworks like mercury[1] at the time). For mithril.js specifically, the hyperscript variation offers an extra feature that AFAIK not many other libs do: the ability to write emmett-like CSS expressions as the tag name (e.g. `m('input.required[type=password]')`). Totally understandable if you think that's too much sugar for your lib, but I've found it handy for usage with CSS frameworks like bootstrap. Mithril.js users also appreciate it and some interesting unexpected patterns came out of that (e.g. `const Foo = '.some.tailwind.thing'; <Foo />`) BTW, funny story: mithril.js partially took inspiration from an ancient library called dōmo[2] which - as it turns out - uses the tags-as-functions pattern. [0] https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript [1] https://github.com/Raynos/mercury https://github.com/Raynos/mercury [2] https://jed.github.io/domo/ https://jed.github.io/domo/

xyst 6y ago

https://xkcd.com/927/ https://xkcd.com/927/ going to make a hello world app using skruv so I start the timer on my skruv exp

pjmlp 6y ago

Love it, that is how I do Web development when I control the development stack.

h3rald 6y ago

Interesting project! I recently created something similar[1] because I wanted a simple, easy to use, bloat-free micro framework to create single page applications. I also wanted it to be somewhat "battery-included" and provide things like routing and state management out of the box. I think skruv comes with even bigger batteries (SVG support, Shadow Dom integration and additional vdom related apis), and I am curious to see how they all play together. The one thing that does seem a bit weird is the html helper functions... like Mithril, I went straight for hyperscript: I think it is very underrated right now but it is actually a good way to write a dom tree -- and you also get JSX support (nearly) for free. Anyhow, keep up the good work, I think the world needs more micro frameworks like these: powerful but simple enough to be understood and extended easily if needed. [1]: https://h3.js.org https://h3.js.org

SahAssar 6y ago
Thanks! I haven't built in a router yet, but I'll publish the one in the Tutorial as a separate package as soon as I feel it covers enough use-cases. On hyperscript: I prefer to keep the tag name separated from selectors, to me stuff like element type and classes/id's belong in different places and with css scoping built in I think you won't need as many classes so hopefully it won't be a big issue. In general I want the vDOM/HTML stuff to be a pretty direct abstraction on the HTML/DOM in the browser. On JSX: There is a generic `h` function builtin that can be used as a target for JSX. I'll put together an example of it in the coming days. I still want the recommended way to use the framework to be without build steps, parsing or dependencies though.

phpisatrash 6y ago

YAJF - Yet Another JavaScript Framework

Semiapies 6y ago

A framework to do... What? Is this another view layer? "Framework" actually has a meaning beyond "JS library". I'd normally not make this complaint, but the entire home page only tells me what it isn't and some traits it doesn't have, aside from the hint it does weird things to CSS. (I tried to look at the tutorial, but it was a mess on my tablet.) It doesn't tell me why I might actually want to use it. After all, there's no library so concise that it wins the LOC comparison against not including it in a project.

ipaddr 6y ago

You're framework doesn't render on an older chrome android browser.