Google App Maker(developers.google.com)
developers.google.com
Google App Maker
https://developers.google.com/appmaker/
82 comments
Thank you.
I have a colleague, a graphic designer who is nearing retirement age. Every time Adobe announces a new software tool, she's partly excited, mostly terrified. Adobe likes to show how newbie-friendly these tools are. One click here, another there, and...project is done. She pays money to visit these demonstrations at conferences. Then she watches on, imagining her billable hours being redirected to an intern, the client's nephew or someone like that.
Usually the terror gets a sort of beachhead in her mind, and for a while my colleague bears the cognitive cost of this "well there's no need for me anymore" anxiety. It's really sad to watch.
> There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.
This is so true. I wish everyone fearing for their career due to new tech could understand it. Braided into a broader whole of business process you've got huge loads of necessary mental capital too, like the ability to deliver on multiple deadlines, the ability to set healthy boundaries, set proper budgets, and communicate well with others. My colleague has all these things; if only she could see new technology is only a small part, and overall a very forgiving part that needs humans like her more than we might think.
I have a colleague, a graphic designer who is nearing retirement age. Every time Adobe announces a new software tool, she's partly excited, mostly terrified. Adobe likes to show how newbie-friendly these tools are. One click here, another there, and...project is done. She pays money to visit these demonstrations at conferences. Then she watches on, imagining her billable hours being redirected to an intern, the client's nephew or someone like that.
Usually the terror gets a sort of beachhead in her mind, and for a while my colleague bears the cognitive cost of this "well there's no need for me anymore" anxiety. It's really sad to watch.
> There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.
This is so true. I wish everyone fearing for their career due to new tech could understand it. Braided into a broader whole of business process you've got huge loads of necessary mental capital too, like the ability to deliver on multiple deadlines, the ability to set healthy boundaries, set proper budgets, and communicate well with others. My colleague has all these things; if only she could see new technology is only a small part, and overall a very forgiving part that needs humans like her more than we might think.
I think that people in the tech world underestimate how foreign this all is to a lot of people. We've had "form builders" in various incarnations for a long long time. Most people don't have the first clue what to do with them, and don't even want to try.
The new low-code solutions are still used by developers, just allows get to develop much faster without having to worry about UI and cross-platform compatibility and other time consuming things that take up time when building a custom app.
I'm afraid that the new generation of low code solutions are not just "form" builders or prototyping tools. We've built a full operational system and client facing portal using a low code solution.
I'm afraid that the new generation of low code solutions are not just "form" builders or prototyping tools. We've built a full operational system and client facing portal using a low code solution.
Point out to her that her (and your) customers are not the people who are getting Adobe products and doing their own design work. The people who will take advantage of the new tools that freak her out are mostly people who are already doing it, they're just not doing it as well.
Her customers are the people who want someone to "make this work" and who don't want to mess with it themselves any more than they want to buy a big chest of tools and do their own vehicle maintenance.
Her customers are not the skilled amateurs now getting better tools. Her customers are the business people who already have too many things to do and aren't looking for ANOTHER project to add to their plates.
edit: minor phrasing
Her customers are the people who want someone to "make this work" and who don't want to mess with it themselves any more than they want to buy a big chest of tools and do their own vehicle maintenance.
Her customers are not the skilled amateurs now getting better tools. Her customers are the business people who already have too many things to do and aren't looking for ANOTHER project to add to their plates.
edit: minor phrasing
> It means we have a new prototyping tool. Cool. Don't worry, your skills aren't going to become obsolete
Not at all actually. There is a ton of demand for light code app builders (waves hand) for simple CRUD stuff in most businesses. These apps are usually cost prohibitive to build and maintain, so things App Maker make a ton of sense.
Not at all actually. There is a ton of demand for light code app builders (waves hand) for simple CRUD stuff in most businesses. These apps are usually cost prohibitive to build and maintain, so things App Maker make a ton of sense.
What happens when the business outgrows what AppBuilder can do? I would assume that's a ground up rewrite. Seems like it's kicking the issue down the road and accumulating technical debt along the way.
> What happens when the business outgrows what AppBuilder can do?
Then they just find an off-the-shelf solution (SaaS most likely) to replace it.
> Seems like it's kicking the issue down the road and accumulating technical debt along the way.
If you do a ground-up rewrite or find an off-the-shelf solution then technical debt doesn't matter anyway does it?
Then they just find an off-the-shelf solution (SaaS most likely) to replace it.
> Seems like it's kicking the issue down the road and accumulating technical debt along the way.
If you do a ground-up rewrite or find an off-the-shelf solution then technical debt doesn't matter anyway does it?
You see this same situation with large and small legacy systems that have reached end of life and need to be replaced. In some since the app or system can serve as the requirement for the replacement, but no one ever sees it that way. Why is the rewrite late? Still waiting for requirements! That running system over there is your requirement! Wait, that old crap? Yes that old crap.
What happens when the business outgrows what AppBuilder can do?
They use AppBuilder 2.
The flaw in your argument is that you're assuming the business grows while AppBuilder remains the same, or even just grows less quickly. There's no reason to think that would be the case. Scaling is a problem that Google and Amazon have really worked hard at solving. Plus for every business that outgrows AppBuilder there'll be 100 that don't, which still represents a huge contraction in the need for developers.
Automated code generators are coming, and they're going to be really good at writing code. If your job is writing code, learn to do other things as well.
They use AppBuilder 2.
The flaw in your argument is that you're assuming the business grows while AppBuilder remains the same, or even just grows less quickly. There's no reason to think that would be the case. Scaling is a problem that Google and Amazon have really worked hard at solving. Plus for every business that outgrows AppBuilder there'll be 100 that don't, which still represents a huge contraction in the need for developers.
Automated code generators are coming, and they're going to be really good at writing code. If your job is writing code, learn to do other things as well.
I mean grow in complexity, not scalability. The crux of the issue, and why all of these type things fail to gain enough coverage to concern me, is business grow in complexity. Each. Individual. Business. Cumulatively it's exponential complexity. These type solutions are general solutions designed as one size fits all. In reality, that usually covers small businesses and for a short period of time. All businesses are niche.
Wordpress, Wix, Access, Oracle Applications, etc. were all thought to solve the problem of development expense and they have all failed. I mean they get some coverage, but once a business grows in complexity, they quickly become obsolete, or in the case of larger apps, configuration is more complex and error prone than developing the application.
They probably don't pivot very well either. Maybe Google will figure it out, but I don't think they will.
Wordpress, Wix, Access, Oracle Applications, etc. were all thought to solve the problem of development expense and they have all failed. I mean they get some coverage, but once a business grows in complexity, they quickly become obsolete, or in the case of larger apps, configuration is more complex and error prone than developing the application.
They probably don't pivot very well either. Maybe Google will figure it out, but I don't think they will.
I don't think that for instance MS Access has failed. It was and still is a very good solution when it comes to creating line of business apps (within days) that have forms, reports and database access (for teams with up to ten members). These teams don't need anything that is more complex than that.
I don't know better solutions for developing RAD (rapid app development) apps for companies who are running on the Microsoft stack and who don't have dedicated dev teams.
Now for them Google App Maker is a very interesting solution.
Actually Google addresses these kind of users explicitly in their early access application form.
I don't think that this platform was intended to replace Frontend Development, React, Angular, etc
I don't know better solutions for developing RAD (rapid app development) apps for companies who are running on the Microsoft stack and who don't have dedicated dev teams.
Now for them Google App Maker is a very interesting solution.
Actually Google addresses these kind of users explicitly in their early access application form.
I don't think that this platform was intended to replace Frontend Development, React, Angular, etc
That's what's been promised for last 30 years :)
It is, and if you compare the resources needed to build software 30 years ago to the resources we need now it's pretty obvious we've made some incredible advances that will continue to make it possible to build software with even less.
Better to build for today, than be consumed with what might be tomorrow
I work in a huge company. Being consumed with what might be tomorrow is taken to an extreme. Given what I hear from other companies, this is very common. Sad part is, it never works. Designs don't ever match up with real world requirements (they match up very well to stated requirements). Anticipated changes never happen, but other changes do, and ... then of course a rewrite is needed, after attempting to get 2-3 unanticipated changes built into the "agile" design. "Technical debt", is the explanation, often without any further clarification.
We have inventory control systems that have their own database server (including disk format, their own indexing system, ...), own query language (because, ... euhm ... needless to say, someone wrote a script that dumps their own database into a mysql, and deletes and rebuilds the mysql every 2 hours, and everyone uses that to query the data. These days, even including the team that built the product). Impressive code (or I should say, impressive that it doesn't burn down our data more often). The point of doing/having done this ? It makes everyone's life more complicated, which seems to mean more reason to promote the participants.
Of course, failure of designs and over complicated designs is always seen as a reason to do more design (every postmortem, every time), with more anticipated future evolution, instead of less. Better and more accurate product managers, better and more accurate requirements (that are never going to come). I shudder to think what happens after rewriting databases from scratch has become the norm. More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
Cynicals say that this is simply "CV-first engineering". Of course the database system for your company ticketing system needs to scale to 50000 employees, and 1 billion customers, never mind that you have 10 at the moment. When you go and interview at Google/Facebook/Amazon, and they ask you "what have you built", are you going to answer "a system that works really well for our 100-person 500-customers company" which runs really well on a single cloud server. They'll laugh you out of the room. (of course reality is that no, they won't laugh you out of the room)
We have inventory control systems that have their own database server (including disk format, their own indexing system, ...), own query language (because, ... euhm ... needless to say, someone wrote a script that dumps their own database into a mysql, and deletes and rebuilds the mysql every 2 hours, and everyone uses that to query the data. These days, even including the team that built the product). Impressive code (or I should say, impressive that it doesn't burn down our data more often). The point of doing/having done this ? It makes everyone's life more complicated, which seems to mean more reason to promote the participants.
Of course, failure of designs and over complicated designs is always seen as a reason to do more design (every postmortem, every time), with more anticipated future evolution, instead of less. Better and more accurate product managers, better and more accurate requirements (that are never going to come). I shudder to think what happens after rewriting databases from scratch has become the norm. More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
Cynicals say that this is simply "CV-first engineering". Of course the database system for your company ticketing system needs to scale to 50000 employees, and 1 billion customers, never mind that you have 10 at the moment. When you go and interview at Google/Facebook/Amazon, and they ask you "what have you built", are you going to answer "a system that works really well for our 100-person 500-customers company" which runs really well on a single cloud server. They'll laugh you out of the room. (of course reality is that no, they won't laugh you out of the room)
A very interesting answer. I could very much identify with what your saying.
> Designs don't ever match up with real world requirements (they match up very well to stated requirements).
Perhaps the most important discipline in computing isn't anything related to technology, but is instead "requirements analysis". What does your company generally use to communicate and record requirements - use cases/stories/other? Are we just still struggling with the same old problem - data can be modeled easily, but not complex behavior?
> More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
Do you think these people don't know their own requirements because: aspects of the complex underlying real-world problem or system are difficult or unknown to them; they are trying to describe something new in their imagination; the mechanism for writing the requirement is vague meaning it inevitably needs to be further decomposed; something else?
> The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
How do proponents of these "custom" database engines justify them if they are not really needed? Is management clueless?
> Designs don't ever match up with real world requirements (they match up very well to stated requirements).
Perhaps the most important discipline in computing isn't anything related to technology, but is instead "requirements analysis". What does your company generally use to communicate and record requirements - use cases/stories/other? Are we just still struggling with the same old problem - data can be modeled easily, but not complex behavior?
> More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
Do you think these people don't know their own requirements because: aspects of the complex underlying real-world problem or system are difficult or unknown to them; they are trying to describe something new in their imagination; the mechanism for writing the requirement is vague meaning it inevitably needs to be further decomposed; something else?
> The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
How do proponents of these "custom" database engines justify them if they are not really needed? Is management clueless?
If App Maker takes an order of magnitude less time than writing the software they want, then it can be low-risk.
If something takes a long time and may not work, that's when it's risky.
If something takes a long time and may not work, that's when it's risky.
Because it's harder to read code than to write it, most freelancers/contractors a small business would get will insist on a rewrite anyway.
Sometimes this is truly justified (especially when the code comes from a $2.50/hr "coder" off Upwork), but more often it's just people wanting to do things their own way and not deal with the cruft of another thing.
Sometimes this is truly justified (especially when the code comes from a $2.50/hr "coder" off Upwork), but more often it's just people wanting to do things their own way and not deal with the cruft of another thing.
You are underestimating how much of corporate america runs on spreadsheets, email and paper.
I'd say COBOL is a bad example. I personally know someone hit by that so bad he became homeless and ended up spray painting street numbers on curbs for money.
I've never understood how that could be possible. What makes COBOL programming so different from work in any other language as to make it impossible to pick up, say, C? I've heard numerous similar anecdotes, but never from programmers who struggled to transition from any language but COBOL. I'm sympathetic, but never having worked in COBOL myself, I can't help but be curious what makes it so distinct.
I spent many years working with COBOL & CICS on AS/400 and mainframe and PC.
COBOL is such an excellent high-level abstraction from the computer hardware that it's almost pseudo-code and one can translate business requirements very easily, but therefore working in nothing but COBOL isolates a developer from underlying technology and trends.
I wrote a few algorithms in COBOL, basic sorts and trees, which was really awkward and whilst it can be forced to do other tricks such as data compression and encryption[0] it's really not conducive to such tasks. As a result it's easy to sit in a COBOL-bubble writing IF...ELSE business code all day long and not do anything computer-sciency until the memory and skills fade.
Thankfully my COBOL programs called down to C programs to do nitty-gritty work otherwise I'd probably have been pigeonholed both in skills and career; many companies seem to ignore COBOL experience as 'not proper programming', for the reasons above. However being one of the few people dealing with the old COBOL code gave me huge experience in working with the business clients.
[0] we had one vendor offer us AES-in-COBOL for scary amounts of money.
COBOL is such an excellent high-level abstraction from the computer hardware that it's almost pseudo-code and one can translate business requirements very easily, but therefore working in nothing but COBOL isolates a developer from underlying technology and trends.
I wrote a few algorithms in COBOL, basic sorts and trees, which was really awkward and whilst it can be forced to do other tricks such as data compression and encryption[0] it's really not conducive to such tasks. As a result it's easy to sit in a COBOL-bubble writing IF...ELSE business code all day long and not do anything computer-sciency until the memory and skills fade.
Thankfully my COBOL programs called down to C programs to do nitty-gritty work otherwise I'd probably have been pigeonholed both in skills and career; many companies seem to ignore COBOL experience as 'not proper programming', for the reasons above. However being one of the few people dealing with the old COBOL code gave me huge experience in working with the business clients.
[0] we had one vendor offer us AES-in-COBOL for scary amounts of money.
CObol is the epitome of a walled garden. Everything from accessing data to ui is done the cobol way. Simple things like arbitrary length string and dynamic memory allocation aren't in standard cobol.
Many companies used to run cobol bootcamps to hire developers. As recently as 2004, one local company was still doing them here. Very few of their developers studied cs in school. The boot campers studied who knows, and those who studied computers often majored in cis or mis.
So you can see how those people are really starting off at zero when it comes to switching to more modern dev stacks. I've personally seen very few make the transition.
My first paid dev job was at such a place, doing mainframe cobol, but I'd been doing hobby programming since I was 12, and writing games in c++, so I wasn't typical. I completed a bs in cs at night and moved on.
Many companies used to run cobol bootcamps to hire developers. As recently as 2004, one local company was still doing them here. Very few of their developers studied cs in school. The boot campers studied who knows, and those who studied computers often majored in cis or mis.
So you can see how those people are really starting off at zero when it comes to switching to more modern dev stacks. I've personally seen very few make the transition.
My first paid dev job was at such a place, doing mainframe cobol, but I'd been doing hobby programming since I was 12, and writing games in c++, so I wasn't typical. I completed a bs in cs at night and moved on.
[deleted]
> you have to try pretty hard to become completely irrelevant in technology
Agreed. I don't know how it is in other countries, but most currency exchange offices I have seen in Romania use FoxPro software running on an MS-DOS equivalent. I haven't used FoxPro in the last 20 years, but some people still make a living with it.
[Now that I think about it... I have actually written a small program in Visual FoxPro last year to interface with a .NET application... huh.]
Agreed. I don't know how it is in other countries, but most currency exchange offices I have seen in Romania use FoxPro software running on an MS-DOS equivalent. I haven't used FoxPro in the last 20 years, but some people still make a living with it.
[Now that I think about it... I have actually written a small program in Visual FoxPro last year to interface with a .NET application... huh.]
>Just keep learning and building stuff, and you'll always be very employable.
This is true, but there are a few caveats.
The one that I've been running up against most recently is that a lot of this new-fangled stuff does not really have a strong value proposition, and I personally do not want to waste time on it.
This has become especially true since "cloud" hit critical mass. Junk seems to get generated 20 times faster than it used to and see much wider adoption. GitHub profiles are now status symbols and everyone feels a need to have a bundle of their own showpieces to display.
A lot of the fads are totally perplexing, from the perspective of an engineer who is more interested in building a robust system than padding his resume. JavaScript on the backend (or, even more horrifying, the desktop)? Single-page app frameworks like Angular for everything, including very simple pages? Why?
Yet, it's hard to find a web-oriented position that isn't asking for a background with some SPA and some Node.js. Maybe it's a fad, but it's still going to impact your job prospects.
The takeaway: stay on top of fads and new tech, even if you resent it and think it's really dumb.
I had the same experience with Rails; I hated so much about it and put off getting serious experience with it for 4 years or so. Turns out I still hate it after years of usage, but it was much easier to find work, both as an employee and a consultant, when I had significant experience in the fad.
Didn't matter that I was learning all kinds of new tech that I thought was interesting. As much as one may hate it, it's usually best to bite the bullet and ride the market's waves.
The most frustrating one today is Kubernetes and Docker. Ansible was so beautiful. I hate Docker with a seething passion (not necessarily other container systems), and I see Kubernetes as a very rough toolkit for people who have Google-scale problems that no one should be trying to make for themselves.
Other caveats:
* sometimes techs DO go extinct. Though COBOL is not quite extinct yet, I've known COBOL coders who have gone years unemployed (that doesn't happen to anyone who knows a language/stack still in wide circulation). A small niche has pros and cons, and one of the cons is that the supply:demand ratio is fickle, and may not always be in your favor.
* It is very rare that your technical qualifications will be so unique that they will take precedence over your personal and political qualifications. This is something most developers try to dance around, but the fact is that tech is ultimately run by people, and they want to be comfortable more than they care about that loop's runtime. If you're looking for something that will confer huge career benefits, the odds are that improving your people skills will be more valuable than improving your technical skills. This is almost universally true. It's especially true if you think it's not.
This is true, but there are a few caveats.
The one that I've been running up against most recently is that a lot of this new-fangled stuff does not really have a strong value proposition, and I personally do not want to waste time on it.
This has become especially true since "cloud" hit critical mass. Junk seems to get generated 20 times faster than it used to and see much wider adoption. GitHub profiles are now status symbols and everyone feels a need to have a bundle of their own showpieces to display.
A lot of the fads are totally perplexing, from the perspective of an engineer who is more interested in building a robust system than padding his resume. JavaScript on the backend (or, even more horrifying, the desktop)? Single-page app frameworks like Angular for everything, including very simple pages? Why?
Yet, it's hard to find a web-oriented position that isn't asking for a background with some SPA and some Node.js. Maybe it's a fad, but it's still going to impact your job prospects.
The takeaway: stay on top of fads and new tech, even if you resent it and think it's really dumb.
I had the same experience with Rails; I hated so much about it and put off getting serious experience with it for 4 years or so. Turns out I still hate it after years of usage, but it was much easier to find work, both as an employee and a consultant, when I had significant experience in the fad.
Didn't matter that I was learning all kinds of new tech that I thought was interesting. As much as one may hate it, it's usually best to bite the bullet and ride the market's waves.
The most frustrating one today is Kubernetes and Docker. Ansible was so beautiful. I hate Docker with a seething passion (not necessarily other container systems), and I see Kubernetes as a very rough toolkit for people who have Google-scale problems that no one should be trying to make for themselves.
Other caveats:
* sometimes techs DO go extinct. Though COBOL is not quite extinct yet, I've known COBOL coders who have gone years unemployed (that doesn't happen to anyone who knows a language/stack still in wide circulation). A small niche has pros and cons, and one of the cons is that the supply:demand ratio is fickle, and may not always be in your favor.
* It is very rare that your technical qualifications will be so unique that they will take precedence over your personal and political qualifications. This is something most developers try to dance around, but the fact is that tech is ultimately run by people, and they want to be comfortable more than they care about that loop's runtime. If you're looking for something that will confer huge career benefits, the odds are that improving your people skills will be more valuable than improving your technical skills. This is almost universally true. It's especially true if you think it's not.
I'm like you; I looked at Chef and thought "WTF??". I looked at Puppet and thought "WTF???". I looked at Ansible and thought "ahh, yes! they get it!"
Most of the application stacks I see that are popular I think of as being invented by people who didn't bother to look around at what had already been tried and rejected by the previous generation.
Caveat I don't build apps that need to scale to millions of users.
Most of the application stacks I see that are popular I think of as being invented by people who didn't bother to look around at what had already been tried and rejected by the previous generation.
Caveat I don't build apps that need to scale to millions of users.
Yeah ui frameworks. has anyone else noticed that yahuda Katz seems to have been completely unfamiliar with any other ui framework for the past 20 years? For example the superfluous stuff removed from 2.0? Sure the browser has unique requirements, but sheesh.
I tend to agree that a lot of the new-fangled stuff (aka. hipster shit stacks) are generational/cyclic re-hashes of previous techniques, but unlike previous generation don't even attempt to adhere to standards or otherwise appeal to ideas such as separation of interface/implementation and interchangeability in general. Supposedly, that's pre-generation POSIX or Java-ish greybeard stuff and we're living in a post-standards era after all.
But I think you should re-consider Node.js. JavaScript is based on an ECMA-specified (ISO-adopted even) language with at least three major implementations, plus smaller (yet still highly regarded) ones. The Node.js API is (loosely) based on CommonJS which is as good as it gets in terms of a community API standard for JavaScript.
But I think you should re-consider Node.js. JavaScript is based on an ECMA-specified (ISO-adopted even) language with at least three major implementations, plus smaller (yet still highly regarded) ones. The Node.js API is (loosely) based on CommonJS which is as good as it gets in terms of a community API standard for JavaScript.
Why do you hate Rails?
Genuine question. I'm not a fan of it either, after working with it for two years, but I can't quite explain why. Maybe it's the "magic" aspect of it, since so much is convention, DSL, and hidden away.
Genuine question. I'm not a fan of it either, after working with it for two years, but I can't quite explain why. Maybe it's the "magic" aspect of it, since so much is convention, DSL, and hidden away.
Yes, "the magic" is usually the way it's summarized. Everything is expected to be done exactly their way. Your code is interpreted and modified by Rails to fit its pre-conceptions and assumptions about your program. Neither the framework itself nor the support structure around it are forgiving if you deviate, no matter how justified the rationale.
One of the most prominent examples I remember is developing a form and explicitly setting the form's method in the Rails code, of course precisely according to the documentation because we know how picky it is. However, because of some minor detail in the content of the form (which I unfortunately don't remember specifically), I found that the Rails JavaScript was overriding me and dynamically changing the form's method when the form was submitted. I had to hack in the middle there to subvert that event.
It took forever to track that down, something that should've been so basic and simple. This is exactly the kind of anti-feature that developers resent: it's supposedly there to make things "easy" by assuming you meant something, when you've taken pains to say that you did not in fact mean that because you assume it's going to assume you meant that. When you complain, the Rails community blames you for not believing in magic hard enough.
That's emblematic of the entire Rails experience; it's just one example among many. We all know that any moderately-complex program is going to have unique requirements and want to do things that are a little out of the ordinary; if it didn't, you'd just be using something pre-built like Wordpress.
When you get to that point, you're going to be tearing your hair out and fighting Rails the whole way, as it insists that no, you didn't mean that when you explicitly defined it in the place the docs say to explicitly define it; you clearly meant the thing that Rails says you meant.
It'd be one thing if this type of behavior was acknowledged and respected as a bug, but it's not. The response you get is usually along the lines of "Well, why were you trying to disobey Daddy Rails? You are a very naughty coder. DHH could surely beat you in a street race, and you probably haven't even read REWORK." The Rails community is a cargo cult.
Rails is not to be introspected or customized. It is only to be appreciated and praised. After all, you are not as successful as 37Signals, are you?
And don't you like magic? Are you not entertained? Magic won't work if you change all the stuff. Don't ruin the magic! The great visionary DHH has come down with the visions of what web applications should be. Do not defy him.
They try to cover all of this up by saying that they believe in "convention over configuration". This means that if you question Rails, for any reason, you will be punished for your insolence. They truly despise heretics.
That's not how frameworks are supposed to work! I sometimes don't even like calling Rails a framework because it's so rigid. Frameworks are supposed to give users the tools and flexibility they need and then get out of the way.
If I feel like I'm writing Ruby (or whatever the base language is) and the framework is just helping me get that code onto the web (or provide whatever the framework's function is), then I'm happy. If I feel like I have to write in a special framework-specific dialect, then it's not a framework; it's a platform, and I'm writing a plugin for it.
I think this revulsion from big-magic black box "frameworks" like Rails and CakePHP led to the rise of "microframeworks", or "semi-reasonable ways to put code behind a web site", as normal people call them. ;)
One of the most prominent examples I remember is developing a form and explicitly setting the form's method in the Rails code, of course precisely according to the documentation because we know how picky it is. However, because of some minor detail in the content of the form (which I unfortunately don't remember specifically), I found that the Rails JavaScript was overriding me and dynamically changing the form's method when the form was submitted. I had to hack in the middle there to subvert that event.
It took forever to track that down, something that should've been so basic and simple. This is exactly the kind of anti-feature that developers resent: it's supposedly there to make things "easy" by assuming you meant something, when you've taken pains to say that you did not in fact mean that because you assume it's going to assume you meant that. When you complain, the Rails community blames you for not believing in magic hard enough.
That's emblematic of the entire Rails experience; it's just one example among many. We all know that any moderately-complex program is going to have unique requirements and want to do things that are a little out of the ordinary; if it didn't, you'd just be using something pre-built like Wordpress.
When you get to that point, you're going to be tearing your hair out and fighting Rails the whole way, as it insists that no, you didn't mean that when you explicitly defined it in the place the docs say to explicitly define it; you clearly meant the thing that Rails says you meant.
It'd be one thing if this type of behavior was acknowledged and respected as a bug, but it's not. The response you get is usually along the lines of "Well, why were you trying to disobey Daddy Rails? You are a very naughty coder. DHH could surely beat you in a street race, and you probably haven't even read REWORK." The Rails community is a cargo cult.
Rails is not to be introspected or customized. It is only to be appreciated and praised. After all, you are not as successful as 37Signals, are you?
And don't you like magic? Are you not entertained? Magic won't work if you change all the stuff. Don't ruin the magic! The great visionary DHH has come down with the visions of what web applications should be. Do not defy him.
They try to cover all of this up by saying that they believe in "convention over configuration". This means that if you question Rails, for any reason, you will be punished for your insolence. They truly despise heretics.
That's not how frameworks are supposed to work! I sometimes don't even like calling Rails a framework because it's so rigid. Frameworks are supposed to give users the tools and flexibility they need and then get out of the way.
If I feel like I'm writing Ruby (or whatever the base language is) and the framework is just helping me get that code onto the web (or provide whatever the framework's function is), then I'm happy. If I feel like I have to write in a special framework-specific dialect, then it's not a framework; it's a platform, and I'm writing a plugin for it.
I think this revulsion from big-magic black box "frameworks" like Rails and CakePHP led to the rise of "microframeworks", or "semi-reasonable ways to put code behind a web site", as normal people call them. ;)
I've tried a lot of these tools. The trouble is that things go extremely well until you hit a wall. With no way to extend them with something like freeform code, the wall doesn't move.
The best ones, then, tend to be the ones that have been around long enough, or had enough foresight to have covered various corner cases.
The other issue is that most of them have "per user / per month" pricing, which doesn't work for many use cases. Things like, for example, an applicant tracking app. If you use the functionality to a high degree, every job applicant is another end user license.
Two of the better ones: http://quickbase.com & http://ragic.com
Other ones I've seen: http://caspio.com, http://knack.com, http://fusio.com, http://trackvia.com/, http://podio.com, https://www.zoho.com/creator/, http://airtable.com, https://getzenbase.com/, http://www.zenginehq.com/
One of the more promising ones was DabbleDB. Twitter acquihired them and shut the tool down. It had a very smooth UI: https://www.youtube.com/watch?v=MCVj5RZOqwY
The best ones, then, tend to be the ones that have been around long enough, or had enough foresight to have covered various corner cases.
The other issue is that most of them have "per user / per month" pricing, which doesn't work for many use cases. Things like, for example, an applicant tracking app. If you use the functionality to a high degree, every job applicant is another end user license.
Two of the better ones: http://quickbase.com & http://ragic.com
Other ones I've seen: http://caspio.com, http://knack.com, http://fusio.com, http://trackvia.com/, http://podio.com, https://www.zoho.com/creator/, http://airtable.com, https://getzenbase.com/, http://www.zenginehq.com/
One of the more promising ones was DabbleDB. Twitter acquihired them and shut the tool down. It had a very smooth UI: https://www.youtube.com/watch?v=MCVj5RZOqwY
My theory is that it is not the existence of a wall that limits these tools - it is the invisibility of the wall. Spreadsheets have a wall too, but it is pretty clear to naive users where it is. These app-in-a-can tools hit the wall suddenly and unpredictably - you need a new UI feature, or the data model can't be generalized, or you can't connect to some silo. Perhaps a better metaphor than a wall would be a mine field.
I've run into all the things you mentioned. Pretty quickly though.
One I hit in many of the tools was lack of a good UI widget for select fields that have lots of choices. Something like a combobox with autocomplete.
One I hit in many of the tools was lack of a good UI widget for select fields that have lots of choices. Something like a combobox with autocomplete.
Yeah - same story repeated decade after decade. "Build apps without coding" is one of those Siren ideas - it seems so compelling and necessary, yet everyone ends up using much the same design as has failed countless times before. I don't really understand exactly why this is so, but I'm pretty sure we need to figure that out to make progress.
These services are cloud services. They have another wall. Spiked, dark, cruel and ready to collapse on us at a second's notice. A new person getting hired at some critical services cloud company. Excellent suit. New CFO, or COO, or whatever. Nice MBA, economics degree, daddy's really important, he has been executive at some bank for decades, comes in. And something happens.
Maybe he sees pedestrian get shot on the street while he walks to his desk and smiles. Maybe a chair screeches on the floor, reminding him of the screams of some kid five years his junior he was beating up in high school. Maybe he cuts his hand on the edge of his giant mahogany desk and the drop of blood fondly makes him remember the thousands of children whose families he sucked dry, and condemned to abject poverty at his previous bank job, reveling in their inescapable fate. We will never know. An epiphany happens.
Then he proceeds to phone up some lead architect and asks the question "don't we fully control the data that these cloud 'customers' think is theirs" ? He likes the answer so much he fires the lead architect on the spot.
And his eyes twinkle.
Maybe he sees pedestrian get shot on the street while he walks to his desk and smiles. Maybe a chair screeches on the floor, reminding him of the screams of some kid five years his junior he was beating up in high school. Maybe he cuts his hand on the edge of his giant mahogany desk and the drop of blood fondly makes him remember the thousands of children whose families he sucked dry, and condemned to abject poverty at his previous bank job, reveling in their inescapable fate. We will never know. An epiphany happens.
Then he proceeds to phone up some lead architect and asks the question "don't we fully control the data that these cloud 'customers' think is theirs" ? He likes the answer so much he fires the lead architect on the spot.
And his eyes twinkle.
I totally agree with you. Most of these tools seems really neat and have seductive examples. Then when you use it for a project you end up needing some kind of customization which they do not accommodate.
I've saved countless hours by doing as you suggested - only using the tools that have matured, where all standard questions are already answered on stackoverflow and common corner cases are covered.
So when I see Google App Maker, my response is "cool, this might be something I can use in a year or two, let's see."
I've saved countless hours by doing as you suggested - only using the tools that have matured, where all standard questions are already answered on stackoverflow and common corner cases are covered.
So when I see Google App Maker, my response is "cool, this might be something I can use in a year or two, let's see."
It is possible extensibility will be via Google Apps Script, about as close to "freeform" code one can get in a sandbox. Google have successfully implemented Apps Script in a number of G Suite products so I would be optimistic about seeing it in App Maker for advanced scenarios. Fingers crossed
Looks like App Maker already supports JavaScript for both server and client scripting, including bindings to read and write data.
https://developers.google.com/appmaker/scripting/overview
https://developers.google.com/appmaker/scripting/overview
Oh sweet "Server scripts run on Apps Script. They can access databases directly and use Apps Script APIs like calendar, email, and more.".. This could be very interesting
Many of the tools I mentioned have scripting capabilities, but that doesn't keep you from hitting a wall, because you're scripting in whatever limited context they give you.
Sometimes the wall is the data model, or the construct they give you for navigation, access control, roles, etc.
Something like freeform javascript that executes in the client would help a lot, because you could patch around limitations in many cases.
Sometimes the wall is the data model, or the construct they give you for navigation, access control, roles, etc.
Something like freeform javascript that executes in the client would help a lot, because you could patch around limitations in many cases.
Creator of App Maker here, though it's been a while since I was on the team.
Smoothing out the transition from on-rails to off was one of the original design goals, so there was arbitrary server and client scripting from pretty early on, and a component model to create widgets. The project as moved from being hosted on App Engine to being hosted on Docs infrastructure, so I'm not sure what the specifics of extensibility are, but I suspect they're pretty good, but more Apps Script oriented. Should be a good solution for heavy Docs users.
My thinking in this space is that you really can have your cake and eat it too with these tools, though it requires a really thought-out design, and that they built-in features use the same extension points that are available to users.
With JavaScript available on the client and server it becomes less of an issue whether you can run code at all, and more of an issue of whether you can run at the right time and intercept the right flows. Especially with Web Components on the client pretty much taking care of components. Providing a standard router on the client and server with similar middleware and handlers, and also middleware/handlers on state changes, you can get close to easy to start with and fully extensible.
Smoothing out the transition from on-rails to off was one of the original design goals, so there was arbitrary server and client scripting from pretty early on, and a component model to create widgets. The project as moved from being hosted on App Engine to being hosted on Docs infrastructure, so I'm not sure what the specifics of extensibility are, but I suspect they're pretty good, but more Apps Script oriented. Should be a good solution for heavy Docs users.
My thinking in this space is that you really can have your cake and eat it too with these tools, though it requires a really thought-out design, and that they built-in features use the same extension points that are available to users.
With JavaScript available on the client and server it becomes less of an issue whether you can run code at all, and more of an issue of whether you can run at the right time and intercept the right flows. Especially with Web Components on the client pretty much taking care of components. Providing a standard router on the client and server with similar middleware and handlers, and also middleware/handlers on state changes, you can get close to easy to start with and fully extensible.
Sounds promising. This is why HN is so great. Meaningful insider feedback in the space of an hour. Thanks for that.
The other limiter is less technical. Finding a way to charge per user only for true internal users. That was my other stumbling block...tools that want to charge for everyone that touches a built app in any way whatsoever.
The other limiter is less technical. Finding a way to charge per user only for true internal users. That was my other stumbling block...tools that want to charge for everyone that touches a built app in any way whatsoever.
Replying to myself because I found an animated gif that gives a peek into some of the functionality. It does look fairly slick. https://storage.googleapis.com/gweb-uniblog-publish-prod/ori...
Hi - I am a Developer Evangelist at Zoho. I would love to have a chat sometime about what worked and more importantly what didn't for you guys. I really value your opinions at this time, especially since we are building some major changes into the product.
Please write to me at <username> at gmail dot com if interested. Cheers!
It means that there will be two new jobs related to this project.
1. App Maker developer wanted to create App Maker Apps .
2. Web developer needed to transition our App Maker App to a javascript / python / ruby standalone project.
1. App Maker developer wanted to create App Maker Apps .
2. Web developer needed to transition our App Maker App to a javascript / python / ruby standalone project.
Very well put. Tools like this, by lowering the barrier to entry of making software (I'm assuming the best case scenario - that App Maker is a quality product), tools like this expand the pie and make the software development industry larger. Wordpress is the perfect analogy here.
And a lot of my best freelance jobs recently have been for companies not traditionally in the tech industry who had a new idea they wanted to pursue, proofed the concept with a Wordpress site, and then once they had some degree of market validation, needed a developer to build it into something more robust and customizable.
And a lot of my best freelance jobs recently have been for companies not traditionally in the tech industry who had a new idea they wanted to pursue, proofed the concept with a Wordpress site, and then once they had some degree of market validation, needed a developer to build it into something more robust and customizable.
Note my comment was in response to the original title : google released this what does this mean ? (paraphrasing here don't remember the exact wording).
What does Google's "App Maker" mean for web developers?
I requested access a few months ago... still don't have it.
We are looking at a number of these rapid development tools. Hopefully google opens it up soon before we select a different one.
I'd be curious if this platform has sticking power. Google rolls these sorts of offerings out from time to time and then shuts them down. If I knew there was a couple years of runway for this offering my fears would go away.
We are looking at a number of these rapid development tools. Hopefully google opens it up soon before we select a different one.
I'd be curious if this platform has sticking power. Google rolls these sorts of offerings out from time to time and then shuts them down. If I knew there was a couple years of runway for this offering my fears would go away.
I'm about to dig into MS Powerapps. Comes with O365. https://powerapps.microsoft.com/en-us/
What are the alternatives you are looking at?
Make sure you have a G-suite Business account and your domain address is whitelisted within settings.
I must need this since I can't even get the sign-up form to work. So do you know any others?
I would highly recommend checking out https://www.dropsource.com/
I just disabled JS and CSS to get the form, and changed the select’s option to value="de">Germany<, and then simply submitted it like that.
I have no idea if it worked, but at least that way it does something. Per default, the form just doesn’t do anything for me.
I have no idea if it worked, but at least that way it does something. Per default, the form just doesn’t do anything for me.
From simplest to manage to most freedom:
App Maker < App Engine < Container Engine < Compute Engine (VMs)
So pick your poison for the business problem at hand. Don't host your blog on a dedicated VM. Don't use App Maker for training neural networks.
App Maker < App Engine < Container Engine < Compute Engine (VMs)
So pick your poison for the business problem at hand. Don't host your blog on a dedicated VM. Don't use App Maker for training neural networks.
I'd break App Engine into standard and flexible environments.
I've often wondered, if you could create a gui app maker like this where the app itself could be exported as, say, a Rails codebase at any time. That would help reassure organizations that wanted to use the service but were worried about lockin or the service shutting down.
Very interesting! This concept has been around for a long, long time in many guises - arguably recent examples are Zoho, Microsoft PowerApps, Salesforce perhaps... And many more going back to Access, Lotus Notes and dbase.
The question is really one of execution (and remaining modern). Too generic and it lacks a killer app. Too specific and it hides of a niche.
The question is really one of execution (and remaining modern). Too generic and it lacks a killer app. Too specific and it hides of a niche.
I've not seen one of these type of applications yet that allowed the flexibility needed to handle many (perhaps the majority?) of use cases gracefully.
What I have seen is non-programmers getting enough power to get overconfident only to wind up with a mess.
These type of applications make it super easy to do 85% of the work. Unfortunately the remaining 15% often turns out to be impossible. Additionally when requirements change (and when don't they?) there often isn't the flexibility needed to make the changes.
The last thing I've observed is when something goes wrong if the person can't drill down into the internals and make adjustments they are just plain out of luck. I've seen this with both Access and Lotus Notes. Companies struggle with bugs for years. I've had a fair share of work re-writing these type of applications into web applications which finally do what is really needed without issue and can be changed when required.
In short I'm not concerned. Seen it before. Works for very simple apps, blows up spectacularly when something non-standard is needed. And this makes work for me.
Maybe this time it will be different but I really don't think so.
What I have seen is non-programmers getting enough power to get overconfident only to wind up with a mess.
These type of applications make it super easy to do 85% of the work. Unfortunately the remaining 15% often turns out to be impossible. Additionally when requirements change (and when don't they?) there often isn't the flexibility needed to make the changes.
The last thing I've observed is when something goes wrong if the person can't drill down into the internals and make adjustments they are just plain out of luck. I've seen this with both Access and Lotus Notes. Companies struggle with bugs for years. I've had a fair share of work re-writing these type of applications into web applications which finally do what is really needed without issue and can be changed when required.
In short I'm not concerned. Seen it before. Works for very simple apps, blows up spectacularly when something non-standard is needed. And this makes work for me.
Maybe this time it will be different but I really don't think so.
I get the feeling that some day theyll get it right and 90% of programming jobs will dissapear.
Alright, so what's missing before web developers aren't needed anymore:
- speech recognition so that you tell what you want
- LEGO blocks for simple things that can be composed and adjusted by voice or AR gestures
- large amount of working code so that "glue" between blocks can be inferred using ML/DL
I am pretty sure App Maker 2.0 will have at least 1 of these finished.
- speech recognition so that you tell what you want
- LEGO blocks for simple things that can be composed and adjusted by voice or AR gestures
- large amount of working code so that "glue" between blocks can be inferred using ML/DL
I am pretty sure App Maker 2.0 will have at least 1 of these finished.
@dang, this title seems to be editorializing.
I thought it was framing a particular discussion, like an "Ask HN" post. Editorializing would mean asserting some sort of opinion--seems factual that this new tool has relevance to web developers.
I think it's more of the clickbait nature of the title.
Right. Changed from "What does Google's new tool “App Maker” mean for web developers?".
[deleted]
Google SharePoint?
Not sure if related but right now I'd trade knowledge for business insight, I can build things but I have no idea what to make that makes money. Right now I just build stuff for people.
It's funny 3-4 years ago when I first started to learn web dev, I had a lot of ideas that I thought would be "viral/make money" but now I have hardly any... a lot of my ideas back then were pretty dumb too looking back at it.
It's funny 3-4 years ago when I first started to learn web dev, I had a lot of ideas that I thought would be "viral/make money" but now I have hardly any... a lot of my ideas back then were pretty dumb too looking back at it.
If anyone here has requested access to App Maker and not received it yet please PM me. SADA Systems (my company) is partnered with google and have been in the early access program for App Maker kicking the tires. We offer app maker development and consulting services for companies looking to deepen their investment in g suite and build cool apps on top of it!
Are there limitations on data or records? I have a SQL database that I'd be interested in migrating over to a solution like this if it can handle 1M+ records without worry.
I believe there is a limit, but you can upgrade to use Cloud SQL.
And I've been thinking about moving my email to fastmail...And then Google tries to tempt me with this! Dang it, they know how to lure me back! :-(
If there is one line of apps that has consistently failed over the last 20 years it is these.
That everything will be replaced by machines including you? ;-)
All hail the new Wordpress of app development.
I once worked with a guy who embodied the "grumpy old man" (we were both just out of college btw) attitude for every new, cool thing I brought to his attention. I kept telling him that in order to stay relevant as a programmer in the foreseeable future he would have to stay on top of technology and keep his chops up outside of the very mundane engineering work that we did at that company. He would flatly refuse out of hand and say things like "Someone who only knows COBOL for 40 years will still have a job". It frustrated the hell out of me at the time, but he's probably right. Not saying you're guaranteed a great job or be making google-level salaries, but you have to try pretty hard to become completely irrelevant in technology. There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.
If you have even enough interest to be on this website and explore things like App Maker and question things like this, you're going to be just fine :)