15 ms·

The web as a GUI toolkit

155 points by pcr910303 7y ago

mrec 7y ago
> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. As someone else who cut their teeth on an 8-bit micro back in the day, I agree with this 100%. And I think it's a large part of the reason I'm so suspicious of the stampede in webdev toward very heavyweight toolchains over the past 5+ years; while they may have had the best of intentions, I think they do end up putting gatekeeper-ey accessibility barriers around the web's original rough democracy. It's not that the underlying technology has gone away, more that when someone starts looking around the mainstream web to see how things are put together, that's not what they're going to find.
- jaywalk 7y ago
  Are you saying that we shouldn't have the advanced web applications that we do today?
  - DougWebb 7y ago
    I would say that we shouldn't have an advanced web application unless we need an advanced web application. Most of the time, we really don't need it.
    - andai 7y ago
      You must enable JavaScript to view this static text blog.
  - bdcravens 7y ago
    This presumes that heavy toolchains are a prerequisite of advanced web applications. The toolchains seem to be more about ergonomics than creating new capabilities.
    - WorldMaker 7y ago
      A large part of the toolchains are also bandaids on a lot of unnecessary friction caused by changing standards and moving targets. The web platform is almost to the point where a lot of those bandaids could just be ripped off: ES2015 modules are directly supported in most browsers today, same with CSS modules / syntax through ES2017 or more recent / and so forth, and protocol upgrades in HTTP2 and HTTP3 remove a lot of the performance-specific needs for things like bundling and minification. The biggest hurdle to ripping off the bandaids (as with so many things in software development) is the rough edges of the long tail of legacy code. The biggest example being that there's still so much code written for CommonJS (or AMD) that needs shims to play well in ES2015 module worlds. (Because no one wants to stop the Node world and rewrite everything all at once.)
      - fwip 7y ago
        pika.dev is coming really close to shimming a ton of existing libraries into module world.
  - thrower123 7y ago
    I can't think of a case in the past decade where I've really wanted to have a web application rather than a proper native thick client. I understand the attraction, and I've had to build my fair share of them, but I don't like it at all.
  - mrec 7y ago
    I'm not at all convinced that the heavyweight toolchains have led to any improvement in webapp quality. Maybe there are rockstar apps out there I just haven't seen, but for the most part the web these days is vastly more bloated and somewhat less stable than it used to be, without doing anything more that any user actually wants. This is not progress.
  - pjmlp 7y ago
    Actually yes, we don't need SPAs to display basic blocks of text with some animation.
- IshKebab 7y ago
  I agree. Node, webpack, npm, babel, etc. all add a huge amount of friction to getting started. It doesn't help that they're all overly complex and every little thing has a different tool or configuration file. It's a huge complex house of cards that nobody really wants to have to deal with. Compare it to writing a Qt app, or even something like a Flutter app. You pretty much just install an SDK and go file -> new project.
  - AnIdiotOnTheNet 7y ago
    Or compare it to something like Lazarus, where you install the environment (sadly it is not at all portable) and can construct GUI applications with a WYSIWYG editor that compile directly to native binaries for multiple platforms.
    - unlinked_dll 7y ago
      GUI editors always go in cycles, and we always come back around to writing code as the editors can't represent the things we want to do.
      - AnIdiotOnTheNet 7y ago
        Except for a huge number of use cases where they can, of course. Obviously not everything can be abstracted away, but things like Lazarus or HyperCard or even Excel offer a starting off point for people to build powerful tools to solve their problems without acquiring a traditional programming education, and offer a ramp into programming for when people need to do more with those tools.
  - kls 7y ago
    Personally I would argue that it is no more complex than JSP/JSF/Spring or ASP.NET/Web Components / Web Forms, then you have to bolt on server side session management, state transfer and the other patterns that emerge from sending everything to the server. In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management. Now I would tend to agree that classic ASP / PHP was conceptually simple and probably simpler than the current client side landscape, but they where beasts at scale. I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities into the mix that you circumvent with desktop where you are delivering from the run-time up. For better or worse, the browser, the webserver and the middleware stack all dictate how we get to go about building applications for the web.
- xyz0 7y ago
  Sure, modern JS tooling is complex, but a 14-year-old just looking to play around with programming isn't going to build a Facebook clone as their first project. You can always create a barebones HTML file and drop some JS into a `<script>` tag and be up-and-running in two minutes. If you don't want to use modern tooling that was designed for large-scale SPAs, then don't.
  - GuiA 7y ago
    In my experience teaching 14 year olds, that is precisely the kind of thing they first want to build: the things they know and use everyday (in 2020 it’s more likely to be Snapchat/Instagram/TikTok than Facebook, but the point remains). And indeed, with a batteries included kind of solution like PHP/MySQL, one can build a basic Facebook like in a week long workshop or so. You won’t understand everything that’s going on under the hood of course, but the fact remains that it’s way more accessible than the webpack/Babel/react.js/etc stacks that web devs push these days (waiting for the inevitable “oh no one uses webpack anymore, it’s all about ChirpChirp.js these days!” :)
  - kart23 7y ago
    I was really turned off by react because of the necessity to use JSX, which in turn required me to use babel, its just adding too much complexity. So I'm still just using jquery.
    - hastes 7y ago
      I would look into CRA (https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app). It handles all the Babel/Transpiling/Webpack mumbo-jumbo for you so you can focus on writing code. Although I would eventually recommend learning how to utilize Babel & Webpack yourself because knowing why and how it works is useful.
      - brlewis 7y ago
        If kart23's objection to complexity is how long it takes to get up and running, I agree about CRA. I agree about knowing the why of Babel and Webpack. But how they work isn't something everybody has to learn. If it's some other objection to complexity, I'd recommend learning modern web dev using https://mithril.js.org/ https://mithril.js.org/ which can use JSX, but in documentation the non-JSX form is primary.
