5 ms·

UIs are way harder. Back in the day, you could drag and drop form controls in VB and bind the data to a database without writing a single line of code. Today, e

by memset 4y ago

UIs are way harder. Back in the day, you could drag and drop form controls in VB and bind the data to a database without writing a single line of code. Today, every step of that requires boilerplate. Backend, fronted, rest api, and so on. Distributing native apps has gotten harder in some ways with code signing required in order to share binaries without scary pop ups or the OS blocking outright.

gw99 4y ago
Oh yes this. I wrote a timesheet system in VB4 32-bit back in the day in 4 days and rolled it out to 10,000 users. And it worked. And it stayed working for 15 years until it was replaced. In 4 days worth of work now, I couldn't even do an evaluation of which UI tech is still going to be around in 2 years...
nhance 4y ago
If you haven't been watching the low-code/no-code space you may be in for a rude awakening. These tools continue to get better every day. The target is only "good enough" and once reached it presents an outsized advantage over custom builds. I fully expect no-code/low-code to grow in nearly permanent ways within many organizations.
- bornfreddy 4y ago
  Any examples that are interesting?
  - mike_hearn 4y ago
    For example Oracle APEX comes with their DB and has a lot of capabilities. https://apex.oracle.com/en/ https://apex.oracle.com/en/ The demo video takes you through creating a full blown database backed app with maps and other geo features, from nothing more than an initial CSV file. The code backing the app is represented as database tables, so you can use queries to explore the app. The core issue is really the same one the no-code/low-code platforms have always had, or even that VB6 had - the ramp isn't smooth. Eventually you hit the limits of the tool or there's a business requirement the tool can't meet and you get stuck. Often that requirement may be something indirect and non-obvious, like growing the team to the point where you start needing 'real' abstractions, or keeping up with some new feature the underlying platforms added that competitors are exploiting but which aren't exposed. Hence why so many companies have mobile apps that are just ordinary Android/iOS apps instead of written using low-code tools.
    - gw99 4y ago
      I've been through that "no code" cycle at least three times, ironically including Oracle in two of those cycles, and they always died on their ass. I suspect the same will happen again. It's really hard to build something generic enough. MS Access was as near to it as was feasible I suspect.
      - thorin 4y ago
        Oracle Apex has been around for over 20 years and is still in use by many people who have Oracle Db or product installations so if it is dying, it isn't dying quickly. It's actually really good for a lot of use cases.
    - mawadev 4y ago
      I worked with apex and I must say, the premise and structure are nice and you learn the basic architecture of web apps as a beginner. BUT the performance is _very bad_ if you don't throw money at oracle. The final nail in the coffin was when customers want you to build something that the blackbox doesn't offer. You are in for a wild wild ride, because whatever happens in the backend is undocumented, you cannot debug it properly.
mike_hearn 4y ago
Code signing requires you to buy certificates, but that's the sort of thing you can delegate to a non-technical assistant as it mostly involves filling out forms, getting access to the corporate credit card and/or receiving phone calls. In very large organizations you probably have code signing certs already and will need to find who has access to them, although there's no theoretical reason why you can't have different departments independently buy certificates for the same organization. The bigger pain, and one reason why desktop apps became less popular, is that with the rise of macOS and (to some extent) Linux, you need to distribute your app to three platforms all of which use different code signing technologies and approaches, none of which are portable/standards based or convenient. Also, software update was ignored by platform vendors. Nowadays things are a bit different. Windows got MSIX, which is a real package manager and which can silently upgrade apps in the background on a schedule even if they're currently running. macOS has the widely used Sparkle framework for updates and of course Linux has had updating package managers for a long time. Up until recently it was still a pain to actually use all those technologies, even though maybe developing your {JVM,Electron,Flutter,native,etc} app was itself quite pleasant and easy. My company has made a tool to fix that [1] and so you can now build self-updating Windows/Mac/Linux packages from your app files and all the signing is handled for you locally. It's an abstraction over the platform-native distribution technologies designed with an obsessive focus on being as simple as web app distribution is. Making this stuff easy in turn opens up possibilities for (re)simplifying the dev stack. For example, in some cases you could now make an app that just logs in directly to your RDBMS. No need for a backend/frontend, REST, JSON, web server frameworks, giant JS transpiler pipeline etc. Just use a real GUI toolkit and connect it directly to the output of queries. Any privacy or business logic can be implemented this way using a mix of row-level security [2], security-definer stored procedures [3] and RDBMS server plugins (e.g. [4] or [5]). There are lots of nice things about this, for example, it eliminates a lot of nasty security bugs that are otherwise hard to get rid of (XSS, XSRF, SQLi etc). [1] https://www.hydraulic.software https://www.hydraulic.software [2] https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [3] https://www.postgresql.org/docs/current/sql-createprocedure.html https://www.postgresql.org/docs/current/sql-createprocedure.... [4] https://tada.github.io/pljava/ https://tada.github.io/pljava/ [5] https://pgxn.org/dist/plv8/doc/plv8.html https://pgxn.org/dist/plv8/doc/plv8.html

