warpech

Interesting take on ideas well presented in a blog post, dubbed as "CLUI": https://blog.replit.com/clui

This is a personal site by Peter Cooper of Cooperpress. This is is one of the people whose work I admire.

This site gives me vibes similar to this blog post by Dan Abramov https://overreacted.io/things-i-dont-know-as-of-2018/

Unpopular opinion: you can subscribe to YouTube Premium to stop ads on YT on all your devices

Great list. Another meta-entry to your list:

https://github.com/cjbarber/ToolsOfTheTrade

I agree that for many use cases, IE11 featureset is fine. We jump on the SPA ship too often. I think that static content and server-side rendered apps are often the best option that is for some reason considered out-of-fashion.

However, for those who see a Web browser as an application runtime, IE11 should be out of question. Vue is an application framework, and as such, it should benefit from all the improvements in the Web platform implemented in the modern Web browsers.

You can't have evolution without dropping ties to the past from time to time. That's about time to drop IE11 to take full advantage of modern Web features.

Amazing work with writing the Terminal component by yourself. Very lean and well functional for its purpose.

For those who are interested to see the source: https://github.com/Renovamen/playground-macos/blob/main/src/...

I am counting on a more creative answer than mine, but my answer is to read the specs, not only the digested material on MDN, blogs, Stack Overflow, etc.

Too many devs are intimidated by the Web and Internet standard specifications. I agree that it is impossible to read them cover-to-cover (however, with most RFCs and the REST dissertation, you can and should actually do that). Still, when you need to understand a particular section, usually you will find there many interesting details and all of the advanced concepts derived from first principles.

I mean specifically:

- the Internet Standards (RFCs). Read some of them [1] or browse all of them [2]

- the HTML5 living standard [3]. Actually the previous HTML specifications are also interesting, easier for reading and mostly compatible [9]

- ECMAScript living standard [4] or the latest finalized spec [5]

- CSS specifications [6] (they are modular and build on top of each other)

- the original REST proposal formulated in Roy Fielding's dissertation "Architectural Styles and the Design of Network-based Software Architectures": "Chapter 5: Representational State Transfer (REST)" [7]. It is also reformulated in "Principled Design of the Modern Web Architecture" [8]

---

[1] https://security.stackexchange.com/questions/116893/which-ar...

[2] https://www.rfc-editor.org/retrieve/

[3] https://html.spec.whatwg.org/multipage/

[4] https://tc39.es/ecma262/

[5] https://262.ecma-international.org/11.0/

[6] https://www.w3.org/Style/CSS/read.en.html

[7] https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[8] https://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf

[9] https://www.w3.org/wiki/HTML/Specifications

I can see a lot of interesting new ideas in Synth! "Smart Bookmarks & History" sound great on their own but "Auto-Roam" is what nailed my own itch. Are you still working on it?

This thread badly needs a mention of another great app by the same authors [1].

LICEcap [2] is a great, absurdly minimalist GIF screen capture tool for Windows and macOS

[1] https://www.cockos.com/

[2] https://www.cockos.com/licecap/

There are systems which are simultaneously in-memory and persistent, e.g. Tarantool, Starcounter

Care to provide some working examples? Many that can be found on Google appear to be working prototypes that are not actually usable.

It's beautiful!

Also it shows the power of publishing documentation in an easily-parsable format.

FTFY: Corrected off-by-one error in the AR ammo counter to correctly match actual rounds in small arm.

;)

I don't know why you are down voted, because it's an interesting point.

I often use the term W3c Web Components to differentiate from JavaScript components that use other APIs.

I know that Web Components are a recurring topic in W3C meeting agendas. I am not aware about parallel fast track discussions in WHATWG, but that makes sense.

I think there are already two Webs (simple and complex) and Web Components are actually a good way to create progressively enhanced websites that work well in both.

Github is one of the strong believers in W3C Web Components. Another one is Salesforce: https://lwc.dev/

Still, worth saying that it's given as an exception that proves the rule that snappier UIs lead to more transactions in ecommerce. The exception was that users couldn't believe that live search in different airlines could be as fast as they made it.

I think I saw the same, I believe it was from Kayak. They said that an artificial loading time increased the user's perception that the search engine made an effort to find the best deal.

I just one to write a positive comment to add some balance to the existing ones. I appreciate your effort to make an alternative web browser for power users! I hope this will be a successful long term project.

I don't know SQLite specifically, but I think that it can be implemented in the application logic using the primitives of any RDBMS. This old thread suggests that http://sqlite.1065341.n5.nabble.com/Re-Two-Phase-commit-usin...

Two-phase commit[0] could do the job

[0] https://en.m.wikipedia.org/wiki/Two-phase_commit_protocol

Just saw https://www.youtube.com/watch?v=vn2aJA5ANUc. It looks great! I am excited that Handsontable works for you in this context. Please let me know if you'd need any help with it.

I read it as: Your stack is so complex that:

- you will not have it running 10 years from now

- I am not able to make a snapshot of the content using tools like curl

Great choice, Sindre! I hope this kind of leadership will help the ecosystem to move forward.

It has a passive-aggressive feel similar to LMGTFY.

It would feel less like it, if there were some ready made text one-liners with a compassionate summary and a link to the longer version.

Also, if you want to help - why would you downvote? Just help!

From the OP

> the login page also sources jQuery version 1.8.3 which was released in November 2012

Wow, that's a prime example of "if it works, don't change it"

I wonder if CDPR released the game at that stage because they thought that the window of opportunity on last-gen consoles was closing

It seems that everybody seems to hate this game, or rather unfinishedness of it. Meanwhile, I am playing it since 2 weeks on PS4 (not Pro) and totally enjoying every minute it.

Not to be confused with Turbo by Yandex: https://yandex.com/dev/turbo/index/, which is a competitive take on Google AMP.

I hope this does not sound cynical. When we release a new open source project, we are not sure what the project will turn into. We put it out, hoping to get some reaction from the world. If there is no reaction, we will only invest a bare minimum for our own use. When there is some reaction, the community might find its sweet spot. When there is huge enthusiasm, which is the least likely, we might decide to seek ways to invest more and get our returns.

Keep in mind that for projects like that, even if they are open source, the vast majority of contributions come from the primary investor. And other contributors can always fork.

It is not anything special about open source. For any product, early adopters are almost expected to get hurt or lose interest as the product matures. It's a part of the product's life cycle that's in any startup book. Crossing the chasm is hard not only for the business but also for the original user base. Yet, successful businesses are destined to do it. I am sorry for the ones that become dissappointed, but they too get something out of it along the ride.