341–350 of 357 posts
If we’re going back to the 90’s let this be your reminder we still don’t have something for web dev as easy to use as VB6.
Anvil has basically created VB6 for the web but uses Python for the code-behind-the-forms. It can't do everything, but on the surface looks like a pretty valiant effort: https://anvil.works/
They need to bring back Gopher. It has a good chance to become very hipster today.
I can't wait for server-side rendering to take its place in the sun again. There are many use cases for which a client-side framework like React is eesential. But I feel the vast majority of use cases on the web would be better off with server-side rendering. And... There are issues of ethics here. You are kidding yourself to an extent when you say that you are building a "client-side web app." It is essentially an a…
The less stuff on the server the better imo. Whenever I can get away with it I use a static site generator or I use vuejs with a json file containing all the data for the site. Being able to just drop a static set of files in to a webserver without any risk of security issues in my code is great. I also hate the tools for backend rendering since if you need any kind of interactivity it becomes so much easier if you h…
What security risks are removed by using a client side app instead of a server side one?
Earlier quoted context omitted.
OK, I'd never heard of this before and now I'm questioning why we have all these JS templating frameworks like Mustache, Pug[1], and the rest. [1] I actually use this one and it's just fine - great, in fact - but seeing M4 does make me feel like a lot of people may have spent a lot of time reinventing a wheel.
I actually looked into some of these frameworks (in particular mustache but also a few others) before deciding to use m4. They were all either too complex or too limited (sometimes both!) for my use case. M4 is old and clunky but it gets the job done without having to install half a trillion Node.js dependencies. I also know that my script will still work just fine 5 years from now (or even 50 years in all likelihood…
I'm not doing anything too clever with Pug, but there are certainly a bunch of things that it makes quite easy that would otherwise be awkward or complex.
Lots of things work really nicely as well: includes, sections, configuration, and it certainly cuts down on typing. I'm absolutely not contemplating a switch from Pug to M4.
I just find it interesting that there's this thing that's been hanging around for decades that would do at least a partial job and is still decent for simpler use cases.
Earlier quoted context omitted.
>monetized blogs I believe that we have the 'web' today because big decisions were made about how little control the end-user (i.e., consumer) should have over the content made by producers, and that the #1 priority for all technology involved in the web has been to separate producer from consumer as stringently as possible . If we had the ability to safely and easily share a file that we create on our own local comp…
The operating system isn't needed for that at all and blaming the vendors is fundamentally misplaced. That directly sending to other computers via direct IP connections is technically possible if you don't operate any firewalls or similiar to block it. And of course non-fixed and shared IP addresses would complicate the system. You would find out quickly why you don't actually want that when your own "unisystem" desi…
And none of the issues you state as being the reason why we can't have nice things, are actually valid reasons. OS Vendors could solve the problem of serving content from ones own local PC's quite effectively - the issue is not the technology, but rather the ethics of the industry, which prefers to have massive fields of consumers to farm from..
Earlier quoted context omitted.
OK, I'd never heard of this before and now I'm questioning why we have all these JS templating frameworks like Mustache, Pug[1], and the rest. [1] I actually use this one and it's just fine - great, in fact - but seeing M4 does make me feel like a lot of people may have spent a lot of time reinventing a wheel.
I actually looked into some of these frameworks (in particular mustache but also a few others) before deciding to use m4. They were all either too complex or too limited (sometimes both!) for my use case. M4 is old and clunky but it gets the job done without having to install half a trillion Node.js dependencies. I also know that my script will still work just fine 5 years from now (or even 50 years in all likelihood…
Earlier quoted context omitted.
Part of me wonders whether this is technically possible. I’m sure it’s an answerable question.
There would be at least two ways to do it, neither of which are likely realistic to something google scale. One would be to cache results, so that any search searched before could be retrieved. This is limited in that you cant make new searches on old data, and possibly stores private information that shouldnt be accessible to others. The other way would be to have the index and algorithm versioned, where you can tar…
I am sure it’s technically possible going forward, but it would be interesting if such capabilities could be enabled for historical versions of the index and algorithm. Combined with anonymized historical zeitgeist data, some interesting digital archaeology could be attempted.
All the more reason to run your own crawler! What’s the state of the art for this area right now in self hosted solutions? Can you version your index and algorithm like we’re discussing and do these kinds of search-data time-traveling?
I'm glad this is the case. I've been a Rails developer for close to 10 years now, but 3 or 4 years back I got sucked into the React world. I bought right in and my company quickly adopted the "React on Rails" pattern. Looking back, it was one of the worst professional decisions I've made in my career. Now we're back to server side rendering and StimulusJS on the front-end when needed. Productivity is way up, and deve…
React + React DOM is something like 35kb gzipped. That’s not nothing (don’t forget caching) and pushing the initial render to the client (though not strictly necessary) does incur a bit of a penalty, but I think the benefits outweigh the drawbacks in many more use cases than people give credit.
The real problem is two-fold: The first, as I stated above, is wrapping the entire application in a client-side implementation. As many people are pointing out this is often unnecessary. You don’t need to go full “SPA” in order to benefit from the vdom.
The second (related) reason is when developers just start adding 3rd party dependencies without considering their impact (or if they are necessary). React is a library, and for the features you get it’s really not that big. If that’s all you are using to add that extra sparkle to some of your pages I firmly believe you are getting the absolute most “bang for your buck”.
Earlier quoted context omitted.
So we have hand-curated directories, and we have social networks. Put them together and you could have a scalable, crawlable, searchable, customizable and non-gamable decentralized indexing system. Just don't know why nobody has come with this yet. Maybe lack of (monetary) incentives? Maybe something for IETF or WWWC to initiate?
Social networks are becoming walled garden so it's kind of tough to crawl them. I mean look at Facebook and Instagram, the biggest social networks. They have robots.txt configured to disallow any crawlers. Facebook also used have RSS feed for public pages and posts. Now they've not only removed that feature but also have heavy restrictions for third apps.
Services connected to the Fediverse, an alternative framework that focusses on connectivity, is slowing growing. It's only a matter of time before they are more successful than the walled gardens.