Javascript Support

[Nefcanto]

Which component is affected?

Qwik Runtime

Describe the bug

I'm trying to create the blog page using Qwik at example.local/blog but I see this error:

[vite] Internal server error: Cannot read properties of undefined (reading 'endsWith')

I know it says it's a vite error, but I thought maybe it's also related to Qwik. I'll send it to the Vite team too.

The problem is that it does not give us any more information whatsoever. Just one vague line. We're stuck at debugging it.

Reproduction

https://github.com/Nefcanto/ViteQwikEndsWith

Steps to reproduce

• Clone
• npm install
• npm run dev
• Go to locahost:port/blog, you should see the error

System Info

System:
    OS: Linux 5.15 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
    CPU: (4) x64 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
    Memory: 8.90 GB / 15.52 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 18.14.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm
  npmPackages:
    @builder.io/partytown: ^0.7.5 => 0.7.5 
    @builder.io/qwik: ^0.17.4 => 0.17.5 
    @builder.io/qwik-city: ^0.1.0-beta13 => 0.1.0 
    @builder.io/qwik-react: ^0.2.1 => 0.2.1 
    vite: ^4.1.1 => 4.1.1

Additional Information

No response

[manucorporat]

I see that the project is using .js instead of typescript, also i see:

const Blog = component$(async () => {

this would error in typescript because returning a promise at that level is not allowed, not sure what the problem is, but i would recommend to use typescript. We dont support .js only at the moment.

[Nefcanto]

@manucorporat with your permission, I want to give some advice. I know it would be harsh, but I do it with good intent, to help Qwik truly shine.

Please do not become overly opinionated. That was what killed Angular. It started extremely well at first, but since it had "opinions" about almost everything, it could not fit into many teams around the world and when React became easier to work with, teams chose it over Angular.

A lot of teams have internal structures/architectures and a new tech needs to have some level of flexibility to be able to fit into their tech stack. Otherwise, they have to choose alternative options.

Vue became popular, why? Because you could simply drop view in your code from a CDN (the highest level of flexibility) and only turn one small part of your application into a Vue app. That's the key to their success.

React became popular, why? Because react does not care about your routing, your API library, your forms, and a lot of other things. It could easily fit itself into existing complex and sophisticated tech stacks.

JSX became popular, why? Because it was way more flexible to (quote) put HTML into JavaScript than putting JavaScript into HTML.

So please do not ask teams interested in Qwik to use TypeScript. I personally hate TypeScript. But putting personal preferences aside, we can't use TypeScript. It would be extremely costly for us to switch to TypeScript because we have an internal meta-meta-framework that's built on any framework that we use. Linux, Docker, MariaDB, React, Next, Qwik doesn't matter. We have a layer of an internal framework for everything. The reason is that we create hundreds of web applications per year for our customers and we need to centralize a lot of things. And we already have a meta-meta-framework built using JS and we can't switch to TypeScript.

These are some examples of websites we build:

axhome.ir
pelakino.com
ghazachi.com
amlakmosallas.com
geokhanjani.com
blog.paydarsamane.com

Which we need to be able to create using Qwik.

They are all built using Next.js. But we truly intend to switch entirely to Qwik. We know how valuable Qwik's philosophy of O(1) is and we know how much it's beneficial for the future of the web. We know it means direct savings in SEO and marketing costs when it comes to a website's performance because we are an SEO and Marketing company too. Thus we are ready to take the cost of changing our entire codebase (even old projects) from Next to Qwik.

But if you insist on TypeScript, then we would simply drop Qwik and stick to Next. That's because as much as we love Qwik, we do believe (our entire team) that TypeScript is garbage.

So please don't force teams for TypeScript. That's key to dominating the market. Otherwise, you will become the opinionated Angular and some other framework would steal your idea and would become popular.

Thank you for hearing this, and though my words were bitter, my heart is truly with you and I love to see your success.

[Nefcanto]

Regarding the async component, what is your recommended way for us to fetch a component dynamically? We use import() function and it's async in nature, thus we have to await it, and if so, we need to decorate our components with async.

Next.js supports this in version 13, which shows the global demand to be able to support async/await inside components.

This is our code in Next.js 13:

import {
    Layout,
    useBlog,
} from 'Blog'

const Blog = async () => {

    let RunnableLayout = null
    try {
        const { Layout: TempLayout } = await import('BlogParts').catch(reason => console.error(reason)) || {}
        RunnableLayout = TempLayout
    } catch (error) {
        console.error(error)
    }

    const data = await useBlog()
    const {
        categories,
        latest,
        mostViewed,
        popular,
        posts,
        seo,
        tags,
    } = data || {}

    return RunnableLayout
        ?
        <RunnableLayout {...data} />
        :
        <Layout {...data} />
}

export default Blog

And it works. Let me explain the requirement:

Let's say we want to build 100 websites. Almost 90% of them would have blogs. So, do we create 90 blogs from scratch (including routing, commenting, information architecture, etc.) or do we reuse some of the stuff and centralize them into a module? I think it's clear that the correct approach is the second answer.

So, we create a centralized Blog and we use convention over configuration to assume some things are in some places.

If a developer has not implemented a blog for a new website, we reuse our base blog with routing and a default UI.

But if they only want to change the look & feel of a blog (the UI), then we still prefer to use routing and logic related to how to call API and SEO and social sharing and many other things.

And if we intend to create an entirely new blog, then we still support him.

So, this enables us to compete and deliver complex websites at lower costs. That's the requirement that forces us to use await import() inside a centralized blog page to see if a custom blog UI is provided or not.

[shairez]

@Nefcanto we appreciate the care about Qwik and trying to make sure Qwik gets adopted better.

The team has a huge task which is to stay focused on producing the best developer experience possible before 1.0 ships
TypeScript has proven itself to improve the ability to refactor large scale code bases, to catch errors automatically and to document the code intent better, plus it's becoming a more standard way to write large web applications.

BTW both React and Vue started in 2013, when TS was still young and non ES standard compatible (for example, the modules system was way different)

Adding another layer of maintenance is adding much more work to an already huge and complex project scope (which usually the cause that prevent projects from gaining more traction, because they don't ship fast enough).

It's not easy to introduce new capabilites to the web development open source world, so decisions are needed to be made and it's hard to support ALL of the possible use cases and individual project architectures right at the beginning.

Plus, it's totally fine to not like a particular solution or have a personal constraint in your project that prevents you from using it, but one of our community values is to respect other technologies, that's why I'd like to ask to please avoid referring publicly (on Github, Discord and other Qwik Community channels) to other technologies which people worked very hard to create and to maintain as "garbage". Thanks for the understanding 🙏

About async inside the component$ - yes it was this way in the past, but it created other issues (basically related to preserving the execution context if I recall correctly) so there was a need to change this.

Instead you can use async inside of the life cycle hooks like useTask$ etc

[Nefcanto]

@shairez, thank you for reminding me of the community values. I understand and I won't be using it anymore. My apologies. My reaction was based on your team insisting (somehow forcing) the community to use it. I also understand that it's not possible to support every need.

However, since our company is investing heavily in Qwik (and I can show you the amount of effort we put into making it our mainstream infrastructure) I would love to ask about your future decisions.

If it's not your team's decision to support JS in the future, then with heavy hearts we should abandon it. It's OK that you decide whatever you want, it's your project and you're the owner. But it's also the community's right to know the roadmap to be able to plan.

Regarding the async inside component$, if I understand correctly, useTask$ won't hold rendering if it's async. This means that our blog (or other parts of our websites) would possibly flash the default layout and then show the overridden layout.

Please correct me if I'm wrong. We need to be able to decide which layout to show before the rendering happens, in a synchronous fashion. Can we achieve it in Qwik?

[shairez]

Thanks for the understanding @Nefcanto , we appreciate it!

I totally understand the need to know about future plans and if JS is going to be supported. we'll discuss this and get back with an answer

About useTask$ - it first starts on the server and always run before render starts, so there shouldn't be a flicker IMO

[Nefcanto]

@shairez, awesome, I will try it. For now, we should wait until the next release, because our page is not loading and even after removing the async we still see that endsWith error, we can't test it.

[manucorporat]

@Nefcanto appreciate the effort in writing all your thoughts, i read them, but going to reread them. Just to give some context about my concerns is that, using Qwik without JS is like writing assembly.

I cant care less about if developers type their own functions, but regardless typescript or not, there is a contract of the things that are allowed, and we are not defensive about it because we rely on Typescript ensuring at build time, that you are passing the right types, in the right places.

I feel we cant give an official JS starter because I don't want t make it to easy for developers to choose a highly unrecommended solution.

I am gonna keep this issue open, even though the issue was originally fixed to keep the conversation open for TS / JS

[manucorporat]

How could we allow .jsx but running typescript to help you prevent issues, how does it sound?

[manucorporat]

        const { Layout: TempLayout } = await import('BlogParts').catch(reason => console.error(reason)) || {}

no need, all components are lazy loaded already, Qwik is doing this under the hood, even better! just import normally! dont lazy load the components manually

[Nefcanto]

@manucorporat first of all, thank you for allowing this conversation about JS and TS. I do really appreciate it.

The problem in our case is not TS, it's bad messaging. It's fair that we should not breach the code contract to use a Framework. Yet it's also fair to get descriptive and right messages if one breaches those contracts. I'll present some examples:

In Adminer, which is a web UI to manage MariaDB, I can write this code:

select *
from from Blog.Posts

Please note that there is no tooling available for me at all there. And I accept it. I choose it. I'm OK with not having the tooling to help me write robust code. But when I write the wrong code, this is what I get:

Error in query (1064): Syntax error near 'from Blog.Posts' at line 2

It has enough information to help me keep troubleshooting on my side. It gives me the line number in reference to my code.

Another example is bash. Let's say I write this code:

export Name=John
echo $Name
[[ $Name == "John" && another_command

I get this error:

bash: unexpected token `newline', conditional binary operator expected

bash: syntax error near `another_command'

Again, it gives me some hints on the vicinity of the problem so that I can debug on my own.

And we don't have tooling in bash too.

So I argue that it's not about using or not using TS or tooling in the first place. It's about correct and descriptive messages.

[Nefcanto]

Considering the TypeScript vs JavaScript. I know it might not be possible for you to support JS soon, as there is a lot of work. But this is my argument. Consider this Services component:

import { component$ } from '@builder.io/qwik'
import {
    Supertitle,
    Title,
} from 'Shared'

const Services = component$(({
    items,
    supertitle,
    title,
}) => {

    return <div class="services flex flex-col items-center mt-24 max-w-screen-xl xl:mx-auto">
        <Supertitle>{supertitle}</Supertitle>
        <Title>{title}</Title>
        <div class=" grid md:grid-cols-2 lg:grid-cols-3 gap-3 md:gap-8 mx-4 sm:mx-16 md:mx-8 mt-10 lg:mx-10 xl:mx-20 ">
            {
                items?.map(item => <div
                    key={item.id}
                    class="service shadow-lg shadow-slate-300 p-8 rounded-md group hover:-translate-y-2 transition-all duration-500 "
                >
                    <div
                        class="text-icon w-[55px] aspect-square group-hover:-scale-x-100 transition-all duration-500 "
                        dangerouslySetInnerHTML={item.svg}
                    />
                    <h3 class="mt-8 font-dosis font-bold mb-6 text-xl text-slate-700 ">{item.title}</h3>
                    <p class="font-catamaran text-[15px] text-slate-500 font-medium leading-7 ">{item.description}</p>
                    <a
                        href={item.link}
                        class="text-icon underline mt-6 block font-dosis font-bold "
                    >
                        Read more
                    </a>
                </div>)
            }
        </div>
    </div>

})

export default Services

It's real code, from a real project of ours. Why should I use TypeScript here? What benefits TypeScript can add to this code? One might argue that we can create a contract for props (a type definition). But I argue that it's complicating things without making benefits.

The front-end developer is the one who creates this schema in our headless CMS. He creates the schema, and he consumes the schema + data. This process is completely dynamic. He creates the schema (dynamic), then he uses our base functions (usePageSections) to get data (dynamic), and then he destructures that data (still dynamic because he knows what is the name of the section) and he passes that data to his component (still dynamic) and there is not a single third person here to get involved to justify creating type definitions:

const data = usePageSections('home')
const { hero, services, testimonials } = data
return <>
    <Hero {...hero} />
    <Services {...services} />
    <Testimonials {...testimonials} />
</>

Code is clean, code is readable, maintainable, minimal, DRY, etc. Why should I complicate it with TypeScript?

Even I argue that we can get rid of a lot of boilerplate code here. That's what Astro has done. And that's why you have created the concept of lite components in the first place. To make things easier and more readable with less boilerplate and complexity.

[Nefcanto]

How could we allow .jsx but run typescript to help you prevent issues, how does it sound?

That's what you have already done. I gave access to you to one of our Projects. Please see this directory. All of our files are .jsx files.

The problem is not the file extensions here. The problem is the messaging. We run Qwik, and we go to /blog and we see one line of error with no extra information and we have no way to find out what's wrong.

Even if you keep answering the issues, we're good to go.

[Nefcanto]

        const { Layout: TempLayout } = await import('BlogParts').catch(reason => console.error(reason)) || {}

no need, all components are lazy loaded already, Qwik is doing this under the hood, even better! just import normally! dont lazy load the components manually

@manucorporat the point is, the base does not know if that file is already there is not. Thus we can't use static importing. Because in that case, our code won't compile at all (I guess, or does it?).

[jj-owens]

I feel we cant give an official JS starter because I don't want t make it to easy for developers to choose a highly unrecommended solution.

In my humble opinion, flexibility is better than limiting usability, despite the risks. We can admit that a large number of applications are built against their frameworks 'best practices', but, the responsibility of following best practices and avoiding reliability hurdles should still be entrusted to technical leadership and the shareholders- not the frameworks. There are great reasons to use TS. There are great reasons to use JS.

I love qwik either way, but look forward to expanded possibilities if the qwik team considers a non-TS variant in the future!

[gioboa]

Hey @Nefcanto , thanks for opening this issue and thanks for the great discussion.
I see that Qwik already implemented a .jsx support since this was opened
So I'm closing this issue for now, feel free to re-open it if it's still an issue for you.