I found most of this to be quite "objective" and not really related to design decisions.
Most of it very subtle, I agree, but I think it's hard to argue against any of the questions being subjective.
547 karma · joined April 5, 2022
Most of it very subtle, I agree, but I think it's hard to argue against any of the questions being subjective.
However, in many cases a more descriptive name is way appropriate. On top of my mind:
- Multiple variables of the same type. How are you supposed to distinguish between req and req2? Compare it to something like "apiReq" and "cdnReq"
- Primitive types, that does not inherently carry a domain value. An integer called "seconds" or "max_offset" has a lot more meaning that one named "num"
Forcing such a notation into the language would make impossibile to represent all these cases
Moreover, the layout editor is rarely used in Android development, most of the control is done via code because it depends on dynamic content that is not available to the layout editor ahead of runtime. Most the examples in the exact link you attached are code examples for this very same reason
No it's not! You create your content with text and images, you send it to two friends: one opens it in a 27" inch monitor, the other one on his mobile phone. How big should the images be? How big the text? What happens if there is a text on the left and an images on the right, and you watch it on a mobile phone? should it go down, should the image resize to occupy at maximum half the viewport? what happens when the text overflows?
The reason you can do it on a Oowerpoint or Publisher is that the viewport is the same, you position it and you are done. The user on the desktop will see it very small, the user on the phone will need to keep scrolling and dragging.
If you are ok with these limitations, there are plenty of tools available to share content! You named them.
If you want better control, there are no easy way of doing it, there are no example of this problem being solved, and I don't think it's a web problem.
The tools you mentioned have a fixed viewport size, the web does NOT have it.
99% of the difficulties of a web design is in supporting all possibile client screen sizes / ratios.
A powerpoint like experience is trivially to build, just use position: absolute and place everything pixel by pixel.
I'm not aware of any GUI for creating responsive content (unless you limit the content to a simple flow of text)
Of course you shouldn't use a full-js stack if your team of developers doesn't know JS, no one is arguing that because it doesn't make sense.
When that is the case, the stack you are describing is just perfect even nowadays.
The problem is, in most cases that is just not the case anymore.
No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.
> Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/
Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea
Because, in building complex and dynamic web apps, the alternative is to repeat a lot of the same logic in both frontend and backend.
Of course if you are building a blog or a simple static page this is not useful, most of the new techniques are a response to more advanced requirements.
For instance, right now I'm building a "buy form" for internal use (by employees only) in a shop. There is a ton of domain login used to select which field to display, what validation login to use, how to autocomplete some fields ecc ecc. The system is a PHP/Laravel server with SSR rendering and vue only used for some specific advanced components. Most of the logic inside the form has to be written two times: in PHP and in vue. Most enum types are repeated (and must be kept in sync). Having one shared codebase would simplify A LOT the development.
True, but instead of having to trust a central authority for insertion, updating, removal and constant maintenance of your "ownership", the trust would only be required for insertion. Once you purchased a domain and it's inserted in the blockchain, no one (outside of yourself) should be able to revoke, change or question your ownership of the domain itself.
Honestly it would be a pretty good use case for a blockchain, but it lacks a money incentive for any part involved so it will probably never happen