- spankalee 7y ago
  Luckily you can now use standard JS modules and web components to nicely organize code and widgets without buying into any tooling or framework. Things are getting a lot better.
  - lucasverra 7y ago
    do you have a sample app / repo to illustrate ? You can use repl.it to host
  - Vinnl 7y ago
    But then you're buying into Web Components and their limitations instead. Luckily, whatever people could do in the pas, they can still do today, because the web is largely backwards compatible. Then at some point they'll run into some things that seem harder than they need to be, at which point they can start looking at the tooling that was designed to solve those exact problems.
- divbzero 7y ago
  > With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. For this same reason, I’m disappointed that mobile browsers such as iOS Safari have yet to enable DevTools, e.g. a page inspector, network inspector, and JavaScript console. Especially for younger generations, there are many whose first computer will be a mobile device.
  - pjmlp 7y ago
    They are enabled, kind of, you need to plug the device into its bigger brother. However, iOS more so than Android, has plenty of mature interactive code environments.
    - divbzero 7y ago
      > you need to plug the device into its bigger brother This exactly is the challenge. If your first computer is a mobile device, you would not have that “bigger brother” available. iOS does have Swift Playgrounds [1] and Android has the excellent Termux [2] but access to the built-in JavaScript engine would open a whole new set of possibilities. [1]: https://www.apple.com/swift/playgrounds/ https://www.apple.com/swift/playgrounds/ [2]: https://termux.com/ https://termux.com/ I was introduced to programming on a dinky little graphing calculator. My hope is that other “first computers” could offer similar opportunities for tinkering.
      - pjmlp 7y ago
        Agreed, but as mentioned there are also on device coding environments. On iOS you also have Pythonista, Continuous, Shaderific, Codea, all much better than learning FX-4500p, FX-850P Basic. Sadly on Android, most of the alternatives are quite lacking versus the iOS variants in capabilities and quality.
skrebbel 7y ago
Kinda off topic, but the MSX was amazing. We had one too, it was my first computer too. I vividly recall it came with two 200-odd page printed manuals, both in my native Dutch. One for MSX-DOS, which told you how to launch a word processor and print documents. And one for MSX-BASIC. The manual, sent to every consumer's home, taught you what variables and subroutines were. It had pictures of jars with $A printed on the outside that you could put a 5 in and the later put a 6 in. In Dutch! In my home! I was 10. I was learning programming but I didn't know I was - I thought I was just learning the computer. Years later my parents got me a "programming with superlogo" book and only then I discovered that I already knew how to program. That was pretty odd. <3 MSX and whichever Philips exec decided that consumers needed programming language manuals.
- AnIdiotOnTheNet 7y ago
  > I was learning programming but I didn't know I was - I thought I was just learning the computer Back then these were not really separate concepts. Frankly, I don't think they should be nearly as separate concepts today either but nearly everyone making software seems to disagree.
  - andai 7y ago
    One thing I hope will come out of a more code literate society (looks like a lot of high schools are teaching it now) is that, all software will be written assuming every user knows at least some scripting. Often I clone a piece of software because I want to change just one thing, or even if it's open source I often need to set up a build environment etc... and I just wanna change like one integer!
    - AnIdiotOnTheNet 7y ago
      > all software will be written assuming every user knows at least some scripting. I don't know if that's what the answer is. I prefer the idea that computer usage naturally flows into computer programming. Take the most used programming environment in the world: Microsoft Excel. It can be used very simply as a table of words and numbers, but if you want to do more with it there are formulas, and when you reach the limit of that there's VBA. We used to have tools like HyperCard that allowed people to build simple GUI applications with no traditional programming language whatsoever, but also had one baked in for when you grew beyond the WYSIWYG editor's capabilities. That sort of thing basically no longer exists, and to the extent it does it is merely a copy of what existed before instead of an evolution. > Often I clone a piece of software because I want to change just one thing, or even if it's open source I often need to set up a build environment etc... and I just wanna change like one integer! Yeah, it'd be really great if more software was written with flexibility in mind. I want to have an API for interfacing with everything, I want to setup my own custom hotkeys, etc. I can kind of get there today with things like AutoHotKey, old Macs had AppleScript, Plan9... existed, but it is kind of ridiculous that this sort of thing isn't baked in to modern computing.
granshaw 7y ago
Ctrl+F ability is so understated. I often use mobile sites rather than their respective apps precisely so I can Ctrl+F to find what I'm looking for on the page quickly
- GuB-42 7y ago
  To be honest, many apps are nothing more than a crippled browser showing you a website. Also: https://xkcd.com/1174/ https://xkcd.com/1174/