by memset 4y ago

gw99 4y ago

Oh yes this. I wrote a timesheet system in VB4 32-bit back in the day in 4 days and rolled it out to 10,000 users. And it worked. And it stayed working for 15 years until it was replaced. In 4 days worth of work now, I couldn't even do an evaluation of which UI tech is still going to be around in 2 years...

nhance 4y ago

If you haven't been watching the low-code/no-code space you may be in for a rude awakening. These tools continue to get better every day. The target is only "good enough" and once reached it presents an outsized advantage over custom builds. I fully expect no-code/low-code to grow in nearly permanent ways within many organizations.

bornfreddy 4y ago
Any examples that are interesting?
- mike_hearn 4y ago
  For example Oracle APEX comes with their DB and has a lot of capabilities. https://apex.oracle.com/en/ https://apex.oracle.com/en/ The demo video takes you through creating a full blown database backed app with maps and other geo features, from nothing more than an initial CSV file. The code backing the app is represented as database tables, so you can use queries to explore the app. The core issue is really the same one the no-code/low-code platforms have always had, or even that VB6 had - the ramp isn't smooth. Eventually you hit the limits of the tool or there's a business requirement the tool can't meet and you get stuck. Often that requirement may be something indirect and non-obvious, like growing the team to the point where you start needing 'real' abstractions, or keeping up with some new feature the underlying platforms added that competitors are exploiting but which aren't exposed. Hence why so many companies have mobile apps that are just ordinary Android/iOS apps instead of written using low-code tools.
  - gw99 4y ago
    I've been through that "no code" cycle at least three times, ironically including Oracle in two of those cycles, and they always died on their ass. I suspect the same will happen again. It's really hard to build something generic enough. MS Access was as near to it as was feasible I suspect.
    - thorin 4y ago
      Oracle Apex has been around for over 20 years and is still in use by many people who have Oracle Db or product installations so if it is dying, it isn't dying quickly. It's actually really good for a lot of use cases.
  - mawadev 4y ago
    I worked with apex and I must say, the premise and structure are nice and you learn the basic architecture of web apps as a beginner. BUT the performance is _very bad_ if you don't throw money at oracle. The final nail in the coffin was when customers want you to build something that the blackbox doesn't offer. You are in for a wild wild ride, because whatever happens in the backend is undocumented, you cannot debug it properly.

mike_hearn 4y ago

Code signing requires you to buy certificates, but that's the sort of thing you can delegate to a non-technical assistant as it mostly involves filling out forms, getting access to the corporate credit card and/or receiving phone calls. In very large organizations you probably have code signing certs already and will need to find who has access to them, although there's no theoretical reason why you can't have different departments independently buy certificates for the same organization. The bigger pain, and one reason why desktop apps became less popular, is that with the rise of macOS and (to some extent) Linux, you need to distribute your app to three platforms all of which use different code signing technologies and approaches, none of which are portable/standards based or convenient. Also, software update was ignored by platform vendors. Nowadays things are a bit different. Windows got MSIX, which is a real package manager and which can silently upgrade apps in the background on a schedule even if they're currently running. macOS has the widely used Sparkle framework for updates and of course Linux has had updating package managers for a long time. Up until recently it was still a pain to actually use all those technologies, even though maybe developing your {JVM,Electron,Flutter,native,etc} app was itself quite pleasant and easy. My company has made a tool to fix that [1] and so you can now build self-updating Windows/Mac/Linux packages from your app files and all the signing is handled for you locally. It's an abstraction over the platform-native distribution technologies designed with an obsessive focus on being as simple as web app distribution is. Making this stuff easy in turn opens up possibilities for (re)simplifying the dev stack. For example, in some cases you could now make an app that just logs in directly to your RDBMS. No need for a backend/frontend, REST, JSON, web server frameworks, giant JS transpiler pipeline etc. Just use a real GUI toolkit and connect it directly to the output of queries. Any privacy or business logic can be implemented this way using a mix of row-level security [2], security-definer stored procedures [3] and RDBMS server plugins (e.g. [4] or [5]). There are lots of nice things about this, for example, it eliminates a lot of nasty security bugs that are otherwise hard to get rid of (XSS, XSRF, SQLi etc). [1] https://www.hydraulic.software https://www.hydraulic.software [2] https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html [3] https://www.postgresql.org/docs/current/sql-createprocedure.html https://www.postgresql.org/docs/current/sql-createprocedure.... [4] https://tada.github.io/pljava/ https://tada.github.io/pljava/ [5] https://pgxn.org/dist/plv8/doc/plv8.html https://pgxn.org/dist/plv8/doc/plv8.html