lassejansen

The main reason for using a stack was reducing verbosity because for short scripts using variables felt unnecessary when the type-prefix of the command already communicates the variable contents. But it could still be a good idea to have a shorter syntax for assigned variables.

Accessing a variables works like this at the moment:

  <selection-set-text $text="varname">

Keeping the dollar syntax, setting the return value to a named variable could look like this:

  <response-get-text $="varname">

DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem.

You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g.

  <request-send url="..."> // returns response
  <response-get-text> // looks up response on the stack and returns string
  <selection-set-text> // looks up string on the stack and writes it as text content to the current DOM element.

I think the approach of HTMX is that UI state is primarily managed by delegating DOM updates to the server and then modifying the DOM with the response.

With hyTags one can do a lot of things without server calls and without resorting to javascript (e.g. inserting and deleting new rows, showing a loading indicator, validating input, animations, ...).

For most tags you can also put the event handlers as first children inside the element, but self-closing tags like <input> don't support that. I'm now putting the event handlers always outside (as next siblings) for consistency.

Exactly, code is data ;)

It's only frontend logic. There is a small runtime that is implemented in Javascript interprets html tags. Backend logic needs to be implemented on the server.

Thanks dang!

The main reason for using tags was for me that they can be generated from a host language and stay readable, even for longer scripts. I'm using Swifts result builders for my projects, which enables autocompletion and partial type safety.

I did a Show HN for the language "hyTags" yesterday, too. It's a language embedded in HTML, using tags as syntax. It quickly dropped of the new page:

https://news.ycombinator.com/item?id=46599403

Could you add that too to showlang?

Or, phrased differently, if n has an upper limit, the algorithm is O(1).

I'm using Swift Result Builders as a statically typed language to generate HtmlScript code (which a similar approach as html, the programming language):

https://htmlscript.org

This works pretty well for composable server side generated view components.

So how does it work if a library owner changes something in his library—do they have to update all projects that depend on it and then push this as a single commit?

Not sure if "recent" is the correct attribute for DSLs in Ruby.

https://www.infoq.com/news/2007/06/dsl-or-not

The Sapper version is cheating a little. It is preloading the pages on mouseOver events of the links.

One great application of this would be to hide the unsubscribe link if the email is forwarded.

I don't understand. Would't each of your 8 million followers get one push notification instead of you getting 8M when you post something?

About half a year ago. It turned 1500 lines of Dart into ~10000 lines of Javascript. That might not be that much to handle for a webview but it was quite hard to debug. I used it as a UserScript in WKWebView so I couldn't use DartEditor. In comparison, the haxe code, which looked very similar to the Dart code, was compiled into 1400 lines of pretty readable Javascript.

I tried Dart when looking for a typed language that compiles to Javascript. It was nice but in the end I used haxe because it had a much smaller footprint. Dart seems to include its own library while haxe sticks close to what Javascript offers.

Related discussion by John Carmack:

http://number-none.com/blow/john_carmack_on_inlined_code.htm...

https://news.ycombinator.com/item?id=8374345

Cached:

http://webcache.googleusercontent.com/search?q=cache:LQgMUMT...

I don't think it's useful to extract every guard statement into a separate function. Consider importing a json file where each field could potentially contain invalid or missing data. Sure, you could create functions like parseTitle, parseSubtitle, parseAuthorName etc. but these functions will probably only be called from one place and I don't think they improve readability.

On the other hand, I do think that larger functions should be broken up into smaller parts where it makes sense, e.g. a separate function for parsing each object in the json example.

As the article mentions Unibox: If somebody is interested in giving the beta version of Unibox for iOS a try, send me an email: lasse.jansen@eightloops.com.

Unibox groups emails by person. It's different, but it really helps you staying organized.

https://www.uniboxapp.com

Interesting, the compiler seems to be implemented in C++.

[Disclosure: I'm a co-founder]

If you're open to new approaches to email you should try Unibox. It's an email client for Mac (and soon iOS) that lets you browse through your emails by person, so you always have all messages and all attachments with a person in one place.

https://www.uniboxapp.com

Did anybody find information regarding namespaces?

Hm, doesn't let me reduce the number to zero.

Unibox has this: http://www.uniboxapp.com/faq/attachments/list

Unibox works pretty well for newsletters and notifications. They get grouped into one contact by sender, so e.g. 4 Twitter notifications only take one slot in the contact list.

It works also really well for notifications that contain attachments. If you have e.g. a github account that sends invoices you can select the Github Billing contact, go to the attachment list and have all invoices in one place. I don't copy attachments to the filesystem anymore because it's much easier to find them in Unibox.

Yes, we're checking MX records.

If you send us an email to support@uniboxapp.com we'll ping you as soon as we're able to provide a trial version.

Unibox is a fully native OSX app, webviews are only used for rendering the HTML email content.