If you think of them as mostly just syntactic sugar for closure state variables wrapped up in the module pattern, it's not so bad. (This is how some of us have been writing D3.js code for years!)
I see lots of responses to this article asking "why client-side navigation?". I can share my own experience with building an app a few months ago, and how/why I switched to a client-side single-page app..
It is a worldwide list of brands that have been seeded with OpenStreetMap data, and which volunteers have linked to Wikidata identifiers. We use this data in OpenStreetMap editors to help people add branded businesses. Pretty cool!
1. We had data in `.json` files (but not too much data) and we wanted to show it to people working on the project so that they could review the brands.
2. I spent a day or two and built a static document generator. It took our data and spit out an `index.html` and few hundred `whatever.html` files. This worked really well. As the article says, "browsers are pretty good at loading pages". A side benefit - Google is really good at indexing content like this.
3. Then users made the obvious request: "I want to filter the data. Let me type a search string and only show matching brands. Or brands that appear in a certain country".
4. OK, SO.. If your data is spread out over a few hundred files, short answer - you can't do this.
5. But the data is _really_ only a few megabytes of `.json`. I spent a few days to learn React and switch to a single-page client side app so that we can filter across all of it. The new version uses hooks to fetch the few `.json` files that it needs, `react-router` to handle navigation between the index and the category pages. It works pretty ok! Most people would stop here.
6. The first version with client-side filtering performed good enough, but not great. The reason was because, as users type these things happen: The filters get applied, the React components get a new list of brands passed in as props, and React re-renders these new lists to the virtual DOM, and eventually, slowly, the real DOM.
7. It's really easy to build React code like this, and many people do. But it is better to avoid DOM changes in the first place. I changed the components so that the lists stay the same, but filtered things just get classed as hidden `display:none` instead of being added and removed from the DOM, and performance is much better now.
> Realistically, we can't pay people full engineering salaries to do random OSS.
Why can't you?
Professors get paid full professor salaries to do "random research".
Doctors get paid full doctor salaries to treat "random illnesses".
I expect if you looked a bit closer, you'll find that "Random OSS" is maintenance that makes the entire ecosystem possible. Would love to hear from some of your engineers what they are doing to earn that $20/hr.
As a professional full-time open source maintainer and developer, initiatives like this bother me a lot.
The work we do is worth much more than $20/hr.
Ideally I'd like to see open source developers in stable, tenured positions that pay fair salaries with benefits. Anything that normalizes the idea that open source should be funded on tips, patreons, or spare time goodwill is embarrassing to all of us. We can do better.
If you value open source, hire people to do it and pay them fairly.
>Crucially, self-driving cars also rely on conventional cameras. So if those lidars are not camera-safe, it won't just create a headache for people snapping pictures with handheld cameras. Lidar sensors could also damage the cameras on other self-driving cars.
Lots of people don't realize that 1 cup milk has 13g sugar from the lactose.
For comparison, a typical sugar packet is 2-4g.
(This is why cereal + milk is probably just about the unhealthiest thing possible to start your day).
It's a good idea to switch from the sugary/milky Starbucks drinks to anything else - like cold brew, or black coffee where you add trace amounts of sugar/cream yourself, if any.
Set your profile picture (Slack/Twitter/GitHub/etc) to something happy. You’ll see it thousands of times a day as background noise, but it will affect both your own mood and how other people treat you.
Hah yeah, it was kind of funny that by the 4th shot, the ER docs and police there knew me as "the rabies guy".
I also was told that the immune globulin is a bit complicated because it needs to be prepared specifically for the person's weight. So unlike off the shelf vaccines, it requires an on duty pharmacist to actually do something before they can give it to you, which I'm sure adds to the cost.
Oh! I got rabies shots in 2014 after being bitten by a dog.
The course of treatment is injections 0day, 3day, 7day, and 14day. I went to the emergency room to get these injections, at the recommendation of my primary doctor.
Unfortunately I don't have the bills anymore, but the total cost was a bit over $20,000, which insurance adjusted down to about $500/visit.
Basically, it would have bankrupted me if I didn't have insurance. Yes, the US healthcare system is really this broken.
OpenStreetMap US | Executive Director | Remote USA only | Full Time
OpenStreetMap US seeks a new, full-time Executive Director to be a part of our continued mission and growth! OpenStreetMap US aims to broaden the reach and diversity of the OpenStreetMap community and increase the use and improve the quality of our map data. As Executive Director, you will work closely with the Board to move these goals forward and provide strategic vision to further the organization’s mission.
The duties of the Executive Director cover a broad scope, encompassing organizational program and strategy, as well as fundraising, finance, and marketing. This role will require a high degree of flexibility and creativity, and a collaborative and inventive orientation. The successful candidate will be mission-driven and passionate about the idea of creating and applying open, accurate geospatial data for the world.
This is a unique leadership position within the open source mapping and open geographic data communities. OpenStreetMap US is one of the largest user communities of the OpenStreetMap project, and as the Executive Director you will have a chance to make a difference at the local, national, and international level. This is a role with ample room for growth and creativity, and the successful candidate will come from a diversity of backgrounds. We encourage you to apply!
> And it has a barrier to entry - you have to be a tiny bit nerdy to confidently make edits.
Serious question - what can we do to lower these barriers to entry? Friendlier community norms? Documentation / tools? Social stuff (groups, meetups, etc?)
I'd love to hear people's experiences on contributing, and your honest feedback. I'm one of the "core" members of OSM (I maintain the iD editor) and we're always looking for ways to improve the new user experience.
> Personally, I think a good intermediate step will be to embed better and more automated review processes.
I agree! For now, most review is done manually by volunteers. We're looking for ways to make this process more efficient.
It runs some checks against every changeset as they occur, and presents a newsfeed-style list for anybody to review. It also has filters, in case you are interested only in certain geographic regions.
Sorry to hear that you had a bad experience.. For what it's worth, it sounds like your edit was fine (what you described is actually the preferred way to map divided roads) and should not have caused any issue.
I'd love for you to give it another chance! A few of us do monitor the changeset discussion feed in Slack, and try to speak up when we see new users being mistreated.
https://www.alltheplaces.xyz/