Live data from Hacker News

Vue Native (2018)

vue-native.io

161–170 of 190 posts

Re: Vue Native (2018)

#161
post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

> HTML/CSS is an inevitable part of the ecosystem because the web is an important target. You did confuse cause with effect. In the first place Web accepted HTML/CSS/JS for the good reason - as a classic implementation of "Separation of Concerns" principle. See: 1. HTML defines semantic structure of UI - DOM tree. 2. JS, as language-behind-the-UI, handles users events and updates DOM tree and its state. 3. CSS define…

> HTML defines semantic structure of UI

The problem I have with HTML is that it's only really any good at defining the semantic structure of a document, particularly the type of thing you might produce with a word processor. Half the stuff on a modern webpage—even those you'd still call documents rather than apps—can only really convey meaning via visual layout, and so break down when divorced from CSS/JS.

For example: I'm a big fan of reader mode in browsers, but so often they're tripped up by basic UI affordances like menus and image galleries. The renderer has to guess at what's content and what isn't, so half the time any sort of "widget" is rendered as a crappy-looking vertical list. Sure, that's technically what a menu or gallery is at its most basic level, but surely we can do better?

There probably are sensible defaults you can already follow—representing a menu as a containing s, say. But it would be much easier if there was a tag. A inside a would semantically be a menu in the same way that inside is semantically an ordered list—you don't need any CSS to render that in a sensible way.

Same goes for galleries; if we had a tag that could contain and s, you'd still be able to do custom layout with CSS if you needed to, but at the base level you could sensibly render it with just the markup itself.

I dunno, I just find it weird that we added all these new tags for HTML5 years ago then just stopped bothering. I mean when was the last time a HTML element with behaviour was added?

In an ideal world a reader mode could be expanded to a "reader-friendly page mode" wherein the page still looked approximately like the normal webpage, just without all the user-hostile shit. Of course, that's usually diametrically opposed to the financial incentives of running a website, but it's nice to think about.

Re: Vue Native (2018)

#162
post #140

Earlier quoted context omitted.

C only got there, because UNIX just like the Browser did to JavaScript, has placed it everywhere. This happened only because Bell Labs/AT&T were forbidden to sell UNIX, hence its source code spread across the industry, with a symbolic price that made it by comparison with other OS vendors feel almost as quite cheap beer. During the 80's and early 90's, C only mattered in universities and companies that had access to…

We're all well aware of the unix/c coupling. What I'm saying is that for low level memory mangling and primitive operations over the set of register based machines.. you don't get any benefits from using another language it seems. I.. just a dude but some people doing HPC said that you can even reach FORTRAN speed on numerics if you fiddle with the right keywords to avoid aliasing. Again I'm not a C fan.. but what wo…

Safer with less memory corruption exploits to start with.

Fixing C is so beyond hope that Apple, Oracle, Google, Microsoft, ARM are all driving hardware based solutions for memory tagging and pointer validation, while at the same time reducing the use cases for it across their OS stacks.

Re: Vue Native (2018)

#163
post #162

Earlier quoted context omitted.

We're all well aware of the unix/c coupling. What I'm saying is that for low level memory mangling and primitive operations over the set of register based machines.. you don't get any benefits from using another language it seems. I.. just a dude but some people doing HPC said that you can even reach FORTRAN speed on numerics if you fiddle with the right keywords to avoid aliasing. Again I'm not a C fan.. but what wo…

Safer with less memory corruption exploits to start with. Fixing C is so beyond hope that Apple, Oracle, Google, Microsoft, ARM are all driving hardware based solutions for memory tagging and pointer validation, while at the same time reducing the use cases for it across their OS stacks.

> Safer with less memory corruption exploits to start with.

ok I admit defeat on this. I can't barely believe I forgot that u_u;

Re: Vue Native (2018)

#164

Earlier quoted context omitted.

You had to upgrade from which version to which one?

I initially used it with version 1/Angular 1.x. Then when Angular 2 was basically a complete rewrite from scratch Ionic did the same. For a little bit I was still able to compile the code but quickly their tools became unavailable and unusable.

