Unclear to me how much of the negative perspective of this is because of her gender. Media has a bias against female leaders. The fact that they don't put the whole email in there is concerning as well.
E.g. Stripe had a similar tone in that they basically wanted to maintain their margins but didn't get anything close to this type of negative coverage. No MLK quotes though
This is cool and in some world where the company becomes massive and basically commit to properly maintaining the product I could see it being a player.
I'm skeptical of open-sourcing UI and workflow builders.
The upsides are that you enable a community to build connectors and the UI builder + maintain them, but the downside is that you have to manage the community well enough that enterprises can trust the connectors and the UI builder. The challenge of maintaining the community + maintaining some sort of an SLA is very hard. This type of software is extremely hard to test for –writing integration tests are much harder for the frontend than they are for something like a database (e.g. MongoDB) because of the permutations of use-cases). The OSS+managed model seems to have succeeded in areas where very you can regression tests are much easier to maintain and there are clear benchmarks to test the community's output against.
As a buyer (we recently bought SuperBlocks (https://www.superblocks.com/) which is just a managed version of the same idea) it's hard to commit to an open-source version of something like this given the problems above. I may be totally wrong – I've never run an OSS+managed business, and as much as I love the ethos, I still have to not care about the stability of an internal tool builder that my company is being built on top of.
You have a good point about enterprise requirements and the challenge of wrapping an SLA around open source which is entirely or primarily made from community contributions. I ran into this all the time when I worked at Acquia which provides a platform for Drupal.
One thing to note - proprietary does not necessarily mean it is any safer or more stable than OSS. Superblocks is actually a closed source fork of Appsmith, so the code is very close to the open source version, but now it is not visible.
In my experience, proprietary vs OSS is not the issue, but maturity and support.
Most newer software either has undiscovered bugs, or develops them as they grow and become complex. More mature software tends to be more stable in general, and OSS projects with commercial backing tend to have the resources (and incentive) to focus on security and stability.
This is why I am so interested in the explosion of Open Source business models. In theory, it provides a more stable product and commercial support, while still being transparent about its code and being open to community contributions.
[Disclaimer: my company is using Superblocks and have been paying for it for about a year]
Been reading the comments and I think there are a bunch of questions about why companies would use a tool like this and that integrating your product / company into it is potentially risky. Here's why we decided to use it.
First thing you should know is that before we moved to Superblocks, we were using a combination of Retool, Google Cloud Scheduler, Mode Analytics, and a few small Google App Engine apps to solve our problems.
There is a whole ecosystem of apps and mini-products our engineering team has to build which require slow-paced maintenance, but are still mission critical to our business. Analytics dashboards, Slack reporters, revenue dashboards, customer service dashboards, Discord bots, etc.
There are plenty of different tools which solve some of those problems in silo, but the main problem (and beauty) of building internal apps is that you can fully solve for your unique business problem. We're a tech-enabled advertising agency (there are a handful of companies like ours in the world) and we both have our own external product as well as a series of internal apps that power our operations.
We decided to move all our internal apps to Superblocks effectively because we could merge a few different platform layer things (Google Cloud Scheduler, App Engine, Mode, Retool) and be able to build much faster within our team. The big thing for us was that we have engineers writing in Python (more data heavy stuff), and engineers writing Javascript. Previously, we had to have them offer APIs to each other and it wasn't as agile as it is today for simple things we had to build for our business stakeholders.
I remember seeing one of our first Workflows on Superblocks when our data scientist built a BigQuery step, a Python step, and then our Javascript engineers grabbing that to do some post-processing with it to display the data and thinking "this is probably how most tiny apps will get built in the future".
I don't want to have infrastructure for every tiny solution I built for our team. I just want things to work.
As a developer, the other concerns that I always want to be addressed around RPA / UI based tools are (1) how do I solve my problem when it outgrows the bounds of the product, yeah, you kinda have custom code I can enter via the webpage, but... (2) why do I have to use & learn your UI, let me use my normal tools
I use nvim, but yea, that is the point. Meet your users where they are, which is code for developers, not drag-n-drop, which is for non-developers. Pick your poison :]
Just to be clear, porting a drag-n-drop interface to VS Code is not meeting developers where they are.
Interesting point. Personal opinion here - I do not think that drag and drop is only for non-developers. A great example of this is the gaming industry in Unity/Unreal engine. These tools are effectively low-code but also incorporate drag and drop to allow developers to build whatever they can imagine but faster. Drag and drop should be an extension to the developer’s arsenal, not be the only way a developer can interact with the system.
I agree 100%, I want a drag-n-drop* but every single one has not met the expectations.
* what I want now is a little more and a product I plan to move from prototype to production soon (tm)
As I said in a peer comment, I get the game engine analogy, it's close, but there are enough differences that it doesn't carry enough weight to make it a point of justification. They've also had over a decade plus to develop and get lots of complaints. But note, there are 2-4 options in the game dev space, because it is so hard to build a compelling experience. Low code. / drag-n-drop is littered with shitty products and race to the bottom competitors. Also, my statements can generalize to DnD based solutions for more than frontend, to things like node red, iffft, zapier et al
Since Excel is on the front of HN, I'm reminded that Excel is the OG and most successful low code product in history
It's a great point, one interesting thing we've found is that backend developers are welcoming of using a drag and drop frontend builder, as long as it is extensible with code. For them using React, HTML, CSS is painful especially for an internal tool where the speed of getting their tool shipped is paramount.
Do you have analytics that back that up, or just statements and surveys?
As a backend focused dev who's very interested in low code, I've tried them all and they fall short after the honeymoon. Most recently Plasmic.app, had (has) great promise once their product matures. They nailed the developer facing workflow. The problem is twofold, (1) that the UI is big, slow, and buggy (2) the code that comes out the other side is super heavy. A blank component added 50% to my bytes shipped.
The hard question to answer is what does that interaction point look like? Why is the backend dev even tasked with doing the frontend?
You'll face a point where you will have to decide who your paid product is for, and every drag-n-drop for developers has pivoted to non-developers, because getting something that most developers actually love has proved impossible to date.
Not from statements and surveys, but from paying customers :)
We think our market area is wildly similar to the early days of gaming engines, echoing what pbardea commented earlier. We are providing the game-engine or the "tool-engine" if you will.
The reason backend developers are often tasked with building frontends on internal tools is because the frontend developers are often allocated fully to the core revenue-generating customer facing product.
As of today, we don't solve every use case pure code can. But over time we think there is a path to becoming the default and standard for this category of software, especially if we can nail the programmability aspect to win over developers.
There will be no default or standard in low code / drag n drop. It's a market that has been around a long time, very crowded, largely segmented, and a tough space to compete in.
I get the game engine analogy, used it myself, but it's a little apples and oranges. Very different personas, if you only have one persona for developers or even backend devs, you haven't narrowed down enough yet.
Re: "super heavy" output: A blank component should result in one corresponding div. Maybe you're weighing the API client library? You can codegen pure React modules if you don't want the loader library itself.
If you have any specific feedback on the UI, would love to listen. Thank you!
The whole thing is recorded, I posted a link to twitch in slack.
An unhydrated card like the testimonial example was 28k via code gen.
I put tons of feedback in that video, if your teams are not watching it, you are missing out immensely
Despite not pulling a lot of punches in my stream, I still think Plasmic is closest of all I have tried to a developer friendly, maybe lovable in time, product
I'm generally a fan of reducing complexity for building internal tools. We used to use Retool with a combination of Google's App Engine, Google Cloud Scheduler, and Mode Analytics to support our internal teams but we consolidated all of it under Superblocks.
They have charts, you can build backend functions (and call them on a schedule!), and you can build a UI just like you can with Retool (they have feature parity in most areas with Retool on the UI side).
The best part has been that they support Javascript and Python at the same time, which has let our data and engineering teams live in the same eco system and work together to build internal data tools for our team members.
Looks like the sample size has some bias built into it given the data is from those who use their performance software. I would trust the numbers from Firefox much more (higher scale, much more ubiquitous product).
52% of computers here are with 2 cores. 40% are with 4gb of RAM or less. 20% are 32bit, which haven't been sold for god knows how many years. These stats do not represent new PC that are being sold.
Looking at your "The Best Store of Money" – I'm baffled that First Republic Bank even made the list. We're in the process of switching away from them because of how broken their web interfaces are, and how hard it is to connect them to other tools which makes it hard for our accounting team to automated their work.
I think you really need to do a lot more interviews with people that have been users of these products.
Hey, thanks for the datapoint! I'd like to break your comment down into what I believe are the two main points, and address them independently.
1. On whether or not FRB should be in the list — we certainly think they should. Based on the founder surveys we sent out, we found that FRB was quite-well represented across the startup community (and I think that your datapoint adds to that finding). Our inclusion of a company/product is not an endorsement, but rather a result of what we think would be useful to test for the community. In this case, we evaluated FRB because we know a lot of founders (including yourself) have considered/are using them.
2. On whether our evaluation reflects your experience — this is the more interesting point for us. We have data from ~15 founders re: FRB, ranging from full-blown interviews to anecdotes. In general, we didn't hear anything substantially negative about their core banking service, but we aren't going to conclude that they're perfect from that data alone. That said, the founder data was informative enough to draw some directionally-accurate conclusions from, although additional data points help us both realign as well as shrink or expand our confidence interval.
If you're willing to email me about your experience with FRB, we'd very much like to look it over and take it into account when we update the guide.
On 1: this is because they've done a great job with partnerships. Cerkly's corporation set-up becomes free if you sign up with FRB – this was a YC deal we used. So this doesn't mean much.
2. I recognize that this is generally a hard job. Our original product/company was along the same lines as Wirecutter (https://www.digitaltrends.com/mobile/ask-suto-launch/) and it's an extremely tough path to take. I do feel that it's easier for businesses since the value-props/features are a lot more distinct in how businesses make decisions.
I've been a repeat startup employee, and have now become a founder. The reasons I chose to live this path haven't changed.
If you have a comp.-driven mindset (i.e. you'd like to become a millionaire in X years), then I think there are far faster, better, easier ways to achieve that. Join a top-tier firm in the valley / NYC and do a decent job at getting promotions and you'll be well within your way by your mid-late thirties.
The best part of being part of a startup is your ability to be in fast-paced multifaceted problem-solving environment.
You can play quiet a few roles at a small company. As an early employee (engineer or otherwise), you can look at any part of the company, product or its internal operations and decide that it's something you care enough about to fix and improve upon.
I joined my first startup as an engineer, became a product manager, did sales, built employee on-boarding flows and training manuals, re-branded the company and learnt how to manage a sizable team as I moved on to marketing. All within less than 2 years.
You can get most of those experiences elsewhere, but not within that timeframe or the depth of autonomy you would receive to get it done is not attainable in a Big Corp.
This is exceptionally great if you're early in your career, are generally good at getting tasks done, but have no idea what your calling is. You can work at a startup (or a series of them) for a few years and walk away with understanding what you'd like to focus your time and money on for the next few decades of your life.
Only caveat that I would add is that if you'd like to achieve any of that, then it's paramount that you look for the right founders. Founders that are willing to give away autonomy and let you flourish. They tend to be the best ones and produce great companies with incredibly rich cultures as a result.
I have no degree, but have had a documentary made about my first startup in Canada + speak at conferences / meet-ups from time to time, have a couple of pieces of press and have a profitable business with a handful of employees
E.g. Stripe had a similar tone in that they basically wanted to maintain their margins but didn't get anything close to this type of negative coverage. No MLK quotes though