korynunn
It's Australia only for now, which has no crime :P
It was useful to me so I figured I'd see if it was useful to others.
Pretty fun little project to build.
Show HN: Debug Some JavaScript, Weep
Here's what I got to for my own usage: https://howshouldyoupayforyournextphone.now.sh/#eyJlcnJvcnMi...
Show HN: How should I buy my next phone
I've used both for years, feel free to critique fastn when you've tried it for a week.
If you like light, fast, opinion free UI tools, maybe give my module fastn a go: https://GitHub.com/korynunn/fastn
PS: I'm the most Anglo-Saxon Aussie you've seen, I just wanted to make use of the 'now.sh' domain.
Show HN: How much is my life costing now
Show HN: Evolutionary Neural net. Surprising complexity from simple neurons
I Promise this was a bad idea
npm un --save lodash
Potatoscript – How JavaScript works, explained with potatoes
var input = crel('input', {type:'email'});
vs:
var wrapper = document.createElement('div'); wrapper.innerHTML = '<input type="email">'; var input = wrapper.children[0];
righto crel cpjax sea-lion dion keysdown badwords
Show HN: Vanilla JavaScript game with a bare-essentials node server
Show HN: ES-6/next/whatever. Whats in it, whats good, and whats shit
- I'm defining a web-app as something that feels like an application, not a website. If you are making a news site, fastn probably isn't the way to render everything. You can however just use fastn enhanced functionality, since it isn't a framework, just a tool to make chunks of UI.
- on average, 99% of users have JavaScript installed. As above, if your target audience is `literally everyone`, sure, fastn probably isn't the way to go. Having been a library developer for nearly a decade now, I am intimately aware that different browsers have differences. Fastn should work the same on all modern browsers, and if you find any bugs, let me know and I'll fix them :).
- Delays from loading additional files will be negligible. Not sure how to back that statement up tho ¯\_(ツ)_/¯
- As mentioned, rendering a fastn app on the client is very fast, faster than serving an equivalent page from ASP.net for example, even in a 1:1 race. The issue with server-side templating is that there is one server rendering N requests, whereas with client-side rendering, the N clients are doing the heavy (actually pretty light) lifting.
- I spend an enormous chunk of my time doing performance analysis and improvements. Have a look at recent commits to fastn or enti (the databinding module) and you will see quite a few commits with "performance" in them. We have non-trivial applications using fastn that perform at extremely acceptable speed (hundreds of fields, with live validation, across multiple tabs, renders in around 150ms)
- My work PC is only a few times faster than my Nexus 5. Btw, the homepage renders in 1.2s(~500ms JS) on my phone.
I hope you do give it a go. Fastn isn't a tool for every job, that's the point, it's just a tool. It's up to the developer to decide if it is appropriate.
It has been developed mostly with cordova apps in mind (and yes, they have been made with it, and are quite snappy), where abandoning HTML is actually really nice. It makes writing apps more like how you would do it native, in code, not a markup language.
Privacy (JS off): You can't make a complex web-app without JavaScript, and statistically speaking, everyone has it on always.
Performance: This can be measured in may ways.
- Server time: fastn is just static files, so server time is negligible.
- Transport time: fastn apps are often smaller than the DOM they produce, so server-side rendering the content first would only slow down load times. The trivial example app is 31KB, a large AWS-like application at work is about 40KB.
- Initialisation time: fastn is very fast. On my old slow work PC, the homepage loads 165ms after page ready, and its about a 700ms wait from hitting the refresh button, to everything being shown.
But then, judging by your "paper to cardboard" comment, you aren't here to discuss pros 'n cons :)