You were very early in the history of Ionic, I understand you :( but such breaking change should not happen anymore at this scale

Re: Vue Native (2018)

#165
post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

I've used pretty much all GUI frameworks - raw Win32, MFC, WinForms, wxWindows, Qt, WPF, native Android and iPhone. HTML/CSS is vastly more powerful and productive, especially when using something like React/Vue. It's not because "web devs who don't know anything else". HTML/CSS is just a superior technology. No wonder that even traditional GUIs are moving this direction - Qt with QML, windows with their new Win10 fl…

So glad to hear this sentiment. It's frustrating that so many people don't seem to acknowledge how flexible HTML/Javascript is. It's not perfect, it's probably not the most efficient possible set of APIs, but it has to deal with a whole lot of legacy, just like most programming languages/platforms/frameworks.

Much of this conversation seems to consist of "the popular solution to this insanely complex problem is hard! Why isn't it trivially easy!?"

Re: Vue Native (2018)

#166
post #93

Earlier quoted context omitted.

I just don't understand what happened to classical RAD from the late 90s early 00s. OK web was out of touch because no one really uses the "standard gui" anymore, even something as simple as a button has different look and behavior on every website. But mobile app should be prime targets for it, and theming is a well understood concept for it too. So why do we not have a proper rad tool (drag and drop my button where…

> classical RAD from the late 90s early 00s. RAD, a.k.a. UI-nailed-down-to-pixel-grid approach, has died immediately after we've switched from 640x480 pixel screens to variety of display and devices. If in doubts think about Adaptive and Responsive Designs ( https://en.wikipedia.org/wiki/Responsive_web_design ) in regards of RAD.

But that's not a limitation of RAD. Delphi 4 and Visual Basic both had "align and/or resize proportionally" on all axis.

Making an UI that adapted in size from 640 to 1280 was a 4 clicks matter.

Having COMPLETLY SEPARATE UI for different form factor like we need on the web sure, but that shouldn't be an issue on mobile just pack X version of your UI like you end up doing with all your resources anyway.

> RAD, a.k.a. UI-nailed-down-to-pixel-grid approach

That's really not what RAD was about.

RAD was about "every single component you use is generic, you don't care how it works, you only want to say where it is, what event you listen to, and optionally do some custom rendering".

As said above, positionning could be non-fixed, auto-adapted to the view, ...

Re: Vue Native (2018)

#167
post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

I’m sad at CSS but not HTML. If you look at other front end approaches by other communities they will have something similar to reusable components which can be nested as a DAG with some technique to pass state around, but which community is inspired by CSS?

Re: Vue Native (2018)

#168
post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

I've used pretty much all GUI frameworks - raw Win32, MFC, WinForms, wxWindows, Qt, WPF, native Android and iPhone. HTML/CSS is vastly more powerful and productive, especially when using something like React/Vue. It's not because "web devs who don't know anything else". HTML/CSS is just a superior technology. No wonder that even traditional GUIs are moving this direction - Qt with QML, windows with their new Win10 fl…

> No wonder that even traditional GUIs are moving this direction - Qt with QML,

QML (march 2009) is older than angular, react, vue which are all post-2010. And still they are all more complicated to use as a language

Re: Vue Native (2018)

#169
post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

> Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes.

I've been manually crafting HTML/CSS websites since 2001. Since the arrival CSS flexbox/grid, I don't know anything easier to build layouts than HTML/CSS.

I like what Fluter offers but HTML/CSS is far cleaner/easier to read and simpler.

Re: Vue Native (2018)

#170
post #162

Earlier quoted context omitted.

Safer with less memory corruption exploits to start with. Fixing C is so beyond hope that Apple, Oracle, Google, Microsoft, ARM are all driving hardware based solutions for memory tagging and pointer validation, while at the same time reducing the use cases for it across their OS stacks.

> Safer with less memory corruption exploits to start with. ok I admit defeat on this. I can't barely believe I forgot that u_u;

Here some updates on hardware memory tagging from Google regarding future Android hardware.

https://youtu.be/zkoOD4hmiGE

Microsoft, FreeBSD, ARM collaboration on CHERI

https://msrc-blog.microsoft.com/2020/10/14/security-analysis...

https://youtu.be/yrk5FfjHDCo

Oracle with ADI

https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html

Apple with pointer authentication,

https://developer.apple.com/documentation/security/preparing...

Post reply on HN