5 ms·

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorl

What's incredibly frustrating about the knocks on JavaScript is that it's not a shortcoming of the language that creates the problems hinted here, but the poorly-considered engineering choices of the popular frameworks. After building my own framework [1] last year, 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. When you couple that with websockets for incremental updates (similar to what Chris McCord is doing in Phoenix), it's insanely powerful. It can be reasonably lightweight, too, if you're only shipping the JS you need to render the page. That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams. [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick

skydhash 5y ago
Most languages are quite tough to get into. And they require some real learning if you want to do anything trivial. JS is easy to get started (only the browser you already have) and you can do quite a lot without understanding anything about computer science. But it catches to you anyway. I've seen on Twitter someone repelled by the MDN documentation, describing it as not intuitive. I realized that the documentation assumes you're familiar with the basic tenets of programming (data types and structures, function signatures, ...). Which bootcamps often conveniently ignore.
- the_sleaze9 5y ago
  What do bootcamps have to do with anything?
  - bryanrasmussen 5y ago
    the parent seems to imply that having learned to program from a bootcamp you will be unfamiliar with the basic tenets of programming and as such more likely to find MDN documentation unintuitive.
- mostertoaster 5y ago
  That seems crazy. I feel like MDN documentation is done so well. It balances well between giving good examples, and yet still remaining exhaustive in what it describes. Most extensive documentation ends up being less than useful and I have to fall back to just search results.
  - hbn 5y ago
    I'm legitimately curious what that person expects out of documentation. MDN has basically everything you could want. Simple explanation, examples in an an editor that can be played with and executed, argument names and explanations, browser compatibility, etc etc etc Compared to the amount of languages where their documentation is a table auto-generated from code, it's everything I could dream of!
    - Shared404 5y ago
      > I'm legitimately curious what that person expects out of documentation. MDN has basically everything you could want. w3schools style "Let me walk you through every step of the process" probably. It has it's place, I know I've found it useful in the past, but definitely not a place you want to stay in very long.
      - hbn 5y ago
        Maybe, but I think MDN would be even more helpful for beginners. Compare the documentation for JavaScript's Math.pow() on each: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/pow https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://www.w3schools.com/jsref/jsref_pow.asp https://www.w3schools.com/jsref/jsref_pow.asp W3 doesn't have much in terms of English explanation, has less examples, and their playground forwards you to another page as opposed to MDN where it's embedded.
    - anitil 5y ago
      MDN documentation and Sqlite documentation stand out to me as some of the best around. The Cloudflare how-tos would be up there, if you stretch the definition of documentation
- Heyso 5y ago
  Well, that is my experience too. My background is game programming school, after first learbing flash, second trimester was about making a game using html/css/js (no pixijs or phaser here). I did find MDN hard to read and preferred W3School. Today however I tend to prefer MDN. MDN is richer, more exact, more complete. But being minimal is better when you already unfamiliar with basics. TLDR : MDN pair well with W3School, imo both are fine as they are.
- mythrwy 5y ago
  JavaScript used to be easy to get into (and I suppose technically still is) but the old days of open a console and type in some code or put a src file at the top of the HTML page seem to be gone for most practical and production purposes. Now it's typescript and webpack and a 200 hour course to get started with React. And big teams tripping over each other making components. The funny thing is, I don't know that the resulting product is really much better.
  - rglover 5y ago
    Yes. What you describe is where I started out and I watched it devolve over the last 15 or so years (why I decided to take a swing at building Joystick—it was getting too ridiculous to keep entertaining). I think so many started out in the chaos that they don’t know what the “before time” was like and don’t have perspective on how complex it’s gotten (it’s just normal to them).
pphysch 5y ago
> Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams. Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than the team with an architecturally simple frontend, and the framework flywheel gains momentum.
- LAC-Tech 5y ago
  > Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than the team with an architecturally simple frontend, and the framework flywheel gains momentum. And it will stay working as long as you never need to update any of the packages. And then the rapidly changing, highly co-dependent nature of the FE npm ecosystem will bite you in the ass unless you were really careful with your choices - which you weren't because giant megacorps said it was 'best practice'.
  - mickael-kerjean 5y ago
    In less than 10 years, being able to recompile a modern projects will be a new kind of jobs, going around legacy version of webpack with legacy version of babel that support some syntax that would have never been made a standard with a spaghetti of deprecated library like axios who only became popular because their users was too lazy to look at the standard. That will all become very interesting if we start to find some XSS issues in today's major frontend framework
mavelikara 5y ago
> 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.
- rglover 5y ago
  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?
  - throwthere 5y ago
Philip-J-Fry 5y ago
How does your framework handle re-rendering large components? E.g. a table with 1000 rows. I can't see any obvious mention of virtual DOMs so I assume you're not using them. You might say virtual DOMs are exactly what you're talking about when you talk about the design choices of popular frameworks. It fundamentally comes down to the idea of writing functional components. I declare exactly what I want my UI to look like as if render() is called every frame. But I don't care _how_ it gets there. The complexity comes from taking this declarative UI and making it performant. I don't doubt that 90% of web pages could get away with not using React or Vue or Angular. But as someone who loathes writing complex applications with pure HTML and JavaScript, they do serve a purpose. I've written web apps that are basically just one large render() function with pure JS/HTML and it gets the job done. But at some point you do need to optimise and then it all falls apart.
- josephg 5y ago
  Virtual doms are a cute idea, but virtual dom diffing will always leave a lot of performance on the table. It’s complex, slow, and entirely unnecessary - especially now we have frameworks like svelte. It can still work well enough when developers don’t go crazy with divs, and when they use shouldComponentUpdate. But nobody uses that stuff; and modern pages are bloated like crazy. For my money I think the problem is cultural. Theres a community and culture around frontend engineering now which seems to entirely disregard performance to the throne of closing tickets as fast as possible. Lots of frontend devs I meet at conferences and meet ups have no idea how the browser works, and no real desire to learn. The result is disasters like the new reddit homepage - which needs more horsepower to render smoothly than AAA video games did a few years ago. The GP is right. There’s an insane amount of performance being left on the table. I don’t think it’s a technical problem. It’s a cultural problem.
  - unleashit 5y ago
    I love how the new Reddit gets frequently used as a straw man in arguments of front end developers are bad, the state of front end is a mess, etc. If you care to look at the actual reasons that Reddit and so many modern websites really are terrible, you'll see that it comes from the top and in many cases is on purpose. Reddit (and many others) don't want you to use their website. Especially on a mobile browser. They want you using their app where they have access to more of your data and generally keep you longer. And also where the initial payload of advertising and analytics cruft feels faster to you because you probably are more inclined to be patient with the mobile install/update lifecycle than you'd be with a browser. The GUI changes too were much more likely to come from product management than your lowly front end bootcamp graduate.
bsder 5y ago
> That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. I think you are probably ignoring the fact that we have basically converged back to a web monoculture again. A lot of the current frameworks were born out of "Chrome is shitty this way. Firefox is shitty that way. Internet Explorer is shitty this other way. This framework elides over all that."
- rglover 5y ago
  Not at all. I cut my teeth debugging CSS in IE6 (front-end Vietnam). I’m an old timer. And based on what I’ve learned, what I’ve done in Joystick could have been done in some capacity pre-ES6 and easily in 2014-2015 when most of these frameworks were born.

skydhash 5y ago

Most languages are quite tough to get into. And they require some real learning if you want to do anything trivial. JS is easy to get started (only the browser you already have) and you can do quite a lot without understanding anything about computer science. But it catches to you anyway. I've seen on Twitter someone repelled by the MDN documentation, describing it as not intuitive. I realized that the documentation assumes you're familiar with the basic tenets of programming (data types and structures, function signatures, ...). Which bootcamps often conveniently ignore.

the_sleaze9 5y ago
What do bootcamps have to do with anything?
- bryanrasmussen 5y ago
  the parent seems to imply that having learned to program from a bootcamp you will be unfamiliar with the basic tenets of programming and as such more likely to find MDN documentation unintuitive.
mostertoaster 5y ago
That seems crazy. I feel like MDN documentation is done so well. It balances well between giving good examples, and yet still remaining exhaustive in what it describes. Most extensive documentation ends up being less than useful and I have to fall back to just search results.
- hbn 5y ago
  I'm legitimately curious what that person expects out of documentation. MDN has basically everything you could want. Simple explanation, examples in an an editor that can be played with and executed, argument names and explanations, browser compatibility, etc etc etc Compared to the amount of languages where their documentation is a table auto-generated from code, it's everything I could dream of!
  - Shared404 5y ago
    > I'm legitimately curious what that person expects out of documentation. MDN has basically everything you could want. w3schools style "Let me walk you through every step of the process" probably. It has it's place, I know I've found it useful in the past, but definitely not a place you want to stay in very long.
    - hbn 5y ago
      Maybe, but I think MDN would be even more helpful for beginners. Compare the documentation for JavaScript's Math.pow() on each: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/pow https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://www.w3schools.com/jsref/jsref_pow.asp https://www.w3schools.com/jsref/jsref_pow.asp W3 doesn't have much in terms of English explanation, has less examples, and their playground forwards you to another page as opposed to MDN where it's embedded.
  - anitil 5y ago
    MDN documentation and Sqlite documentation stand out to me as some of the best around. The Cloudflare how-tos would be up there, if you stretch the definition of documentation
Heyso 5y ago
Well, that is my experience too. My background is game programming school, after first learbing flash, second trimester was about making a game using html/css/js (no pixijs or phaser here). I did find MDN hard to read and preferred W3School. Today however I tend to prefer MDN. MDN is richer, more exact, more complete. But being minimal is better when you already unfamiliar with basics. TLDR : MDN pair well with W3School, imo both are fine as they are.
mythrwy 5y ago
JavaScript used to be easy to get into (and I suppose technically still is) but the old days of open a console and type in some code or put a src file at the top of the HTML page seem to be gone for most practical and production purposes. Now it's typescript and webpack and a 200 hour course to get started with React. And big teams tripping over each other making components. The funny thing is, I don't know that the resulting product is really much better.
- rglover 5y ago
  Yes. What you describe is where I started out and I watched it devolve over the last 15 or so years (why I decided to take a swing at building Joystick—it was getting too ridiculous to keep entertaining). I think so many started out in the chaos that they don’t know what the “before time” was like and don’t have perspective on how complex it’s gotten (it’s just normal to them).

pphysch 5y ago

> Though, not surprising, when you realize a lot of the momentum in JavaScript the last decade or so was perpetuated by venture capital (and the inevitable fast and cheap nature of that world) being pumped into inexperienced teams. Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than the team with an architecturally simple frontend, and the framework flywheel gains momentum.

LAC-Tech 5y ago
> Yep. Frontend frameworks get you a slick looking responsive GUI with not much effort (you are outsourcing most of the design work). This wows the average VC. The VC funds you rather than the team with an architecturally simple frontend, and the framework flywheel gains momentum. And it will stay working as long as you never need to update any of the packages. And then the rapidly changing, highly co-dependent nature of the FE npm ecosystem will bite you in the ass unless you were really careful with your choices - which you weren't because giant megacorps said it was 'best practice'.
- mickael-kerjean 5y ago
  In less than 10 years, being able to recompile a modern projects will be a new kind of jobs, going around legacy version of webpack with legacy version of babel that support some syntax that would have never been made a standard with a spaghetti of deprecated library like axios who only became popular because their users was too lazy to look at the standard. That will all become very interesting if we start to find some XSS issues in today's major frontend framework

mavelikara 5y ago

> 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.

rglover 5y ago
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?
- throwthere 5y ago

Philip-J-Fry 5y ago

How does your framework handle re-rendering large components? E.g. a table with 1000 rows. I can't see any obvious mention of virtual DOMs so I assume you're not using them. You might say virtual DOMs are exactly what you're talking about when you talk about the design choices of popular frameworks. It fundamentally comes down to the idea of writing functional components. I declare exactly what I want my UI to look like as if render() is called every frame. But I don't care _how_ it gets there. The complexity comes from taking this declarative UI and making it performant. I don't doubt that 90% of web pages could get away with not using React or Vue or Angular. But as someone who loathes writing complex applications with pure HTML and JavaScript, they do serve a purpose. I've written web apps that are basically just one large render() function with pure JS/HTML and it gets the job done. But at some point you do need to optimise and then it all falls apart.

josephg 5y ago
Virtual doms are a cute idea, but virtual dom diffing will always leave a lot of performance on the table. It’s complex, slow, and entirely unnecessary - especially now we have frameworks like svelte. It can still work well enough when developers don’t go crazy with divs, and when they use shouldComponentUpdate. But nobody uses that stuff; and modern pages are bloated like crazy. For my money I think the problem is cultural. Theres a community and culture around frontend engineering now which seems to entirely disregard performance to the throne of closing tickets as fast as possible. Lots of frontend devs I meet at conferences and meet ups have no idea how the browser works, and no real desire to learn. The result is disasters like the new reddit homepage - which needs more horsepower to render smoothly than AAA video games did a few years ago. The GP is right. There’s an insane amount of performance being left on the table. I don’t think it’s a technical problem. It’s a cultural problem.
- unleashit 5y ago
  I love how the new Reddit gets frequently used as a straw man in arguments of front end developers are bad, the state of front end is a mess, etc. If you care to look at the actual reasons that Reddit and so many modern websites really are terrible, you'll see that it comes from the top and in many cases is on purpose. Reddit (and many others) don't want you to use their website. Especially on a mobile browser. They want you using their app where they have access to more of your data and generally keep you longer. And also where the initial payload of advertising and analytics cruft feels faster to you because you probably are more inclined to be patient with the mobile install/update lifecycle than you'd be with a browser. The GUI changes too were much more likely to come from product management than your lowly front end bootcamp graduate.

bsder 5y ago

> That rendering some HTML, CSS, and interactive JS in a browser has been turned into what it has is staggering. I think you are probably ignoring the fact that we have basically converged back to a web monoculture again. A lot of the current frameworks were born out of "Chrome is shitty this way. Firefox is shitty that way. Internet Explorer is shitty this other way. This framework elides over all that."

rglover 5y ago
Not at all. I cut my teeth debugging CSS in IE6 (front-end Vietnam). I’m an old timer. And based on what I’ve learned, what I’ve done in Joystick could have been done in some capacity pre-ES6 and easily in 2014-2015 when most of these frameworks were born.