themodelplumber 7y ago
This seems a good starting point for a complex yet possibly constructive tool-related discussion. I recently started building a bunch of personal productivity and hobby apps using Lazarus / Free Pascal, because there are quite a few things I didn't want to deal with from the web development world: - Constant browser upgrades that can instantly change how well your JS tools work, especially if you integrate third-party components like CKEditor - The sheer number of different types of updates that are spread across various front- and back-end contexts: HTML, CSS, JS, and PHP/More JS/whatever, but then you've also got to consider your choice of editor / coding environment, whether you're using SASS, any deployment tools, fonts and font services, etc. - Having a single binary to use vs. needing to open a web browser which will then try to tie everything together for you, meanwhile maybe you have good reason not to be using a web browser at all - Working with tons of files that exist locally, and will always exist locally, and which you don't want to add to a server or the cloud (doable via the web tools but just a bit weird in its way) It's been nice to just build a thing I need and see it immediately fit into normal native desktop app characteristics, meanwhile I can focus on the productive logic and workflow. But that doesn't really even sum it up, does it? You can do _something like that_ on the web...it's just different. I found myself with ample time to design an icon for my latest desktop app, having completed all the main functions, and caught myself smiling at the thought--it was a good feeling.
- asdasdasdasdwd 7y ago
  Decades ago I discovered HTA (Html Applications). It was a program from MS that let you build applications using a single html file. It had no browser UI in it, had it's own button in the menu bar, and other than the default white background it looked like a native application. All you needed to update it was to edit the file and reload the application, no compilation step needed. You could embed scripts and styles and even images so it could be one file if you wanted. I used it for building small toy apps. It was the times of IE5, I didn't really care about browser upgrades. Better of all, the files were small and you didn't need to package an executable since all Windows machines had the executable already.
- Sophistifunk 7y ago
  Does Lazarus have a good GUI story on MacOS yet?
reggieband 7y ago
I am extremely negative on HTML/CSS as a ui framework. Yet like many, I have been paid well to come over to the dark side of Javascript app development. The opening section in this article is one of the first times I've agreed with some positive view on the benefits of the environment. Zoom really is a cool feature that is not easily possible in more traditional GUI frameworks. I also have to begrudgingly admit that nowadays I can mostly create really nice interfaces with very little effort. This is thanks to browsers finally reaching an acceptable level of compatibility (anyone remember Acid CSS test), Javascript/Typescript evolving with genuine improvements (e.g. async/await), flex layouts (and soon grid!). There is still huge room for improvement but it isn't anywhere near as bad as it once was.
throwGuardian 7y ago
Agree with all the pros stated in the article. However, there are cons: 1. Each desktop app is shipping almost a full browser, updating it independently and bloating RAM, storage and CPU utilization in the process. 2. RAM/CPU bloat issues are real - even the V8 team advices against overreliance on excess RAM. They've noticed a speed increase in the process of releasing V8-lite aimed at aggressive gc 3. Even amongst the most mature GUI frameworks based on html/js, there's far too much overhead for trivial things, like reading/writing to file. For instance, in electron, since the browser V8 context isn't allowed willy-nilly storage access, a file read from the browser V8 goes across a couple IPC requests to complete. Also, these hops aren't widely documented and understood, making desktop apps janky by default, instead of fast by default
- sdegutis 7y ago
  I wonder what would happen if all major OS & Browser vendors decided to agreed on a long-term plan to migrate/evolve the HTML, CSS, and JS specs & implementations towards a functional equivalent variation that could be efficiently implemented with the same semantics and level of security (or better) but with far less CPU and memory inefficiency, removing indirection and dynamic abstraction layer by layer, until suddenly we get something that has all the legitimate benefits of modern web development, but with the same memory/CPU footprint of Cocoa or .NET, being also cross-platform and built into every OS. Wouldn't that be great?
  - jerf 7y ago
    Before that can happen, we'll get WebASM + WebGL interfaces (efficiently) in our browser. I expect an explosion of alternate layout mechanisms to arise from that. They won't be very good at first, but they may end up somewhere neat.
    - c-smile 7y ago
      > I expect an explosion of alternate layout mechanisms. No need WebASM for that. Just one CSS property: div { flow: custom [funcname/url(of-layoout-controller)]; } + single function funcname() that will replace children and report min/max intrinsic sizes.
