Wappler needs to be rewritten in TypeScript

Wappler General
#1

I said it here: rewrite in TypeScript and full test coverage. Wappler is treading on thin ice, particularly as you add more features.

Way, way too many bugs to be taken seriously. Doesn’t help that Wappler is accumulating decades of technical debt (Dreamweaver/DMX, threads about ASP are you kidding). Even coming from a professional dev background, I have tried for 3 weeks and I face bugs on a daily basis. It’s got to a point where it’s using up more time than it’s saving me.

Wappler is in this weird spot. Not as slick as Webflow for a perfect front end, and not nearly as flexible on the server side as writing code. Heck it’s much faster to just learn Vue.js. And may the gods help you if you try to do something advanced on the backend. It’s frustrating really.

I will try coding up the same project I did in Wappler these past 3 weeks and I will see how much faster I can get it done. I expect it to be at least half the time.

Also, the team might want to think about coding the Wappler app in Wappler. That’s the only way you will stay on top of your issues.

2021: The Year in Review
#2

Hmm, I think I completely disagree here. I’ve built around a dozen projects of varying complexity and Wappler is pretty much flawless (if there’s a bug, they fix it quickly) and has saved me weeks and weeks of coding time.

2 Likes
#3

Being borderline with Wappler is a common trait for those of us that use it on a daily basis.
One week you love it and the next week you just want to pay Teo a visit with the worst of the intentions(invite him to the worst brand of beer you can find).

You are suffering of a mix of excitement, weekly releases and knowing how to code. Some of us are in the same train as you.

Solution: we just skip some weekly versions until we are confident that a particular one is safe for us :smiley: As I said in your other post I am two versions behind currently.

For instance, I’m not upgrading to the next one until the team can confirm that it’s a bug and it’s being looked into or you just have absolutely no clue what you are doing with the tool :smiley: We have all been there at the beginnings.

Is this approach perfect? Nope
Is it enough? Yup. At least for me.
Do I understand the situation? Yes.

Edit: I didn’t reply to your main point. Typescript. Yeah. Why not? It will increase quality of any js based code base. Pretty sure it’s crossed their minds at some point. Still they are a small team for rewriting their app. Migrating to Electron could also be interesting. But they know their product better than us and their resources for something like this.

4 Likes
#4

@sitestreet there might be a bit of a bias in your comment if you are doing client websites and CRUD apps that fit the same model. I know professional devs who have boilerplates ready as well and they pump out full-fledged apps in 5-6 hours.

@JonL I laughed harder than I should.

I will hand code the same app I have right now and time myself to get more precise numbers on this.

#5

That’s some harcore dedication to back up a post with data :smiley:
Your are probably one of those psychopaths out there that do things like this just to prove a point :smiley:
true ? true : false

To be honest, I’m pretty excited you are going to do it.
Besides the time spent would you care to share your findings and even the source of both when you finish? I think it’s a pretty neat experiment.

#6

Yep, there probably is some bias. I’m building some pretty complex web apps (full CRMs, that kind of thing) and for that it’s the best tool and reduces my time spent by over 75% I reckon so I can now have multiple projects on the go at the same time and get them finished in good time.

Having direct contact with the devs is another big factor.

#7

My objective is not to back up my post. It’s rather to objectively measure how code compares to point and click for my specific use case. It’s easy to forget how much time you spend on Wappler when you are invested in it and still hold the belief that you are saving yourself time.

My gut feeling is I can code the same app in 3 days. I could be wrong, but that’s for me to find out.

2 Likes
#8

I agree that Wappler is much easier if you fit a specific model and have your Wappler project boilerplates ready to go for CRMs.

The same could be told of professional developers who have carefully selected SaaS nodejs boilerplates ready to go. Many of them deploy full blown SaaS in a matter of days.

#9

In my case I find it quicker to build on Wappler than code(and I still use a lot of it) due to the time saved not having to go through reference guides. One day a simple bootstrap class name decides to leave my brain so I need to go through the reference to look it up. Another day it’s a different class and so on. Then it’s a simple javascript method where I forget what optional arguments could be passed.

I find that Wappler saves me a bunch of time on that single topic: reference hunting.

#10

I start each project from scratch in Wappler and have done some pretty varied projects including an e-commerce site so not just CRMs. I definitely think it’s saving me a ton of time but my approach as a coder may be very different to yours and nowhere near as efficient so I’d be very interested to see the results.

Maybe put the spec up so we could try the same thing in Wappler and see how that fairs? It would then allow for Wappler experience (I’ve used it since day one but don’t consider myself experienced by a long shot) so the results aren’t skewed because you’re not so familiar with it.

#11

@sitestreet I am building a SaaS for small business/entrepreneurs to deploy a search engine without code. Basically the same thing as Algolia/Elasticsearch but for a different market, without the need to code. That means hosted front ends with domains/SSL hooked up with the search engine and load balanced and backed up. In a matter of a few clicks for the end user. A bit like Wordpress.

#12

Cool.

Out of interest. Are you using an existing engine(i.e. MeiliSearch, Typesense, Elastic), even a deeper library (Lucene, Solr, Sphinx) or are you building your own one from scratch?

Asking because I’m integrating MeiliSearch with a Wappler project as we speak.

#13

I forked both Typesense and MeiliSearch and I will keep an eye on both as they are still 0.x. I am going with MeiliSearch for the time being because I know Rust a bit better than C++, but they are essentially copies of each other/very close competitors (inverted index and a bucket sort). These projects are however heavily geared at developers. I am talking about a Wordpress experience, but with the same robustness.

1 Like
#14

Can you tell us some more on how you integrated MeiliSearch with Wappler when your done?

1 Like
#15

Will do.

I am building an omnisearch for my app and for now I’m just calling the REST API but I will eventually create a custom module to interact with the instance through the javascript SDK.

2 Likes
#16

@JonL you mentioned Electron. Isn’t Wappler made using Electron? For some reason I always thought it was done in Electron because of the lack of native menus on macOS

#17

would be keen to know what was the advanced backend thing you couldn’t do or had great difficulty to do with Wappler?

#18

Nwjs

I have the impression that Electron is better supported and will eventually eat nwjs.

#19

@nshkrsh resource provisioning and managing a small cluster - hooking up into other runtimes besides nodejs on select endpoints - restricting pages with 3rd party/webhook security providers - custom code on the fly (VM script?) - heck I couldn’t even get the wappler migrations to work with firebase alternatives. All in all if you fit a very specific “Wappler model” of an app (aka php+mysql or a dockerized node process) you will be happy.

@JonL I’ve used Electron since 2016 and it’s the first time I hear about nwjs

#20

Remember Popcorn Time desktop app? That’s nwjs.

But yes, it is not so known as Electron. Same principle though.