I think it’s time for me to post a small update. I am happy to announce that most of the challenging tasks (backend logic) are finished, and the database is more or less functional. I am now working on the frontend (the part visible to the user), and I am very close to presenting a functional demo for the public.
However, there is both good news and bad news.
Good news:
I am delighted to see that the Ruby website uses SCSS to better manage CSS code. This was one of the surprising things that genuinely made me happy.
Bad news:
I don’t really know how it happened, but the Ruby website does not use SCSS imports in any meaningful way, resulting in a single, massive stylesheet file that is nearly impossible for a mere mortal to comprehend. The modest documentation is also not helpful at all. When I saw that, I experienced a kind of internal stroke because it means that for me to work on the frontend, I will either have to study and remember the SCSS code (which is impossible), or reorganize it, style by style. I am choosing the latter option as it seems to be the only reasonable solution moving forward. I will not accept this kind of code as-is in the OpenStreetMap-NextGen.
Afterward, I will assess whether it’s feasible to drop the jQuery dependency. To my knowledge, modern JavaScript can work very well without it, requiring very little code. It’s simply a relic of the past. Having fewer dependencies means a more standardized approach, making it easier for other contributors to get involved. Once I’m done with both tasks, I will update the roadmap and release a new SONG (State of NG) episode when the demo is ready. This delay is a result of my underestimation of the current state of the JS/CSS (I initially assumed it would be a simple copy+paste task).
Cheers, and until next time!
PS.
For some extra context, I am primarily a backend developer, and I really, really don’t enjoy working on frontend code. That’s why it’s such a big deal for me. I hope you can understand that!
I will seek additional help only after reaching the feature parity point. I don’t want to be bothered with that just yet. I value good-quality developer documentation, which will happen once the base code has been laid out. Everything will come with time (it’s not that far away!).
After reading this dramatic description, I eagerly clicked the link to see what horrors awaited! How massive is it? 40,000 lines? 80,000? My grim fascination was short lived. The link brought me to a well organized source code file with a modest 1300 lines of code.
Of course! Everyone has a different threshold for what they consider readable. What’s more, some people even consider the current OSM Ruby website to be readable. Personally, I found this file quite difficult to work with; the SCSS import feature is there for a reason . If I found issues with it, I’m sure there will be others who do too (not everyone!). The NextGen project aims to provide a robust foundation for future OSM development, and I find it crucial to be nitpicky about such issues. I want future developers to find the project easily accessible and not require them to spend hours studying the code. After all, this is a community project.
It currently is most definitely not a community project since I see that you are writing things like: “I will not accept this kind of code…” - it is a clearly, at present, a “NorthCrab makes all the decisions” project. And my hunch is that it will forever remain that, because the disrespectful way in which you write about the work of others doesn’t lend itself well to community efforts.
Hey! Yes and no. While I am currently the primary developer - yes - and I make decisions about the NextGen code standards, I do so after listening to community feedback. During one of my AMA video meeting sessions and forum discussions, I learned that the original (at the time of the thread posting) code quality and project structure were not good enough. Originally, I wanted to closely resemble the OSM Ruby codebase, which was seen as a negative. I now understand that the NextGen codebase should focus on using a modern style of development, and I fully agree with that.
As I have already mentioned, I will open up development once the NG project stabilizes enough. I would love to prepare some awesome developer documentation and make this project have the best developer experience the world has seen!
Secondly, I don’t know where you got that from, but I have deep respect for the work of others. I understand that the Ruby codebase goes as far back as 2009 (and possibly earlier?), and I understand that over many years, the style of development has changed, and the project itself has grown massively. There’s nothing wrong with it; it’s just how things are. Without the work of the contributors, we wouldn’t be where we are today. I simply pointed out that the SCSS/JS will require additional work, which I hadn’t accounted for, as this code does not match the NextGen standard as-is. This was very important to me because it directly affects the ETA date on the roadmap. Please don’t see it as an attack on anyone!
I hope this clears things up a little bit for you!
You may feel to you like you stated this simple point in neutral terms, but that is not the case. Suggesting that the code is impossible to comprehend, not acceptable, and caused you to have a stroke is unnecessarily disrespectful towards the authors. If you can’t see this, I’d encourage you to reflect on the words you chose and how they come across to others.
I see the issue. When I mentioned it was “impossible to comprehend”, I primarily meant that it would take an unreasonable amount of time for a new contributor to grasp. When a single file requires a day of study, there’s a very high chance that a new contributor will drop out and never contribute anything. When I said it was “not acceptable”, I was referring to the NextGen codebase standards. Originally, I intended to leave the frontend code pretty much as-is, but after seeing the files in question, I realized that more work would be needed, and this would delay the roadmap.
Now, regarding the “stroke” comment, that’s true. I genuinely couldn’t contribute anything to NextGen for about a week. I needed some time to clear my thoughts and prepare a good plan moving forward. In the meantime, I focused on modernizing some of my other open-source projects and took a general coding break. You can see the week break in the commits here. I want to clarify that this has nothing to do with people contributing to the Ruby project. I really appreciate everyone working on FOSS projects! We all work for the greater good . It’s all about the schedule of work and additional coding required. Originally, I intended to finish the migration on December 16th, and any sort of unexpected delay (like this one) really bothers me.
Anyway, it’s been 1.5 days now, and I have about 500 lines left (down from the original 1300). At this point, I cannot provide an exact ETA for when I will finish the SCSS/JS migration. In the bold part, it’s estimated to take about 3-7 more days.
Have you considered refactoring the SCSS file in the scope of the current openstreetmap-website? That way your work on that file would benefit both the current codebase as well as your own, and would bring the benefit of your work to the community much sooner (and with a higher likelihood to be accepted).
Hey! At the moment, I’m fully focused on the NextGen project itself as I want to complete the roadmap within the given deadline. Back-porting any of my contributions (features, optimizations, formatting) is a lower priority, and I haven’t considered it yet. I’ll see what’s next after the NextGen roadmap is complete, as it’s my highest personal priority for December, January, and February. If anyone else wants to back-port the NextGen contributions sooner, the best time for that would be after the developer documentation/experience work is finished (which is planned for after the feature parity migration part; less than a month).
Here’s a quick update on how things are progressing. Overall, it’s going pretty well. I’ve completed the SCSS migration, although there are a few small tasks remaining that require a fully functioning website. The JavaScript migration is ongoing, and I’m happy with the progress. I’ve managed to refactor, simplify, and optimize significant portions of the code. What I am also supper happy about, is the considerable reduction in npm dependencies. This reduction came from rewriting code in a way that uses standard JavaScript functionalities. I have also successfully removed the jQuery dependency.
Starting tomorrow and for about a week, OSM-NG won’t be my primary focus. I’ll be prioritizing activities related to the new year. While I’ll likely still contribute some code, it won’t be anything substantial.
Hello! The code hasn’t been optimized for a new developer’s experience yet. The development will open up once the application is ready to be run on a test server.
Focus on the test server. Make sure sure you have good documentation on how to get everything running. People are going to want to try out it for themselves.
If they like it, they will submit changes. Please don’t reject them just because you think the code is not ready. This will drive away those who want to help you. Instead, show them development guidelines and help critiques to better shape thier contributions. You have to give up some control if you want it to be accepted by the community.
Let me post a small update on how things are progressing.
I am taking my time during the JavaScript migration. While initially I planned just for the simple code refactoring, I decided it’s much more sensible to write the functionalities from scratch, while preserving the same behavior. I am super happy about the current state of the JavaScript code. There are numerous optimization, bug fixes, simplifications, and other improvements (too much to talk about right now). I will describe everything in rich detail on the test server launch - which is my primary focus right now . I can see a light at the end of this tunnel.
Here’s a small sneak peek at one of the cool new features (as a thank you for reading this post):
In OpenStreetMap-NG, image map export (from the share menu) is done client-side instead of the server-side. This has numerous advantages: it allows users to export any base layer and not just mapnik, is much faster as the client browser can reuse tile cache, can be easily extended in the future, eases out OSM server maintenance and reduces cost, and has a new very intuitive user interface.
I’ve been advocating for a similar approach in ohm-website, since a MapLibre GL map is already being rendered on the client side anyways. But if you’re still loading raster tiles, does this rule out support for the SVG and PDF export formats?
Do you really mean mapnik or do you mean Carto? As well as others, which it wouldn’t hurt to list here, as it shows your “context state of mind” as to what you place into your mental picture bucket of “base layers.”
Thank you for that question! I do plan to fallback on server-side render for those 2 formats. However, I would love to explore the idea of dropping off PDF exports completely (so just SVG) - planned discussion on that. PNG/WEBP/JPG exports will work in client-side.
I meant the default OSM layer.
“mapnik” name is used all over the code so I just sticked to it.
By base layers I mean all layers from the sidebar panel:
. If I found issues with it, I’m sure there will be others who do too (not everyone!). The NextGen project aims to provide a robust foundation for future OSM development, and I find it crucial to be nitpicky about such issues. I want future developers to find the project easily accessible and not require them to spend hours studying the code. After all, this is a community project.