c-smile 7y ago
If to speak about browser technology as a GUI toolkit then there are three big things that are greatly underestimated. 1. Bubbling/Sinking(Capturing) event propagation schema. With that schema a container knows what event is passed to a child and did child process it or not. On desktop, windowed widget handles all its events without notifying/asking its container. This actually is pretty big - it enables composition of atomic input widgets. On Web you can use <input|text> as part of more complex widget. 2. CSS and CSS selectors in particular. As the way of styling component from outside - independently from its event handlers/code. So code changes DOM state and CSS defines how that state shall be presented. And not only that but styling of elements in context (cascading). That is "separation of concerns" at its best. 3. And the DOM. While each UI system has DOM ( tree of windows/widgets ) in one form or another the Web pushes its further: it adds unification of widget (attributes/states) interface. Any widget or element may have ID, class or other attributes defined. And those can be used for styling.
- admax88q 7y ago
  In practice CSS rarely lives up to the aeparation between state and presentation. In most projects the to are updated in tandem. DOM is not expressive enough to represent state, it moreso represents UI state, but CSS also represents UI state.
  - c-smile 7y ago
    That is more about architecture actually. Ideally Web/UI component has two sets of styles: So called "primordial" or "base" - the one that defines layout of sub-components and parts and that is essential for component operation. And another set is about decoration - colors, fonts, sizes. For example in Sciter (https://sciter.com https://sciter.com) component is defined by so called style sets: @set nullable-input-base { :root { flow:horizontal; } :root > input { display:block; width:*; } :root > button.clear { display:block; } } // concrete nullable-input styling: // derives from nullable-input-base @set nullable-input < nullable-input-base { :root { background-color: var(inputback) } :root > button.clear { width:2em; background: url(x-cross.svg) 50% 50% no-repeat; } } And in script: class NullableInput : Reactor.Component { const styleset = ["nullable-input", url("widgets.css") ]; function render() { return <widget.nullable-input> <input|text /> <button.clear /> </widget>; } } This way you can redefine nullable-input in the way you want without putting any styles into code.
austincheney 7y ago
Building a browser GUI is simple. I would even argue extremely trivial. Here is a video demo of one I built in the not too distant past (github link at the end): http://mailmarkup.org/sharefile/demo1.mp4 http://mailmarkup.org/sharefile/demo1.mp4 It took me a little more than 2 weeks to write and test the GUI in that video. From this experience I have learned the following: * If you are comfortable working with the DOM and vanilla JS you should be spending more effort writing the content and services that populates the GUI rather than the GUI itself. I would say this ratio of time should be something like 20% GUI and 80% content starting out and scaling towards greater content effort as the requirements upon the GUI increase. * A JavaScript based GUI can be extremely fast and responsive. The video demo was captured on a 4k resolution and it performs, at least to human interaction speed, just as responsively as the OS's GUI even in VMs. That high resolution also explains why the video text is hard to read on a small mobile device. I intentionally wrote this to be fast though using vanilla JS and the standard imperative DOM methods, because that is the fastest way to execute things in the browser. It stands to reason if you go about things in a much slower way it will likely perform slower, possibly slow enough that the user notices a huge difference. * A JavaScript GUI can be extremely lightweight with tiny code. This is only true if you are comfortable working with the DOM without a bunch of code decoration and abstraction nonsense. * If the code is organized well it will scale well even in the face of numerous competing enhancements. I solved the problem of scale with TypeScript interfaces and constant refactoring. * There is one aspect that does not scale well, which any feature that requires complex algebra. One example is dragging a highlight rectangle over some elements for a mass selection and ensuring that highlight rectangle is confined to the containing element and that it knows which elements of the parent element are visually occupying the same space and which ones aren't. Another example is that the CSS property text-overflow only works if dimensions are statically available to the current element or its parent node. That means calculating a dimension for an element in order to set the value upon the element, which requires some calculation written by you instead of relying upon something like display:block;width:auto. * All presentation, and I do mean absolutely everything except dynamically modified display, opacity, position, and specified dimensions should be in CSS. The presentation that is not in CSS is directly on the DOM node by dynamically reassigning new presentation values on user interaction where necessary. This allows for smaller and more scalable code. * All icons are Unicode characters. The only one other graphic, because the desktop background, is an SVG spinner. SVG, being XML, can be adjusted with CSS just like the rest of the DOM.
mrighele 7y ago
I had a similar experience in my youth (just replace the MSX with a C64). The author is right when he says that programming a PC (either in DOS or Windows) was non obvious; but once you realized that the best way was to use a spreadsheet or a database engine, you could get a lot done quite easily. Those tools may not be as generic as Python or Perl, but you could program whole applications in a fraction of the time. As for the web, I think it is still harder than it could be, and the browsers make it more difficult every day, since they put more and more restrictions when opening a local page.
baybal2 7y ago
Web is very inferior to any modestly well done UI toolkit.
- guggle 7y ago
  As someone who spent most of his time in the last 20 years building web application and only recently (2 years) started using gui toolkits (mostly QT but also wxwindows), I certainly can relate to this. What a breath of fresh air... consistent UI, no fiddling with half-assed components or soon-to-disappear frameworks, no time wasted reinventing the wheel, excellent performance, no markup/code dichotomy... Great results with ease, I wish I made the jump earlier.
divan 7y ago
I'm so on the opposite side of this opinion. To my view, the better tech aligned with the problem domain, the better off are developers and end users. Using typesetting format for rich UI apps is so far from what UI toolkits need and has created enormous amount of pain, losses and security vulnerabilities. Making it the only available option on the dominant software platform (web) made it the worst cataclysm in the UI software industry. Like, in a slightly different turn of events, it could be Lotus or Excel spreadsheets format as a GUI framework. You can easily imagine how XLS becomes the dominant monopoly in UI toolkits and evolve chaotically to accommodate web demand for UI features. After decades of evolution and billions of lines of XLS and VB scripts, one could easily find "some things that work very well" with spreadsheets as a GUI toolkit approach. It doesn't make it a good fit, though. Why would anyone think that using text markup language for UI apps can be a good idea?
nitwit005 7y ago
There's kind of a big bump in using HTML/CSS/JS. It's easy to slap together some simple stuff, or fiddle with a web page, but you'll hit a certain point where you want your app to do something useful. Suddenly you'll be stuck reading about webservers, databases, Electron, and whatever else. In some ways it's still easier to make a basic Java Swing application. You can just install Java and start working through tutorials.
mirimir 7y ago
I mostly write stuff for others, and they do what they want with it. Or for GitHub. But my own stuff only goes on Tor onion sites. So it's strict HTML, because Tor's latency punishes client-server dialog. And also because people will hate on you for scripts. Also, I thought that this might be about WebGUIs. Such as the pfSense WebGUI, which still amazes me in its depth and usability. Or indeed, that you can route the WebGUI of a remote pfSense VM as a Tor onion service, and manage it just as easily as the box in the closet.
dzonga 7y ago
the great thing about the web is universality. no one controls the platform yet. although, that could change, as browser engines consolidate. The web, also allows you to be OS agnostic. most of my work is done via the browser. with the only native programs I run being a media player eg vlc or smplayer since linux doesn't handle gpu video decoding and some terminal windows. with tools like Figma etc. Web programs are here to stay and win. Though we suffer a regression in usability with people who abuse tools like React etc
malkia 7y ago
yup it is :) fossil ui - runs the browser as UI (from https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki) one of the first examples I've seen, but not the only one.
tsukurimashou 7y ago
Funny thing is these three points: - Copy/paste anything. - Search any text with e.g. Ctrl+F. - Back button. Tend to disappear with javascript frameworks, single page applications, ajax, and websites partially or fully rendered with canvas

