491–500 of 715 posts
Recommend you try to start with webcomponents + a well thought out design system -> move on from there and you're pretty sure to have a solid base from which you can always add react, lit, vue or whatever else cooks your noodle.
the other way around is near impossible
Earlier quoted context omitted.
Because in a lot of cases, the driver isn’t in the correct place, and so if you have their location you can easily tell them how to get to you. I’ve had multiple deliveries where the Uber Eats app just could not tell the driver the correct location for my address, and I wouldn’t have been able to tell the driver how to get there by just them telling me where they were.
For that, I would propose a feature where I can mark the directions to my home from a well known checkpoint on a map, one time. If the rider deviates in the last mile, they get notification. If they continue to deviate, I get a notification. The solution is not for me not constantly monitor the rider's location.
I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?". I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. A vast majority of the hours I've spent building web sites & applications has been devoted to admini…
I’ve never felt more useless at work than when I was told to integrated with a new React self-service portal. No one actually wanted to build things for it or use it. It was the pet project of a new CIO. I think it fell over under its own weight in under 2 years.
Earlier quoted context omitted.
Can't put those in templates though. It's a serious pain and completely unnecessary.
You absolutely can put properties in templates. Web component authors do this all the time. Here's a lit-html template that sets a property: html` `
Earlier quoted context omitted.
They let you encapsulate the logic pretty much however you want, same as not using web components.
When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.
Edit: I just added a shadow root to a div in your comment, saving its content beforehand, moved its content inside the shadow root, and added a style with * { all: initial } and your comment text got Times New Roman.
Earlier quoted context omitted.
Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React. Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly. There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by…
Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer. Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static. I think what you’re…
The islands/RSC work seems to offer some improvements to this, but most of these websites still include a full copy of React on the page to essentially do what the speculation rules API and a `` element could do just as easily.
Earlier quoted context omitted.
And they're right! IMO Lit is a marvel of engineering. I think the goal they set themselves (make it easier to build an entire app out of web components) is silly, but given that goal, they hit a total homerun. It's fast, the compiler is very optional (not using it just means a bit more boilerplate around attributes etc - it's not like using React without a JSX compiler or something), lit-html is a genius alternative…
> lit-html is a genius alternative to virtual DOMs, etc It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast. Additionally, it's weird to ask…
> Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.
Fair point. I don't personally really care about that either. I guess I just meant to be say that it's not all too custom :-)
I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?". I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. A vast majority of the hours I've spent building web sites & applications has been devoted to admini…
Lets first not forget: 1) people been doing business with these "ugly" green textmode screens, long before web; 2) the web existed in a very reasonable form pre-www as FIDO, GOPHER, and of course IRC & EMAIL. The fact that this all got hyperlinked is a superb. convenient, but also a challenge from tech perspective, and what FAANG did in the 30 years to come (after 1992) led to this horror of entangled and super-compl…
With that title I didn't expect Javascript to be part of the equation. To me "vanilla" is CERN's HTTP+HTML.
The thing that happened is that FAANG redesigned the web for their own needs, then other companies used that to fulfill their own needs too. That's how we ended up with a lot of available content, but also user info mining, browser monopoly, and remote code execution (JS) as a daily normalization of deviance.
There are some secessionists - Gopher is still alive, Gemini - but alternatives have a hard time to compete with the content companies can provide apparently for free. Most of the content we want costs time and/or money. Content creators can be fine with contributing from their own pocket, but this is not really sustainable. User sponsorship (donations via Paypal, Patreon, Kofi, ...) don't work well either.
Also, since the supporters of the alternatives are generally supporters of freedom (who isn't? Well, people don't reject freedom, they are "just" making compromises), they have to deal with illegal content and other forms of abuse.
So there are 3 problems an alternative web must solve: protocols, moderation and repayment.
I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…