Search results for:

Appreciate you taking the time for this response.

While I can not really argue against refactoring code into extra
functions: Please note that every function you add generates some
overhead = slower program. In the (I think it was the) calendar app I
once inlined the code of a function I previously extracted because it
slowed the execution by 100ms (It was called multiple times).

While this might be true in alot of real world projects, there isn't any direct correlation between oo approach and slower code. Javascript was never designed for it, which makes it harder to do well.

What would you change e.g. for GPS? You have setGPSPower(), isGPSOn(),
getGPSFix() and the GPS event on the Bangle-Object.

I was thinking higher level. I can give good examples once I look at the source code more and start making an app - which will almost certainly result in a side library for gps stuff.

Those examples you give are of the core functions. So firstly on those. If you call getGPSFix() and gps power has not been set on, what happens? I wouldn't suggest changing the core function to auto turn it on, as may be a reason you call getGPSFix without turning on GPS. However in most cases I imagine turning GPS on first is a requirement. So if create a higher level object like a GPS manager, calling myGpsManager.getFix() would check if GPS is currently on, if not set it on first.

At even higher level, its likely alot of apps actually want to do the same thing once they have GPS location, like overlay position on an openstreetmap tile. So having pure helper libraries which are not apps themselves, just code to import can massively speed up new projects.

I see your points, I'm just skeptical that every refactoring someone
would make in a Browser/Node.js environment is a good idea in a
resource constrain

Will come back with examples once I have started building an app. I think some of the stuff is that I am coming from a world of large scale apps, typescript with webpack or similar to tree shake and remove unused stuff, minify if needed, flatten to single file if needed.

Thanks for the long response, its really helpful. Re timers - its not in the documentation, just some of the apps using them. It was one of my less constructive comments as unless the bangle js compiler doesn't support async functions, its an understandable coding mistake, as async stuff is often harder to get head around.

I didn't know the best forum to post this - so feel free move it if a better place.

Short background. I am a full time programmer. For the last 2/3 years I have been leading a team using ReactJs (modern javascript framework) with Typescipt to build large scale multi platform apps.

I have spent the last 4 months as a fulltime parent and have been looking for some projects to do around that. I have worked with dev boards like the esp32 with both Arduino and more recently Micropython for a long time so although I don't do this type of development for a living I am very familiar with it.

I bought the bangle 2 watch a few weeks ago. The Javascript programming framework looked interesting. I liked the idea of open source software I can improve - mostly around improving the existing apps for hiking and navigation.

I have some comments around the dev framework which may well be ignorance, any criticism is meant as constructive rather than an attack on the framework and community. Any help or feedback would be grateful.

One of the starting points is the documentation. I am finding navigating the documentation confusing, often getting circular links from one page to another. Some of the questions below may be answered in the documentation but I haven't been able to find it (it also doesn't help when a small baby keeps interrupting)

1. Its not clear to me which version of Javascript espruino is supporting. es5, es6 .. etc? Or some cut down version supporting some of the functionality of one of these (as with micropython). I would be planning to use typescript and smaller single files of typescript in an offline ide, which could be built down to a single or multiple javascript files, if the compiler is custom javascript the use of typescript is limited.

2. Coding styles. There is a small section on suggested naming conventions, syntax structure etc. Has anyone considered having a defined linting file for people to use? You can even run forced linting when code is submitted to github. With an extreme implementation rejecting files not parsing certain linting rules.

3. Folder structure. Having boilerplate folder structure for new applications is really useful. Especially for beginner programmers. I can even make a cli in javascript to do this if there is demand. Although I am guessing the web ide makes chucking everything in a single file easier.

This questions come from looking at the documentation and existing code library. Having looked at existing navigation apps within the github repo. There is alot of very poorly built code. Long single files of functions (or in some cases not even split into functions). Lack of object orientated code (not sure if classes supported in the compiler). Use of timers instead of async functions. All of which is understandable for any hobby developer and are one of the issues with scripting languages over ones like c# which force better code by design.

The issue for me is that I can't extend any of the existing applications. I would need to rewrite the base code into a structure which would be maintainable and upgradable in the future. Without the use of linting and type safe code (typescript) building any reasonable size application is difficult. If I was rewriting one of these apps the first thing I would do is split the code into much smaller object orientated files. Splitting any generic code related to the hardware to a separate library project.

Was the original intention that espruino dev boards/watches will always just be for simple hobby type projects. Or was there a hope that atleast on the watch side users would build up libraries of really useful everyday apps? If the later is true, nudging people towards object orientated approaches, code split into smaller files, supporting additional layers like typescript becomes hugely beneficial. Third party function libraries you can just import with specific functions around the hardware sensors etc would allow quicker development and code reuse.