Live data from Hacker News

Get in zoomer, we're saving React

acko.net

101–110 of 251 posts

Re: Get in zoomer, we're saving React

#101
>Many competing frameworks acted like this wasn't so, and stuck to the old practice of using templates. They missed the obvious lesson here: every templating language inevitably turns into a very poor programming language over time. It will grow to add conditionals, loops, scopes, macros, and other things that are much nicer in actual code. A templating language is mainly an inner platform effect. It targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist. Designers don't want to code at all, while coders want native expressiveness. It's just that simple.

This is exactly what I was getting at when I wrote this recent post about Smarty (in response to the following parent comment proposing building a crippled scripting system for designers), to which somebody insightfully commented "Someone doesn’t like Smarty…"

https://news.ycombinator.com/item?id=32886317

parent> Even in game development, it often turns out to be a huge mess that coders have to go and sort out after the fact, it's almost inevitable if it's general purpose enough. If you do decide to build a scripting system for designers, I would recommend being very conservative with features and thinking twice before adding any new feature.

https://news.ycombinator.com/item?id=32886424

>DonHopkins 5 days ago | prev [–]

>Just hire competent and trustworthy designers, instead of purposefully crippling the tools you spend so much time developing. The best designers can also code, and if you design a system that discourages instead of encourages designers from coding, you're wasting the potential of those precious coder/designers, and wasting the opportunity to train your best designers to code too.

>It's not as if Rock Star can't find anybody qualified who wants to work for them, or any designers who are willing to learn to code in a powerful visual scripting language.

>This attitude causes disasters like PHP's "Smarty" templating language.

>PHP was already a templating language, but somebody got it in their head that there should be an iron-clad separation between designers and programmers, and that PHP gave designers too much power and confused them, and that their incompetent untrustworthy designers who refused to learn anything about programming deserved something even "simpler" than PHP, so they came up with Smarty.

>Then over time the realized that their designers were powerless, so their programmers would have to learn TWO languages so they could wade into the Smarty templates to make them actually work with all the extra code they had to write because Smarty was so crippled, so they nickle-and-dimed more and more incoherent programming language elements into Smarty, making it EVEN HARDER to use and more complicated and less consistent than PHP, yet nowhere near as powerful.

https://news.ycombinator.com/item?id=20736574

DonHopkins on Aug 19, 2019 | parent | context | favorite | on: YAML: Probably not so great after all

One of the most ridiculous examples of this was the Smarty templating language for PHP.

Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug.

So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either.

https://web.archive.org/web/20100226023855/http://lutt.se/bl...

>Bad things you accomplish when using Smarty:

>Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn.

>Not really making the code more readable for the designer.

>You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites).

https://web.archive.org/web/20090227001433/http://www.rantin...

>Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay?

http://www.ianbicking.org/php-ghetto.html

>I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.

Re: Get in zoomer, we're saving React

#102

I thought this was the most insightful part, though it would be the second most if the author did more than allude to conflict-free replicated data types. Whenever you build a tiny language for the purpose of templating, it's worth asking yourself if it's really worth it to have to reinvent variables, loops, branches, scoping, expressions, and functions... Poorly. > Many competing frameworks acted like this wasn't so…

Yes, JSX (and React) is interesting in this way: it's not a (full) template language. Instead, it's a convenient way to write component fragments that include HTML/XML expressions and further components. Each component top-level is still JavaScript statements.

There's also an escape hatch to include arbitrary JS expressions inside your JSX expressions, although perhaps we should use it only to include variables and not more complex JS expressions.

In the end, templates are not important, components are. JSX provides just what's necessary to make it convenient to define components in JS.

Re: Get in zoomer, we're saving React

#103
post #93

Earlier quoted context omitted.

> FFS. The context is the web, nobody solves graphic problem like gaming for you, or need to… I don’t think you understood the article. The point he was making is that a good user interface is hard to build and is “app like”, with all the weird edge cases. …and that, for better or worse: 1) react is the best at doing that. 2) react is (frustratingly) not making itself better at it, and is instead prioritising weird s…

But why can't we make an app if we need an app?

Sometimes, you want to be able to support more than one OS.

Re: Get in zoomer, we're saving React

#104

I agree with this guy. I can see that his tone unfortunately irks many to take offense and post. I am sad that microsoft has so dropped the ball on UI, that even MS' own teams use web tech to build apps nowadays. I particularly lament that scroll bars have become a lost art. We have gone from scroll bars working perfectly in windows 3.1, to .. whatever passes for a scrollbar these days. Often they are even hidden, so…

I thought windows had bad UX until I tried macOS. Maybe my taste is different than others but I found macOS UX to be really confusing. I particularly disliked the iconset. Interestingly this is not true for iOS and iPadOS, those are magnificent.

Re: Get in zoomer, we're saving React

#105
>So what exactly did we lose? It's quite simple: by moving software into the cloud and turning them into web-based SaaS offerings, many of the basic affordances that used to be standard have gotten watered down or removed entirely. Here are some examples:

>Menus let you cross over empty space and other menu items, instead of strictly enforcing hover rectangles.

I know the guy, Frank Leahy, who implemented that feature invented by Bruce "Tog" Tognazzini.

When he was at Apple, he rewrote the Menu Manager for Mac SE and Mac II.

We were working together on a project at Current TV, and reminiscing about how great the original Apple Human Interface guidelines were, and how Apple had totally lost their original devotion to excellent user interface design, and I mentioned how the original edition of the Apple HIG book I had actually illustrated, documented, and justified that subtle feature.

Frank proudly told me he was the one who implemented it for the Menu Manager, and that he was touched that somebody actually noticed and appreciated it as much as I did.

https://news.ycombinator.com/item?id=17404401

https://bjk5.com/post/44698559168/breaking-down-amazons-mega...

>Breaking down Amazon’s mega dropdown [...]

>DonHopkins on June 26, 2018 [–]

>The comments are actually great -- even Tog weighs in! It also mentions Frank Lehey, who rewrote the Menu Manager for Mac SE and Mac II.

>Jake Smith • 5 years ago This was first implemented by Apple's HID team back in the 80s, specifically Bruce Tognazzini, I believe.

>Bruce "Tog" Tognazzini Jake Smith • 5 years ago Yes, I did invent it back in 1986 and it is firmly in the public domain. From what I remember, it was Jim Batson who worked out the math and coded it for the Mac OS. The OS X team later failed to copy the algorithm, so I am happy to see that amazon has resurrected it.

>Josh Davenport Jake Smith • 5 years ago I think it was yes. It looks like it was originally implemented by NeXT and then removed by Apple when they bought NeXT. Tog himself talks about what happened here: https://www.asktog.com/columns/022DesignedToGiveFitts.html in the answer to question 6 - "When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a >markr_7 • 5 years ago Can't comment on the HID team, Bruce, or possibly the many times it was even implemented at Apple, but as a young developer at Apple in the 80s, I remember stopping by Frank Leahy's office as he was tweaking his code to get menus to "work right." I've often recalled the experience because of the time he was spending to get it right, and how the behavior wasn't simple once you started really trying to meet a users expectations. If I remember right it wasn't just the direction, but also time and therefore velocity. For example, you wouldn't want to stick with the wrong menu if the user wasn't really moving with purpose in the direction of the sub-menu.

Re: Get in zoomer, we're saving React

#106

I agree with this guy. I can see that his tone unfortunately irks many to take offense and post. I am sad that microsoft has so dropped the ball on UI, that even MS' own teams use web tech to build apps nowadays. I particularly lament that scroll bars have become a lost art. We have gone from scroll bars working perfectly in windows 3.1, to .. whatever passes for a scrollbar these days. Often they are even hidden, so…

I thought windows had bad UX until I tried macOS. Maybe my taste is different than others but I found macOS UX to be really confusing. I particularly disliked the iconset. Interestingly this is not true for iOS and iPadOS, those are magnificent.

I can never find the back button on iOS.

Re: Get in zoomer, we're saving React

#108
Funny how reactive seems recent for people, while dataflow / dag based visuals are old in the movie/cgi industry :)

It always pains me to remember a p2 cpu could do realtime nurbs procedural animation (very complex) and yet we still have manual state machines for simpler tasks like documents / filesystems etc

This article is right that there's a lot to gain in terms of ergonomics by finding leaner ways. I also think the web stack and dev culture is ready to respond well to this idea.

Re: Get in zoomer, we're saving React

#109

> What's really frustrating about all this is how passive and helpless the current generation of web developers seem to be in all this. It's as if they've all been lulled into complacency by convenience. They seem afraid to carve out their own ambitious paths, and lack serious gusto for engineering. If there isn't a "friendly" bot spewing encouraging messages with plenty of emoji at every turn, they won't engage. > A…

I didn't read the article, but just based on the passages you have quoted and based on my recent experience, I will have to agree with the author. I recently learned that GitHub has a discussions page which is separate from the issues pages. To pass the time and to give back to the community I try to help people and answer their questions. It's a bit concerning to me that when I point some people to the right directi…

I don't know if it's the whole new generation or only the web/nerdy part of it.

Re: Get in zoomer, we're saving React

#110

I agree with this guy. I can see that his tone unfortunately irks many to take offense and post. I am sad that microsoft has so dropped the ball on UI, that even MS' own teams use web tech to build apps nowadays. I particularly lament that scroll bars have become a lost art. We have gone from scroll bars working perfectly in windows 3.1, to .. whatever passes for a scrollbar these days. Often they are even hidden, so…

Recently scrolling through a list of countries to choose 'United Kingdom' I eventually found it under 'G'. The nearest I can figure, it was previously for 'Great Britain' and was never re-sorted? (Never mind that nobody in the UK has called it Great Britain since maybe mid 20th century!)
Post reply on HN