155 points by pcr910303 7y ago

mrec 7y ago

> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. As someone else who cut their teeth on an 8-bit micro back in the day, I agree with this 100%. And I think it's a large part of the reason I'm so suspicious of the stampede in webdev toward very heavyweight toolchains over the past 5+ years; while they may have had the best of intentions, I think they do end up putting gatekeeper-ey accessibility barriers around the web's original rough democracy. It's not that the underlying technology has gone away, more that when someone starts looking around the mainstream web to see how things are put together, that's not what they're going to find.

jaywalk 7y ago
Are you saying that we shouldn't have the advanced web applications that we do today?
- DougWebb 7y ago
  I would say that we shouldn't have an advanced web application unless we need an advanced web application. Most of the time, we really don't need it.
  - andai 7y ago
    You must enable JavaScript to view this static text blog.
- bdcravens 7y ago
  This presumes that heavy toolchains are a prerequisite of advanced web applications. The toolchains seem to be more about ergonomics than creating new capabilities.
  - WorldMaker 7y ago
    A large part of the toolchains are also bandaids on a lot of unnecessary friction caused by changing standards and moving targets. The web platform is almost to the point where a lot of those bandaids could just be ripped off: ES2015 modules are directly supported in most browsers today, same with CSS modules / syntax through ES2017 or more recent / and so forth, and protocol upgrades in HTTP2 and HTTP3 remove a lot of the performance-specific needs for things like bundling and minification. The biggest hurdle to ripping off the bandaids (as with so many things in software development) is the rough edges of the long tail of legacy code. The biggest example being that there's still so much code written for CommonJS (or AMD) that needs shims to play well in ES2015 module worlds. (Because no one wants to stop the Node world and rewrite everything all at once.)
    - fwip 7y ago
      pika.dev is coming really close to shimming a ton of existing libraries into module world.
- thrower123 7y ago
  I can't think of a case in the past decade where I've really wanted to have a web application rather than a proper native thick client. I understand the attraction, and I've had to build my fair share of them, but I don't like it at all.
- mrec 7y ago
  I'm not at all convinced that the heavyweight toolchains have led to any improvement in webapp quality. Maybe there are rockstar apps out there I just haven't seen, but for the most part the web these days is vastly more bloated and somewhat less stable than it used to be, without doing anything more that any user actually wants. This is not progress.
- pjmlp 7y ago
  Actually yes, we don't need SPAs to display basic blocks of text with some animation.
IshKebab 7y ago
I agree. Node, webpack, npm, babel, etc. all add a huge amount of friction to getting started. It doesn't help that they're all overly complex and every little thing has a different tool or configuration file. It's a huge complex house of cards that nobody really wants to have to deal with. Compare it to writing a Qt app, or even something like a Flutter app. You pretty much just install an SDK and go file -> new project.
- AnIdiotOnTheNet 7y ago
  Or compare it to something like Lazarus, where you install the environment (sadly it is not at all portable) and can construct GUI applications with a WYSIWYG editor that compile directly to native binaries for multiple platforms.
  - unlinked_dll 7y ago
    GUI editors always go in cycles, and we always come back around to writing code as the editors can't represent the things we want to do.
    - AnIdiotOnTheNet 7y ago
      Except for a huge number of use cases where they can, of course. Obviously not everything can be abstracted away, but things like Lazarus or HyperCard or even Excel offer a starting off point for people to build powerful tools to solve their problems without acquiring a traditional programming education, and offer a ramp into programming for when people need to do more with those tools.
- kls 7y ago
  Personally I would argue that it is no more complex than JSP/JSF/Spring or ASP.NET/Web Components / Web Forms, then you have to bolt on server side session management, state transfer and the other patterns that emerge from sending everything to the server. In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management. Now I would tend to agree that classic ASP / PHP was conceptually simple and probably simpler than the current client side landscape, but they where beasts at scale. I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities into the mix that you circumvent with desktop where you are delivering from the run-time up. For better or worse, the browser, the webserver and the middleware stack all dictate how we get to go about building applications for the web.
xyz0 7y ago
Sure, modern JS tooling is complex, but a 14-year-old just looking to play around with programming isn't going to build a Facebook clone as their first project. You can always create a barebones HTML file and drop some JS into a `<script>` tag and be up-and-running in two minutes. If you don't want to use modern tooling that was designed for large-scale SPAs, then don't.
- GuiA 7y ago
  In my experience teaching 14 year olds, that is precisely the kind of thing they first want to build: the things they know and use everyday (in 2020 it’s more likely to be Snapchat/Instagram/TikTok than Facebook, but the point remains). And indeed, with a batteries included kind of solution like PHP/MySQL, one can build a basic Facebook like in a week long workshop or so. You won’t understand everything that’s going on under the hood of course, but the fact remains that it’s way more accessible than the webpack/Babel/react.js/etc stacks that web devs push these days (waiting for the inevitable “oh no one uses webpack anymore, it’s all about ChirpChirp.js these days!” :)
