What about it doesn't scale? Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. If MVC doesn't scale the folks who maintain those frameworks would have noticed by now.
Does Retool have a query builder? Does it support query parameters? If not how do you find the record you want to update? Does it support displaying fields from lookup tables (i.e., tables joined via foreign key)? How do you pick a record from a foreign table (when you want to update the foreign key itself)?
Yes. It may not be exactly like the one in Airforms. You can do CRUD operations/mappings without writing any SQL, or you can drop into SQL (with autocomplete and a schema browser) if you need more complexity.
> Does it support query parameters?
Yes.
> Does it support displaying fields from lookup tables (i.e., tables joined via foreign key)?
Yes.
> How do you pick a record from a foreign table (when you want to update the foreign key itself)?
There are multiple ways to do it. The easiest way is to run a query to get the IDs (and labels) from the table you're joining and then add that to some kind of input (list, table, etc.)
Like I said in a previous comment, a lot of this stuff requires knowing how to code or at least some technical understanding of databases, which might be a differentiator.
I am a founder myself and I haven't put founders' info on our website for a simple reason... one of the cofounders has not yet quit his day job and he doesn't want his employers to know he is moonlighting.
React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might as well use vanilla js instead of React.
What does using Vanilla JS look like? Here's an example: https://github.com/wisercoder/eureka It uses two tiny 500-line libs. It uses TSX files, just like React. It has components, just like React. It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.
This is either a fundamental misunderstanding of React, or you're actually talking about a different library.
> React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React
React components are designed with state in mind. When state changes, components passed that state in the form of props are re-rendered. Don't take my word for it though, from the first paragraph on the reactjs.org website; "React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes."
> At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish.
I have never heard these spouted as the benefits of React. The main fundamental philosophy of React is that only components that have state changing "react" to changes - in other words, the benefits of React are: no unnecessary re-rendering (hence the virtual DOM).
> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key
This part just threw me, if you are doing it this way - you are doing it wrong.
> I have never heard these spouted as the benefits of React.
You will find this if you read enough of React developers' blogs. JavaScript and DOM these days are fast enough that most pages can completely re-render the page and replace the whole DOM in one shot and you won't be able to tell the difference. The downside of doing that is that you lose focus, selection, scroll position, etc. So preserving those things is the benefit of React.
> Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key.
Do you have any concrete examples for this? I'm not sure I agree: I've made plenty of stateful components in React and they are just fine. If anything, they're a lot cleaner than what I could do in plain JavaScript, thanks to the framework.
Further, could you expand on what you mean re: recommending changing the key? I have never heard the React team suggesting to do this, although maybe I missed something in the documentation :-)
Wait isn't state the whole point of react? What level of interactivity are you talking about? State and props, that's it's thing: you can always update them.
I've only need the "change key to flush components" trick very few times, and most of those where rush fixes for bugs that had a better "doing it right" fix at a different level.
This is categorically false. If you want to update props in a stateful component it is exactly the same - just pass new props.
If you instead are talking about syncing props with state, there are ways to do this as well without changing the key, but this is considered an anti-pattern in the first place.
This sounds more like bashing react without even knowing it very well in the first place.
This whole article is about an edge case where components have an internal "draft" state and an external "final" state, where both represent the exact same thing, and you want internal state to change when props change. This, in itself, would be an anti-pattern in any kind of programming, reactive or not.
What the author is trying to convey is that using getDerivedStateFromProps is not the best idea, and there are two simpler ways of doing it. The first solution (only keeping the state in one place) is the better one.
About the solution you're repeating all over the thread, anyone using React will notice that the "key" change solution you're talking about only works for trivial cases: it doesn't work in practice if you have more internal state in the component. It does work perfectly fine if you only have one single piece of internal data.
This is of course a past worry. All this is much simpler to solve by using Hooks.
But the important lesson here is maybe that one shouldn't judge whole Frameworks by advanced articles about edge cases written 4 years ago that require more experience with the framework than you have.
Nothing has changed in the last 4 years. Any time you have props and state, updating props is best done by replacing the component by changing the key. If you think hooks has fixed this, you are welcome to point to an article or code that demonstrates that.
All of this complexity is completely unwarranted, which is the point of the article at the subject of this thread. You can do it with simple vanilla js and it is easier. Javascript developers tend to buy into frameworks too easily without realizing the framework is making some things more complicated than without any framework.
> Any time you have props and state, updating props is best done by replacing the component by changing the key
No, it isn't. This is a ludicrous statement.
Replacing the key will RESET the internal state of children objects. Meaning you can't use this workaround for any component that has any kind of internal state does not come from props.
On the other hand, it is completely trivial to update props that don't affect internal state. This article is only about updating props that affect internal state of components that don't have any other internal state.
> All of this complexity is completely unwarranted
No. All of this complexity you're complaining about exists for one very specific edge case, and this edge case exists in non-reactive frameworks too. You're just extrapolating the complexity of one single edge case to the whole framework.
What's more, if you want it to only do this when passed new props and not at other times, you have to use things like React.memo:
"If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result."
But it doesn't do this is my whole point. React will not blow away the entire DOM in the document even if props change.
It will correctly keep your scroll position, caret position, etc. if you use React the way it's intended to be used, which is very easy to do and learn. Of course if you use the `key` prop to blow away the entire DOM with every change all these benefits are lost, but thats not react's fault, its your own.
> Stateful components don't work so well in React.
They work fine, though managing state outside of components via a state management library is common.
> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key.
Where do you find this recommendation? I’ve never seen anything like it, and keys are usually only used for repeating sets of elements, and you would generally only use a different key if something is not the same logical entity as the thing that previously had the key.
There might be some cases where you want to force a new rather than updated component by the kind of key manipulation you describe, but it's not the general case of prop updates for stateful components.
> It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.
React does have incremental updates for interactive, stateful components. You can deliberately negate it the way you’ve described, but you should not, generally.
Ive may have done great work under Steve Jobs, but his work since Jobs' passing has been disastrous.
Let's consider Jony's performance on software design first. This is what some prominent people have said about iOS 7: The Verge wrote in their review: "iOS 7 isn't harder to use, just less obvious. That's a momentous change: iOS used to be so obvious." Michael Heilemann, Interface Director at Squarespace wrote, "when I look at [iOS 7 beta] I see anti-patterns and basic mistakes that should have been caught on the whiteboard before anyone even began thinking about coding it." And famed blogger John Gruber said this about iOS 7: "my guess is that [Steve Jobs] would not have supported this direction."
And what about Jony's other responsibility, industrial design? The iPod, iPhone, iPad, MacBook Air and other Apple products from Jobs era are all amazingly well designed and breathtakingly beautiful. But these products weren't designed by Jony Ive all by himself. He designed them under Steve Jobs's guidance and direction. Steve was the tastemaker. Apple's post-Steve products are nowhere near as well-designed.
Consider iPhone 5c, for example. The colors were horrid, and when you added those Crocs-like cases it looked more like a Fisher-Price toy than like a device an executive would want to be seen holding. That the 5c didn't do well in the market shouldn't surprise anyone.
As an Apple shareholder and customer I am glad Ive is gone.
I entirely agree that Ive's design brilliance required Job's meticulous attention to details and taste to be really successful. He did make some questionable choices after Job's passing.
And the article doesn't make much sense to me. While I don't agree with everything Cook does, Recent Apple computers are traditional Apple at its best — extremely well designed, minimalist, functional, with best in class performance, displays and portability.
>Consider iPhone 5c, for example. The colors were horrid, and when you added those Crocs-like cases it looked more like a Fisher-Price toy than like a device an executive would want to be seen holding.
Personally, I found the 5c colors nice. I dont see much of a difference to those huge (ugly?) cases that people wrap around their phones today. I dont know many people who are using naked phones today and my feeling is that phones today are not designed anymore to be case-less: the camera bump, razor-sharp edges, too thin bodies.
The 5c flopped because of other reasons: it was artificially made worse than the 5s. It started with 8GB memory that was already WAY TOO LITTLE back then, it had no touchid, it had a bad camera and so much more - and yet, the price was high. Apple learned from the mistakes and changed their segmentation strategy and it worked since then (with the exception of the weird XR thing).
I had an iPhone XR from work. It flopped…but it was a good phone, and it was not necessarily an obviously bad idea, in my opinion.
People like big phones. The idea of a big iPhone that has contemporary guts but lacks some of the really wild camera abilities of the Max models didn’t inherently seem like the wrong plan to me. But it just kinda went nowhere, probably because you can just go buy last year’s iPhone model.
It flopped because apple did that: "here is our standard model.. and by the way, here is a cheaper, crappier model".
Now they have the approach to have a full price standard model - and there is a super duper "pro" model for the extra successful, professional and rich people.
This approach makes more sense for the consumers and this makes the 12 and 13 fly the way they do.
Calling this "disastrous" goes beyond hyperbole into a realm of parody, so I can only assume you're kidding.
A lot of the iOS 7 changes were positive, and those which were missteps were far from "disastrous" and have already been reversed.
If you have to go all the way back to a fringe product like the 5c, that kinda proves the opposite of your point, doesn't it? The 5c is the exception that proves the rule.
Nobody should be glad Ive is gone. It was a tremendous loss. For every decision you might disagree with, there were a hundred others that were spot-on.
I’m also very glad that Ive is gone and I think iOS 7 was a disaster that gave up an enormous UI/UX lead.
His value existed solely when his extremes were moderated by someone like Steve Jobs.
When handed the reigns, Ive ran roughshod over what made Apple — and his own work — worthwhile. He prioritized form over function, and ego over empathy.
Not “universally”. I have a stock of 2016-18 era laptops because they are the only thing I can comfortably type on for extended periods. I prefer them to every laptop that came before and every one that has come since.
I, for one, very much prefer the aesthetics introduced in iOS 7. The first version was rough and sometimes inconsistent, but that can be expected when the changes are so radical in such a big project.
The developer experience of web technologies is after all this time still far worse than all the desktop libs I've tried. It is even worse than Swing (for those who don't know: That's Javas GUI technology. From the 90s). Add to that the horrible RAM usage, the general jankiness and ... thanks, but no thanks.
> It is even worse than Swing (for those who don't know: That's Javas GUI technology. From the 90s).
As someone who loved Swing and used to hate JavaScript, that's really nonsense if you actually want to be a UI developer (and not just some side afterthought).
State management and the custom capabilities when you need them are amazing. I wasted a lot of my time writing tons of Swing code. Sorry, but the modern front end experience is much more enjoyable and productive. If you want "native widgets" I get the complaint, but most platforms seem to be less interested in consistent experiences these days.
> State management and the custom capabilities when you need them are amazing
JS devs just rediscovered MVC with some added immutability and that’s all. Hardly more productive. Also, I don’t see your point on custom capabilities - please add a slight modification to the date picker widget. Oh, you have to reimplement the whole thing with some insane number of divs, while you can trivially override certain parts of it in most desktop libs.
Dependency management is simple for Swing. In can mostly be assumed that it is available and works. How many dependencies will an Electron /Webstack based app have?
I really like JetBrains IDEs and I think they are based on Swing.
Although I haven't used it for more than a decade, I still have some fondness for Java. I like Workflowy but am not crazy about it being in the browser. I contemplated writing my own outliner and Java + Swing is one combination I'm thinking about.
Compared to WinUI, I wouldn't exactly call web technologies' developer experience pleasant.
This was pre WinUI, but a while back I worked at a shop that simultaneously maintained Web-based and WPF versions of an app. The Web version required 3 dedicated developers to maintain. The WPF version needed about half of one person's time, and had more features.
I would say that the main thing favoring tools like Electron is entry costs. There are lots and lots of people who know who to do front-end Web development, and you can do a good job of supporting all platforms using free tools. Even if you grant me for the sake of argument that native GUIs cost less in the long run, there aren't a whole lot of people who have experience doing them these days, even fewer who have experience on more than one platform. Going that route also requires you to shell out for Macs and probably also Visual Studio.
You wouldn't ask the question if you had developed both GUI apps on MS stack with VS and web apps: the MS dev experience is very good, while the web one is meh at best. C# vs JS, XAML vs HTML+CSS (debatable), desktop application model vs web one, VS vs whatever else, there is a lot of strong arguments in favor of the MS stack in that case.
Microsoft is trying to port some of this magic with Blazor, with is quite liked from what I read here and there.
It is C# vs Typescript. Modern JavaScript is a very good language, and when enhanced with TypeScript's static types, it is every bit as good as C#.
XAML and MVVM is all about two-way data binding. JS frameworks copied it at first. But now it is widely recognized that 2-way data binding is a bad idea.
Imagine for a moment that your current employer is paying you significantly less than the market value for your role based on your skills and experience, and attempts to request a review of your compensation have been rejected. You may then consider looking for work elsewhere. It’s likely that the question of your current salary will come up at some point during the interview process with a potential employer.
What would you do in this situation? On the one hand, if you’re honest about how much you currently earn, the potential new employer may be reluctant to offer a significantly higher wage… even if it is the “market value”. On the other hand, if you exaggerate your current salary to reflect a figure that’s on-par with what you should be earning, you risk getting caught in a lie when that employer screens you using The Work Number. Clearly, neither situation is ideal.
> It’s likely that the question of your current salary will come up at some point during the interview process with a potential employer.
This is why places like California and NYC have made this question illegal. Candidates can still volunteer this information if they want, and employers can verify it in that case.
But, as another commenter already said, there are ways people can learn to deflect that question toward what they're looking for instead of what they're already making. Recruiters usually accept this after a certain amount of pushback, though not always.
My answer to this is that I work at a giant monster mega bank. As a benefit of employment I have exclusive access to many various financial products with the option to personally refer people directly to financial advisors at the bank’s expense. It’s hard to put a value on that. To compete with the benefits from a mega bank I expect a salary of XXX.
Then they can ask for my current salary but I have largely invalidated the question.
I was once being paid way below market, and while I couldn't get a substantial raise, I eventually got a promise of a market salary in the near future. So I immediately started interviewing outside the company and told them about my promised salary when they asked what I was making.
Deflecting the question this way did work to get me hired at a more reasonable amount, without being dishonest according to my conscience. However, things rapidly soured, and it's possible they checked what my salary had been and never asked me to clarify, so I may have outsmarted myself.
In order to leave my current position I'd need an offer of $XXX. My current salary does not include additional side benefits that company X offers that you don't.
