4 ms·
I think all the churn is a sign of several problems. First, the language was not designed to do what people are trying to use it for. Second, I question wheth
by prewett 10y ago
I think all the churn is a sign of several problems. First, the language was not designed to do what people are trying to use it for. Second, I question whether the framework makers are familiar with "native" UI APIs (e.g. Java, Qt, NextStep), which solved a lot of these problems years ago. Notice the lack of churn in native UI APIs (exception of Microsoft). Third, it seems like the frameworks try to build on top of HTML, which I think is a mistake, because HTML was not designed for layout flexibility and pixel-perfectness (unlike native widget APIs). Furthermore, HTML was poorly designed for anything but simple word-processor documents: why is there no <block> element that is inline-block?! That's the first thing I end up assigning to everything. But the whole declare-your-document approach is inherently too simplistic for much beyond a word-processor document. Note that PostScript, and PDF which is an enhancement, has been pretty stable and standard for years, which indicates it is a good solution to the problem. Ultimately, you need to be able to program your documents and put pixels exactly where you want them. But even just sending over a blank HTML page and then having JavaScript add everything programmatically is probably better-suited, despite having to ultimately get squeezed into the HTML approach.
In my opinion, we need to realize that webapps are not documents, and document-oriented HTML is the wrong tool. I don't think things will get better until we start looking at webapps as essentially drawing on the screen, like native UI APIs. I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer, as long as it can compile onto the instruction set. Static-type people can use a statically-typed language, and dynamic types can use dynamically-typed languages. Make an instruction set that maps well onto native CPU instructions, and provide well-thought out input and drawing primitives. We essentially need a PostScript for apps.
- IndianAstronaut 10y ago> I think we need a standardized virtual machine, like a lightweight JVM (or, better, a heavyweight Lua), which would allow people to use whatever language they prefer To be fair, a lot of languages compile to Javascript. Do we really need a second standard?
- icebraining 10y agoIt's coming regardless: https://en.wikipedia.org/wiki/WebAssembly https://en.wikipedia.org/wiki/WebAssembly
- life_is_short 10y ago> provide well-thought out input and drawing primitives This sounds like a cool idea! What primitives would you suggest?
- ng12 10y agoEvery time I see this argument I have the same response -- we tried this. We came really close to having Java be the standard and it failed for a ton of reasons (security was incredibly difficult, absurd slowness, UI/UX problems, user adoption issues, etc). What makes you confident we could get it right the second time?
- prewett 10y agoYes, you have an excellent point, and I worry about that. It also worries me that what I am proposing is pretty much what Flash did, I think, and we all hate that. I think we can do better because we know what we need now, and we have some good and bad examples to guide us. The problem with the JVM is that it is too heavyweight. But we know that lightweight is possible because everyone loves Lua. Security is doable because BrowserVM does not need to do everything. It isn't generable purpose like the JVM, it is an embedded VM like Lua. Lua has great security, as far as I am aware. I expect that having a secure VM is no more difficult than having a secure ECMAScript implementation. I think we want low-level execution primitives (i.e. assembly), which pretty much forces a VM, because it gives people flexibility to use whatever language they want. However, even the minimum of keeping JavaScript and having the page be a large canvas with (fast) drawing primitives would sufficient. Writing windowing systems and UI toolkits is a solved problem. I think the browser should, at minimum, provide primitives for drawing widgets, so that webapps can take advantage of OS-native widgets. A well-designed toolkit, though, would be handy. And here we have a number of examples. Qt is very well-designed and a pleasure to use. Cocoa is a little clunky, but effective. Even Java/Swing was fine (aside from horrid aesthetics). We know that Microsoft-style MFC is a bad idea, the Win32 callback idea is clunky, and Android is a mess. In particular, a constraints-style system seems to be clunky. It was clunky in Motif, clunky in Android, and even Apple's version doesn't seem all that great. Constraints seems to suffer from the same problem of HTML: describing the system is clunkier than just telling the system what to do. Hence, Qt and Swing's layouts are a lot easier to reason about.
- rer 10y agoFinally, someone gets it. Thank you!
- hiddenkrypt 10y ago> First, the language was not designed to do what people are trying to use it for Against this point: Few languages are used for what they were designed for. Java was designed as a control language for "smart" TVs. PHP was designed for making personal homepages a little bit reactive. JS was designed for making client side pages dynamic. And now all three are being used as server software.