- kart23 7y ago
  I was really turned off by react because of the necessity to use JSX, which in turn required me to use babel, its just adding too much complexity. So I'm still just using jquery.
  - hastes 7y ago
    I would look into CRA (https://github.com/facebook/create-react-app https://github.com/facebook/create-react-app). It handles all the Babel/Transpiling/Webpack mumbo-jumbo for you so you can focus on writing code. Although I would eventually recommend learning how to utilize Babel & Webpack yourself because knowing why and how it works is useful.
    - brlewis 7y ago
      If kart23's objection to complexity is how long it takes to get up and running, I agree about CRA. I agree about knowing the why of Babel and Webpack. But how they work isn't something everybody has to learn. If it's some other objection to complexity, I'd recommend learning modern web dev using https://mithril.js.org/ https://mithril.js.org/ which can use JSX, but in documentation the non-JSX form is primary.
spankalee 7y ago
Luckily you can now use standard JS modules and web components to nicely organize code and widgets without buying into any tooling or framework. Things are getting a lot better.
- lucasverra 7y ago
  do you have a sample app / repo to illustrate ? You can use repl.it to host
- Vinnl 7y ago
  But then you're buying into Web Components and their limitations instead. Luckily, whatever people could do in the pas, they can still do today, because the web is largely backwards compatible. Then at some point they'll run into some things that seem harder than they need to be, at which point they can start looking at the tooling that was designed to solve those exact problems.
divbzero 7y ago
> With the web almost everyone has a machine that has a programmable environment by default again. I feel this is a very important and powerful advantage that’s often overlooked. For this same reason, I’m disappointed that mobile browsers such as iOS Safari have yet to enable DevTools, e.g. a page inspector, network inspector, and JavaScript console. Especially for younger generations, there are many whose first computer will be a mobile device.
- pjmlp 7y ago
  They are enabled, kind of, you need to plug the device into its bigger brother. However, iOS more so than Android, has plenty of mature interactive code environments.
  - divbzero 7y ago
    > you need to plug the device into its bigger brother This exactly is the challenge. If your first computer is a mobile device, you would not have that “bigger brother” available. iOS does have Swift Playgrounds [1] and Android has the excellent Termux [2] but access to the built-in JavaScript engine would open a whole new set of possibilities. [1]: https://www.apple.com/swift/playgrounds/ https://www.apple.com/swift/playgrounds/ [2]: https://termux.com/ https://termux.com/ I was introduced to programming on a dinky little graphing calculator. My hope is that other “first computers” could offer similar opportunities for tinkering.
    - pjmlp 7y ago
      Agreed, but as mentioned there are also on device coding environments. On iOS you also have Pythonista, Continuous, Shaderific, Codea, all much better than learning FX-4500p, FX-850P Basic. Sadly on Android, most of the alternatives are quite lacking versus the iOS variants in capabilities and quality.

skrebbel 7y ago

Kinda off topic, but the MSX was amazing. We had one too, it was my first computer too. I vividly recall it came with two 200-odd page printed manuals, both in my native Dutch. One for MSX-DOS, which told you how to launch a word processor and print documents. And one for MSX-BASIC. The manual, sent to every consumer's home, taught you what variables and subroutines were. It had pictures of jars with $A printed on the outside that you could put a 5 in and the later put a 6 in. In Dutch! In my home! I was 10. I was learning programming but I didn't know I was - I thought I was just learning the computer. Years later my parents got me a "programming with superlogo" book and only then I discovered that I already knew how to program. That was pretty odd. <3 MSX and whichever Philips exec decided that consumers needed programming language manuals.

AnIdiotOnTheNet 7y ago
> I was learning programming but I didn't know I was - I thought I was just learning the computer Back then these were not really separate concepts. Frankly, I don't think they should be nearly as separate concepts today either but nearly everyone making software seems to disagree.
- andai 7y ago
  One thing I hope will come out of a more code literate society (looks like a lot of high schools are teaching it now) is that, all software will be written assuming every user knows at least some scripting. Often I clone a piece of software because I want to change just one thing, or even if it's open source I often need to set up a build environment etc... and I just wanna change like one integer!
  - AnIdiotOnTheNet 7y ago
    > all software will be written assuming every user knows at least some scripting. I don't know if that's what the answer is. I prefer the idea that computer usage naturally flows into computer programming. Take the most used programming environment in the world: Microsoft Excel. It can be used very simply as a table of words and numbers, but if you want to do more with it there are formulas, and when you reach the limit of that there's VBA. We used to have tools like HyperCard that allowed people to build simple GUI applications with no traditional programming language whatsoever, but also had one baked in for when you grew beyond the WYSIWYG editor's capabilities. That sort of thing basically no longer exists, and to the extent it does it is merely a copy of what existed before instead of an evolution. > Often I clone a piece of software because I want to change just one thing, or even if it's open source I often need to set up a build environment etc... and I just wanna change like one integer! Yeah, it'd be really great if more software was written with flexibility in mind. I want to have an API for interfacing with everything, I want to setup my own custom hotkeys, etc. I can kind of get there today with things like AutoHotKey, old Macs had AppleScript, Plan9... existed, but it is kind of ridiculous that this sort of thing isn't baked in to modern computing.

granshaw 7y ago

Ctrl+F ability is so understated. I often use mobile sites rather than their respective apps precisely so I can Ctrl+F to find what I'm looking for on the page quickly

GuB-42 7y ago
To be honest, many apps are nothing more than a crippled browser showing you a website. Also: https://xkcd.com/1174/ https://xkcd.com/1174/

themodelplumber 7y ago

This seems a good starting point for a complex yet possibly constructive tool-related discussion. I recently started building a bunch of personal productivity and hobby apps using Lazarus / Free Pascal, because there are quite a few things I didn't want to deal with from the web development world: - Constant browser upgrades that can instantly change how well your JS tools work, especially if you integrate third-party components like CKEditor - The sheer number of different types of updates that are spread across various front- and back-end contexts: HTML, CSS, JS, and PHP/More JS/whatever, but then you've also got to consider your choice of editor / coding environment, whether you're using SASS, any deployment tools, fonts and font services, etc. - Having a single binary to use vs. needing to open a web browser which will then try to tie everything together for you, meanwhile maybe you have good reason not to be using a web browser at all - Working with tons of files that exist locally, and will always exist locally, and which you don't want to add to a server or the cloud (doable via the web tools but just a bit weird in its way) It's been nice to just build a thing I need and see it immediately fit into normal native desktop app characteristics, meanwhile I can focus on the productive logic and workflow. But that doesn't really even sum it up, does it? You can do _something like that_ on the web...it's just different. I found myself with ample time to design an icon for my latest desktop app, having completed all the main functions, and caught myself smiling at the thought--it was a good feeling.

asdasdasdasdwd 7y ago
Decades ago I discovered HTA (Html Applications). It was a program from MS that let you build applications using a single html file. It had no browser UI in it, had it's own button in the menu bar, and other than the default white background it looked like a native application. All you needed to update it was to edit the file and reload the application, no compilation step needed. You could embed scripts and styles and even images so it could be one file if you wanted. I used it for building small toy apps. It was the times of IE5, I didn't really care about browser upgrades. Better of all, the files were small and you didn't need to package an executable since all Windows machines had the executable already.
Sophistifunk 7y ago
Does Lazarus have a good GUI story on MacOS yet?

reggieband 7y ago

I am extremely negative on HTML/CSS as a ui framework. Yet like many, I have been paid well to come over to the dark side of Javascript app development. The opening section in this article is one of the first times I've agreed with some positive view on the benefits of the environment. Zoom really is a cool feature that is not easily possible in more traditional GUI frameworks. I also have to begrudgingly admit that nowadays I can mostly create really nice interfaces with very little effort. This is thanks to browsers finally reaching an acceptable level of compatibility (anyone remember Acid CSS test), Javascript/Typescript evolving with genuine improvements (e.g. async/await), flex layouts (and soon grid!). There is still huge room for improvement but it isn't anywhere near as bad as it once was.

throwGuardian 7y ago

Agree with all the pros stated in the article. However, there are cons: 1. Each desktop app is shipping almost a full browser, updating it independently and bloating RAM, storage and CPU utilization in the process. 2. RAM/CPU bloat issues are real - even the V8 team advices against overreliance on excess RAM. They've noticed a speed increase in the process of releasing V8-lite aimed at aggressive gc 3. Even amongst the most mature GUI frameworks based on html/js, there's far too much overhead for trivial things, like reading/writing to file. For instance, in electron, since the browser V8 context isn't allowed willy-nilly storage access, a file read from the browser V8 goes across a couple IPC requests to complete. Also, these hops aren't widely documented and understood, making desktop apps janky by default, instead of fast by default

sdegutis 7y ago
I wonder what would happen if all major OS & Browser vendors decided to agreed on a long-term plan to migrate/evolve the HTML, CSS, and JS specs & implementations towards a functional equivalent variation that could be efficiently implemented with the same semantics and level of security (or better) but with far less CPU and memory inefficiency, removing indirection and dynamic abstraction layer by layer, until suddenly we get something that has all the legitimate benefits of modern web development, but with the same memory/CPU footprint of Cocoa or .NET, being also cross-platform and built into every OS. Wouldn't that be great?
- jerf 7y ago
  Before that can happen, we'll get WebASM + WebGL interfaces (efficiently) in our browser. I expect an explosion of alternate layout mechanisms to arise from that. They won't be very good at first, but they may end up somewhere neat.
  - c-smile 7y ago
    > I expect an explosion of alternate layout mechanisms. No need WebASM for that. Just one CSS property: div { flow: custom [funcname/url(of-layoout-controller)]; } + single function funcname() that will replace children and report min/max intrinsic sizes.

c-smile 7y ago

If to speak about browser technology as a GUI toolkit then there are three big things that are greatly underestimated. 1. Bubbling/Sinking(Capturing) event propagation schema. With that schema a container knows what event is passed to a child and did child process it or not. On desktop, windowed widget handles all its events without notifying/asking its container. This actually is pretty big - it enables composition of atomic input widgets. On Web you can use <input|text> as part of more complex widget. 2. CSS and CSS selectors in particular. As the way of styling component from outside - independently from its event handlers/code. So code changes DOM state and CSS defines how that state shall be presented. And not only that but styling of elements in context (cascading). That is "separation of concerns" at its best. 3. And the DOM. While each UI system has DOM ( tree of windows/widgets ) in one form or another the Web pushes its further: it adds unification of widget (attributes/states) interface. Any widget or element may have ID, class or other attributes defined. And those can be used for styling.

admax88q 7y ago
In practice CSS rarely lives up to the aeparation between state and presentation. In most projects the to are updated in tandem. DOM is not expressive enough to represent state, it moreso represents UI state, but CSS also represents UI state.
- c-smile 7y ago
  That is more about architecture actually. Ideally Web/UI component has two sets of styles: So called "primordial" or "base" - the one that defines layout of sub-components and parts and that is essential for component operation. And another set is about decoration - colors, fonts, sizes. For example in Sciter (https://sciter.com https://sciter.com) component is defined by so called style sets: @set nullable-input-base { :root { flow:horizontal; } :root > input { display:block; width:*; } :root > button.clear { display:block; } } // concrete nullable-input styling: // derives from nullable-input-base @set nullable-input < nullable-input-base { :root { background-color: var(inputback) } :root > button.clear { width:2em; background: url(x-cross.svg) 50% 50% no-repeat; } } And in script: class NullableInput : Reactor.Component { const styleset = ["nullable-input", url("widgets.css") ]; function render() { return <widget.nullable-input> <input|text /> <button.clear /> </widget>; } } This way you can redefine nullable-input in the way you want without putting any styles into code.

austincheney 7y ago

Building a browser GUI is simple. I would even argue extremely trivial. Here is a video demo of one I built in the not too distant past (github link at the end): http://mailmarkup.org/sharefile/demo1.mp4 http://mailmarkup.org/sharefile/demo1.mp4 It took me a little more than 2 weeks to write and test the GUI in that video. From this experience I have learned the following: * If you are comfortable working with the DOM and vanilla JS you should be spending more effort writing the content and services that populates the GUI rather than the GUI itself. I would say this ratio of time should be something like 20% GUI and 80% content starting out and scaling towards greater content effort as the requirements upon the GUI increase. * A JavaScript based GUI can be extremely fast and responsive. The video demo was captured on a 4k resolution and it performs, at least to human interaction speed, just as responsively as the OS's GUI even in VMs. That high resolution also explains why the video text is hard to read on a small mobile device. I intentionally wrote this to be fast though using vanilla JS and the standard imperative DOM methods, because that is the fastest way to execute things in the browser. It stands to reason if you go about things in a much slower way it will likely perform slower, possibly slow enough that the user notices a huge difference. * A JavaScript GUI can be extremely lightweight with tiny code. This is only true if you are comfortable working with the DOM without a bunch of code decoration and abstraction nonsense. * If the code is organized well it will scale well even in the face of numerous competing enhancements. I solved the problem of scale with TypeScript interfaces and constant refactoring. * There is one aspect that does not scale well, which any feature that requires complex algebra. One example is dragging a highlight rectangle over some elements for a mass selection and ensuring that highlight rectangle is confined to the containing element and that it knows which elements of the parent element are visually occupying the same space and which ones aren't. Another example is that the CSS property text-overflow only works if dimensions are statically available to the current element or its parent node. That means calculating a dimension for an element in order to set the value upon the element, which requires some calculation written by you instead of relying upon something like display:block;width:auto. * All presentation, and I do mean absolutely everything except dynamically modified display, opacity, position, and specified dimensions should be in CSS. The presentation that is not in CSS is directly on the DOM node by dynamically reassigning new presentation values on user interaction where necessary. This allows for smaller and more scalable code. * All icons are Unicode characters. The only one other graphic, because the desktop background, is an SVG spinner. SVG, being XML, can be adjusted with CSS just like the rest of the DOM.

mrighele 7y ago

I had a similar experience in my youth (just replace the MSX with a C64). The author is right when he says that programming a PC (either in DOS or Windows) was non obvious; but once you realized that the best way was to use a spreadsheet or a database engine, you could get a lot done quite easily. Those tools may not be as generic as Python or Perl, but you could program whole applications in a fraction of the time. As for the web, I think it is still harder than it could be, and the browsers make it more difficult every day, since they put more and more restrictions when opening a local page.

baybal2 7y ago

Web is very inferior to any modestly well done UI toolkit.

guggle 7y ago
As someone who spent most of his time in the last 20 years building web application and only recently (2 years) started using gui toolkits (mostly QT but also wxwindows), I certainly can relate to this. What a breath of fresh air... consistent UI, no fiddling with half-assed components or soon-to-disappear frameworks, no time wasted reinventing the wheel, excellent performance, no markup/code dichotomy... Great results with ease, I wish I made the jump earlier.

divan 7y ago

I'm so on the opposite side of this opinion. To my view, the better tech aligned with the problem domain, the better off are developers and end users. Using typesetting format for rich UI apps is so far from what UI toolkits need and has created enormous amount of pain, losses and security vulnerabilities. Making it the only available option on the dominant software platform (web) made it the worst cataclysm in the UI software industry. Like, in a slightly different turn of events, it could be Lotus or Excel spreadsheets format as a GUI framework. You can easily imagine how XLS becomes the dominant monopoly in UI toolkits and evolve chaotically to accommodate web demand for UI features. After decades of evolution and billions of lines of XLS and VB scripts, one could easily find "some things that work very well" with spreadsheets as a GUI toolkit approach. It doesn't make it a good fit, though. Why would anyone think that using text markup language for UI apps can be a good idea?

nitwit005 7y ago

There's kind of a big bump in using HTML/CSS/JS. It's easy to slap together some simple stuff, or fiddle with a web page, but you'll hit a certain point where you want your app to do something useful. Suddenly you'll be stuck reading about webservers, databases, Electron, and whatever else. In some ways it's still easier to make a basic Java Swing application. You can just install Java and start working through tutorials.

mirimir 7y ago

I mostly write stuff for others, and they do what they want with it. Or for GitHub. But my own stuff only goes on Tor onion sites. So it's strict HTML, because Tor's latency punishes client-server dialog. And also because people will hate on you for scripts. Also, I thought that this might be about WebGUIs. Such as the pfSense WebGUI, which still amazes me in its depth and usability. Or indeed, that you can route the WebGUI of a remote pfSense VM as a Tor onion service, and manage it just as easily as the box in the closet.

dzonga 7y ago

the great thing about the web is universality. no one controls the platform yet. although, that could change, as browser engines consolidate. The web, also allows you to be OS agnostic. most of my work is done via the browser. with the only native programs I run being a media player eg vlc or smplayer since linux doesn't handle gpu video decoding and some terminal windows. with tools like Figma etc. Web programs are here to stay and win. Though we suffer a regression in usability with people who abuse tools like React etc

malkia 7y ago

yup it is :) fossil ui - runs the browser as UI (from https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki) one of the first examples I've seen, but not the only one.

tsukurimashou 7y ago

Funny thing is these three points: - Copy/paste anything. - Search any text with e.g. Ctrl+F. - Back button. Tend to disappear with javascript frameworks, single page applications, ajax, and websites partially or fully rendered with canvas