Hacker News new | past | comments | ask | show | jobs | submit login

> I realized just how disconnected JavaScript developers—yes, the "big boys" are especially off in CS la-la land—were from web development fundamentals. HTTP distilled down to its absolute essence is brilliant, but for some reason gets absolutely ignored in the JS world.

Can you please elaborate what these areas of disconnect are? I looked at Joystick documentation hoping to find more of your thoughts this topic, but could not.




I've tried writing a response to you a few times but realizing how complex it is—the real answer to your question is worthy of a long blog post.

The core problem is the blurring of the lines between a framework and the underlying technologies of the web (HTML, CSS, and JavaScript). To me, it seemed like a lot of unnecessary complexity was being added just to achieve the common goal of rendering some HTML, styling it with CSS, and making it interactive with JavaScript (what I refer to in conversation as a "need to look smart" or "justify having a CS degree").

For example, introducing a new syntax/language like JSX (and the compiler/interpretation code) when plain HTML is simple and obvious. The drive to make everything happen on the client leading to vendor lock-in by third-party providers to fill the gaps of having a database (e.g., Firebase/Supabase). Making routing seem like some complex thing instead of a URL being typed into a browser, a server mapping it to some HTML, and then returning that HTML.

Where this really became clear to me was in the resulting developer experience. I've been teaching devs 1-on-1 since ~2015 and had a bird's eye view of what it was like using these tools across the spectrum of competency (beginner, intermediate, advanced). The one consistent theme was confusion about how X framework mapped back to HTML in the browser.

That confusion was handled in one of two ways: making messes in the codebase to solve a simple problem (e.g., lord help me with the nested routing in React) or giving up entirely. As an educator, the latter was especially bothersome because the transition from basic web dev to these JS frameworks was so jarring for some, they just didn't want to bother. That shouldn't happen.

---

I'd like to elaborate on these things a bit more. Can you send an email to ryan.glover@cheatcode.co so I can remember to follow up once I've organized the post I've hinted at above?


Every framework has its learning curve, tradeoffs and frustrations. JSX isn’t that far off from html and can be insanely productive for generating reactive UIs compared to the old jquery days. I’m not sure there’s a one true framework that is easy to learn, sticks to idealistic cs principals and is productive.


> I’m not sure there’s a one true framework that is easy to learn, sticks to idealistic cs principals and is productive.

My goal is to make Joystick that. It's less about sticking to hard principles and more about keeping abstractions thin and APIs clear. I don't expect everyone to agree with me, but I'd bet money if you plopped a newer developer in front of a Joystick component vs. a React component they'd pick up the former much faster (my personal standard of whether I'm "getting it right" or not).


> I’m not sure there’s a one true framework that is easy to learn, sticks to idealistic cs principals and is productive.

Svelte, the tutorial is short and runs directly in your browser: https://svelte.dev/tutorial/basics


You say that JSX adds complexity and plain HTMl is simple and obvious, and yet, when I look at joystick, I see a render functions, and non-obvious helpers like `each, when, component`, etc. JSX is really simple to understand for basic use cases and it provides so many benefits: - support for Javascript expressions - transpilation - better error reporting

I'd also argue that JSX is overall a LOT more readable than some of the more advanced examples you provide in the Joystick docs, especially because you don't get syntax highlighting in javascript template literals.

> The one consistent theme was confusion about how X framework mapped back to HTML in the browser.

I'm not saying you're lying, but in the case of JSX, I find this very hard to believe.

I do 100% emphasize with a new developer approaching react who starts with `create-react-app` and has to figure out which routing package to use, etc. But projects like `next.js` reduce the complexity of the mental model significantly IMO (file system routing, sane defaults for compilation, great local dev experience, etc).


Each renders each item in the array you pass, When renders the html you pass when the condition is met, and Component renders another component. Those are all used inside of a plain string, leveraging JavaScript interpolation (core language feature, no hacks). Again, I want you to be able to go from learning pure JavaScript to Joystick. Assuming you learned about stuff like interpolation and template literals, you’d have an existing mental model for understanding what’s happening. Coupled with writing plain HTML, it’s as close to the metal as you can get.

As for Next, it’s certainly a step forward, but the folder-based routing is another abstraction that obscures the concept of a URL and uses hacks (like weird folder names to support params) to get what is a one line string in something like Express (the router in Joystick). Nothing inherently wrong with that, but it breaks affordances around how the web works. Check out the Next boilerplate on Github on the CheatCode account. Working on that furthered my motivation to build Joystick.

As for syntax highlighting, you can get this by prefixing an html`` before the backticks for your string (I need to spend some time automating this so IDE’s respect the HTML in the string w/o a helper).

To be frank, based on your general tone and username, you sound like someone from one of these projects (or your livelihood depends on them in some way) and got your feelings hurt.


readability is subjective, ymmv.

jsx makes my eyes bleed, it's like php4 in js, and it's full of corner cases you could never guess without cheatsheets and round trips to the docs.


>The core problem is the blurring of the lines between a framework and the underlying technologies of the web (HTML, CSS, and JavaScript).

I believe the core problem is that we've switched from a static document model to a dynamic application model, yet kept at the center of our focus the idioms and technologies meant for the former.


For those looking for the elaboration on the above, I've written one here: https://cheatcode.co/meta/the-joystick-story-how-what-and-wh...


> Can you please elaborate what these areas of disconnect are?

I'm not the OP but something I have noticed is the JavaScript wünderkind seem to want to completely reinvent web browsers but in JavaScript. They seem to not actually know HTML, CSS fundamentals, or even HTTP. So you end up with frameworks that reinvent everything a browser already gives you (for free) but entirely inside their JavaScript monstrosities.

I might just be grouchy and uncharitable but it's certainly the feeling I get looking at any of the big JavaScript frameworks. It's infuriating to see frameworks reinvent something like a button with a bunch of anchors, divs, and spans when HTML gives them a perfectly functional button with a bunch of built-in events including touch events.


It’s worse than that, not just web browsers, they’re also forcing these frameworks into desktop apps, mobile and embedded because they refuse to learn any other platform or language.


Bingo.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: