3 ms·

In 2007 I said that the future of all apps is html/js/css. I knew the front-end space was going to get complicated (it did) and that to really change the game (

In 2007 I said that the future of all apps is html/js/css. I knew the front-end space was going to get complicated (it did) and that to really change the game (ie, force a standard in UX) it would have to be web based. I wrapped chromium in a Java applet for travel kiosks (now mobile is king), I wrapped chromium in C#, in Python, in Go, all to make web tech the standard. I loved electron before it got bloated, I found NW.js before that and wished it was more popular and had more love. I contributed a swig wrapper to webview to support any language you wish (swig interface naming amalgamations aside). Keep going!!! I want a world where I can write an app for any platform and it spits out some standardized UI that could be augmented with some CSS. I’m super interested in this.

davidpaulyoung 4y ago
Just like the old Joyent "Slingshot". https://daringfireball.net/linked/2007/03/23/slingshot https://daringfireball.net/linked/2007/03/23/slingshot
jancsika 4y ago
> I found NW.js before that and wished it was more popular and had more love nw.js made me appreciate HTML5 so much. I ran into bugs with literally every single nw.js API I used in the application. Here's a taste: * nw.js window menu: arrow keys don't properly navigate across menus, accelerator shortcuts randomly break (bog standard ones like <ctrl-1>), some weird race condition displaying the menu which affects the dimensions of the document that get returned by the DOM, inability to change an accelerator shortcut during runtime, and many, many more * at one point, the nwworkingdir attribute for input tags didn't work unless I injected the tag/attr/value as innerHTML * win.zoom and menu.popup didn't play well together * many others On the other hand, the only HTML5 limitation I can remember was that SVG's getbbox will include clipped content in the returned bounding box. There's apparently a newer option to exclude the clipped areas, but AFAICT it isn't honored in any of the browsers. So each time a user would submit a bug, I'd get a sinking feeling because I just knew it'd be some weirdness in one of the nw.js APIs which would have scant documentation. If that turned out to be the cause of the bug it would either be unfixable or require really nasty kludges to work around. (E.g., at one point nw.js didn't play well with the @font tag, but after hacking I figured out that it would work if I included the font inline in the relevant css as a data url.) On the other hand, if the bug had to do with my own buggy js code or a misunderstanding of the DOM, I'd get excited because I knew there'd be 1000 pages of documentation, 10 years of various workarounds (most with code examples on SO), and probably even a blog with smooth animations showing why that part of the DOM works the way it does.
deleted 4y ago
[deleted]

davidpaulyoung 4y ago

Just like the old Joyent "Slingshot". https://daringfireball.net/linked/2007/03/23/slingshot https://daringfireball.net/linked/2007/03/23/slingshot

jancsika 4y ago

> I found NW.js before that and wished it was more popular and had more love nw.js made me appreciate HTML5 so much. I ran into bugs with literally every single nw.js API I used in the application. Here's a taste: * nw.js window menu: arrow keys don't properly navigate across menus, accelerator shortcuts randomly break (bog standard ones like <ctrl-1>), some weird race condition displaying the menu which affects the dimensions of the document that get returned by the DOM, inability to change an accelerator shortcut during runtime, and many, many more * at one point, the nwworkingdir attribute for input tags didn't work unless I injected the tag/attr/value as innerHTML * win.zoom and menu.popup didn't play well together * many others On the other hand, the only HTML5 limitation I can remember was that SVG's getbbox will include clipped content in the returned bounding box. There's apparently a newer option to exclude the clipped areas, but AFAICT it isn't honored in any of the browsers. So each time a user would submit a bug, I'd get a sinking feeling because I just knew it'd be some weirdness in one of the nw.js APIs which would have scant documentation. If that turned out to be the cause of the bug it would either be unfixable or require really nasty kludges to work around. (E.g., at one point nw.js didn't play well with the @font tag, but after hacking I figured out that it would work if I included the font inline in the relevant css as a data url.) On the other hand, if the bug had to do with my own buggy js code or a misunderstanding of the DOM, I'd get excited because I knew there'd be 1000 pages of documentation, 10 years of various workarounds (most with code examples on SO), and probably even a blog with smooth animations showing why that part of the DOM works the way it does.

deleted 4y ago

[deleted]