12 ms·

Ask HN: Why the web lately is all about JavaScript?

I read https://news.ycombinator.com/item?id=31341083 https://news.ycombinator.com/item?id=31341083 recently and feel quite frustrated because now everyone is rendering html using javascript. I'm on twitter reading web stuff, when they talk about "SSR" (server-sided rendering), 99% of the time it means javascript based server. Why these trying-to-be-innovation lately aren't not working with backend languages like python, ruby, elixir, go, rust etc? I have an SPA app that is quite sophisticated whose WHOLE app size is ~110kB minified, and when I look at react-dom on https://bundlephobia.com/package/react-dom@18.1.0 https://bundlephobia.com/package/react-dom@18.1.0 it's 130kB minified which sounds CREAZY to me compared to my whole app (no, it's not a todo app, it's an editor app) Is it just me that interpret this situation as "suck", or this is the future?

OhNoNotAgain_99 4y ago
java / javascrip is a hell its starts as fun until you do it a few years. there is a wow factor in all web tech its best to choose something stable and less wow, stick to proven reliable maintainable and proper coding design.
ale_jacques 4y ago
Yeah, that sucks. So much that there are people building tools to avoid that approach. Take a look at these: - https://htms.org https://htms.org - https://unpoly.com https://unpoly.com - https://hotwired.dev https://hotwired.dev
- lordofgibbons 4y ago
  I think you meant https://htmx.org https://htmx.org Reading over the Hotwired homepage, I honestly thought it was a funny parody like http://vanilla-js.com http://vanilla-js.com Turns out it's an actual framework!
crummy 4y ago
I think this is largely because people are writing JS on the frontend, and it's easier to do SSR with the code you've already got, i.e. render JS on the backend too. That said there is a movement for a more flexible style, e.g. https://htmx.org/ https://htmx.org/
- TacticalCoder 4y ago
  > I think this is largely because people are writing JS on the frontend, and it's easier to do SSR with the code you've already got That and those writing JS on the frontend are, among all the devs out there, those the more likely to be working on SSR pages.
  - ratww 4y ago
    Correct. Most backend engineers today do only the APIs to be consumed by the frontend. And there always was some sort of a separation in the industry: I remember when in some enterprisey places there was the strange role of "webdesigner" or some other (often incorrect) term that was half-designer half-programmer that only took care of HTML/CSS. Javascript was used very sparsely. There were several frameworks whose whole spiel was to allow people not to write HTML/CSS/JS. Anyone doing both the backend and the HTML/CSS part was considered a bit of a unicorn, even back then. For a lot of self-taught people doing "everything" was the norm, but in the industry it wasn't. Then came Bootstrap etc and sorta equalised everything. Then came Angular and React and we needed a name for people doing the HTML/CSS/JS work. When rendering on the server became a focus again, the responsibility of writing the markup once again fell on people able to do HTML/CSS. Which means frontend developers. Which means JS.
- IshKebab 4y ago
  Yeah and there also just aren't any good server side component libraries as far as I can tell - everyone is still just using fairly dumb templating engines like Handlebars and the like. At least as far as I can tell.
john_the_writer 4y ago
Rails is sort of fighting against this. It's trying to hide or remove as much JS as it can, with http over the wire. Still some JS, but not visible to the dev (unless they go after it)
- d_sc 4y ago
  Phoenix as well with LiveController. It’s impressive what can be built with minimal JS while being pretty responsive and snappy.
lewisjoe 4y ago
I am a front-end developer and a Javascript veteran. While I do hate the "hate" against JS, even I think using JS on the server for rendering to HTML is a terrible idea. It doesn't scale, it isn't natural; it's just convenient and taxes the end users. My solution for that is to liberate UI programming out of a single language, using WASM as the abstraction layer. For more information https://github.com/joelewis/kwasm https://github.com/joelewis/kwasm
- quickthrower2 4y ago
  I think I get why people like it. (I am starting to like it and am falling down the NextJS Tailwind SSR rabbithole) React is a decent framework conceptually and more importantly it has become a defacto standard for UI development in JS. On top of that the sheer amount of React support in terms of components, tooling and learning resources is immense. NextJS says “use what you already know and use on the backend (React), and not only that we will make it seemless to use the exact same code to render an initial paint for time to render/seo as you do for live updates, and we will chuck in static site generation for free”. Tailwind is another thing that seems really really odd, until you use it and then it seems brilliant. In a nutshell it is css classes like “m-1” for a small margin. It would be awful for a handcrafted static site, but it works great with React because it plays well with componentizing code. If skeptical read their site where they address the obvious reasons for being skeptical.
  - fendy3002 4y ago
    The thing with react SSR (or SPA) is it's easier to manage layout, styles and shared components since it's all react, as opposed to html / template rendering and using react / others in places / pages where it's needed.
    - cersa8 4y ago
      I love that even my email templates are now just tsx files and rendered on the server with ReactDOMServer.renderToString(). No more context switching, everything is TypeScript / React and refactoring is an absolute joy.
5350-uiop-1130 4y ago
it's cheaper to run your app on the client than the server i guess. the reason why i have 3 tabs open using 3gb of ram.
- deleted 4y ago
  [deleted]
oxff 4y ago
Economical reasons come into play with software engineering.
- Existenceblinks 4y ago
  Does that mean abstraction leak from inside out? (No, not outside in)
  - m0llusk 4y ago
    Easy to find javascript programmers for common tasks.
towaway15463 4y ago
For me at least its due to JavaScript having more mindshare so it’s easier to hire people to work on both the front and backend if they’re both written in JS.
- Existenceblinks 4y ago
  Literally break the mantra "the right tools for the job". Now it's everything is a nail.
  - dismalpedigree 4y ago
    Nailed it!
FlyingAvatar 4y ago
The term "Server Side Rendering" generally refers to client-side frameworks which have been adapted to server-side. These have been nearly entirely JavaScript for obvious reasons. Frameworks that generate HTML on the server side have been around a long time, but are mostly not considered in this category. I would say though there are a decent number of modern ones in the "static site generator" category that exist in many languages. It makes sense to me that in the current iteration of web tech that the client code and the server code be mostly in JavaScript since it allows for a single code base between the front and backend. There is definitely hope for other languages in this space though as WebAssembly gains more traction. As for the bundle size of an app, it's not too surprising that a bespoke app would be smaller than a modest framework. Choosing a framework will always be a trade-off of size, complexity and whatever features the framework offers. I think wether you see it as "suck" depends on how much you love or hate JavaScript and how tolerant you are to using modestly large frameworks. Mostly, I see the modern crop of JS frameworks as a breath of fresh air compared to what precedes them, though the complexity of what is imported when running an `npm install` is enough to give me pause and a wish for something more minimal.
- Existenceblinks 4y ago
  It's "client-server" architecture for reasons though. Client and server mean to have completely different roles, architecture, languages. However, browsers just happened to support one language. There are also protocols between that. I don't hate javascript as I write it too, but I also write many other languages. And I also think more of the web generally.
  - fuzzy2 4y ago
    That’s not quite the right way to put it. Client and Server have different roles, yes. That does not mean they have to be written using different languages. JavaScript on the server (in Node or Deno) is perfectly fine and scales reasonably well. If we take a step back from the most well-known client-server system (the World Wide Web) and look at other examples, we’ll find that client and server are often developed together, in a single language and similar architecture.
neoberg 4y ago
To your second question about the app size vs. framework/library sizes: Frameworks and libraries provide generalised solutions to some common problems. In react and react-dom's case it's defining a ui in a declarative and more or less performant(wihtout making the dev think too much about it) way. The downside is; it includes lots of things your app doesn't need but other apps do. The alternative is to roll your own but if your solution did all the things that the X framework did; then you'd end up with a similar size/complexity. You can build the features only needed by your app; but then I can't imagine the amount of engineering hours wasted for every apps custom framework. And nowadays ~110kb is not that big of an application really. It might be really complex in terms of concepts and what it does but current day apps are a lot bigger than that in terms of size. So the size of frameworks doesn't make that much of a difference in most cases. For example the app I'm working on in my job has a total bundle size of ~15mb minified excluding any third party code. This is just the code written and being actively used by us. We don't serve it all at once and load as needed but still.
- Existenceblinks 4y ago
  Solid.js is very small (sub 7-8kB IIRC), very similar to React.
  - neoberg 4y ago
    Yes, and I think Solid and Svelte's approaches of moving complexity out of runtime and into build time will be the most popular one very soon. But this also comes with its downsides. It complicates the build process, obviously. Debugging is harder since what you code is not what is being run at all. And they usually come with some catches like "if you use this javascript thing, your reactivity will break" kinda stuff - at least for now, but I think it can and will be solved. The gist is; there are options and there are tradeoffs.
    - Existenceblinks 4y ago
      That's the only aspect of complaining. Size is one thing, it's also javascript for everything.
seydor 4y ago
Dunno. But i think JS has actively harmed software development in the past 10 years. It's a bad language, designed and patched hastily that does not work well with humans nor machines. It took 10 years to allow having some form of synchronicity with promises, and that's just disguised callback hell. Callback depth is an inherent human limitation, because our working memory is very limited , so I consider JS a language that s unfit for humans and unfit for big projects. Silicon valley adopted JS probably because of ease of access to cheap developers. Pity there is not a serious competitor from another Valley because i think they could beat them with superior performance in just about anything.
- Crabber 4y ago
  I think the problem is that javascript has stopped being one language of many and has become the language. There are hundreds of thousands of developers now who only know javascript. They have no perception of the parts of javascript that are badly designed because they don't know any other language. They think that computers taking 500ms to render a webpage is just how slow computers are because that's how it is with javascript. They think desktop applications that use 400MB of memory on startup are normal. People no longer weigh up the pros and cons of javascript and decide it is the best option for a certain project. Javascript is all they know, and it shapes their entire view of programming.
  - AlchemistCamp 4y ago
    The kinds of devs who don’t regularly learn new languages are generally the ones you don’t want to hire.
    - herbst 4y ago
      Learning new languages is a different thing than crunching into the next JavaScript fud.
      - AlchemistCamp 4y ago
        The great thing about learning more languages is that you tend to gain new skills to take back to your old projects. This is especially true for languages meaningfully different than those you know. The same can be true of frameworks, databases and other tools.
jrockway 4y ago
I have learned all the frontend frameworks (though my React is pretty shitty) and have come to the conclusion that I much prefer just rendering HTML with html/template. The thing that led me to using the SSA style initially was that it seemed easy to write a backend and then bolt on a frontend. But there isn't actually a good transport layer for that, and the API for your web app and the API for API users usually end up being quite different. I think that GraphQL is intending to be the transport layer that just works (and since it's a graph you can query, theoretically means you don't have to write an API for your web app, teach your web app how to incrementally request things, cache things, invalidate that cache, etc.). I have found that ... it's not that great. The Go libraries for a server are terrible. There are no debugging tools. You send gigabytes of JSON for no reason. My personal favorite API is gRPC-Web, but I guess browsers never added the hooks necessary for bidi streaming, and the "tree shaken" protos + gRPC-Web runtime are HUGE, so I've decided it's not worth being excited about anymore. I typically stick grpc-gateway in front of my gRPC services and get normal RESTful JSON. And then I'm at square one where there isn't any magic in React to make that particularly useful. Anyway, yeah... just printing out HTML. Not that bad. Use fly.io and put the server close to your user and they won't even notice that it's slightly higher latency than caching everything in your SPA. And it sure is easy to debug when something goes wrong.
- Existenceblinks 4y ago
  The tricky part of edge compute though is write operation and where the data store is.
- eurasiantiger 4y ago
  Never roll your own GraphQL server on core libraries. There are existing implementations with good practices and debugging tools.
lawn 4y ago
I personally think the future is adding live functionality to the server, like how Phoenix does with LiveView.
- Existenceblinks 4y ago
  I used Liveview before (on very early version), now I use PhoenixChannel and javascript, it's great balance.
  - nagasadhu 4y ago
    Same here. Mixing ui and data logic layer was not pretty. Alpine js didn't cut it for me.
    - Existenceblinks 4y ago
      Also there is a transformation on js before handing diffs to Morphdom. There was no "replace the whole thing" without having to perform recursive diffs back then, not sure if it has now.
- chrismorgan 4y ago
  The rather massive weakness of that approach is that it requires a functioning internet connection to do anything, and is badly affected by latency. If you lived on the other side of the world from the server and had a sometimes-unreliable or -unavailable internet connection, you would not sing LiveView’s praises so loudly.
  - sfusato 4y ago
    You should be using LiveView only for things that would require a server trip anyway. For client side interactions, use a client side JS library (like Alpine [1] if Phoenix.LiveView.JS [2] is not enough) [1] https://alpinejs.dev/ https://alpinejs.dev/ [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...
Etheryte 4y ago
One of the core propositions of Javascript SSR is that you can write everything in the same way. If you have your data at compile-time, great, it can get prerendered and bundled. If not, it can be rendered on the client, the code you use it the same. You can share the logic for both, same components, same layouts, same business logic etc. You can have initial data rendered on the server and then live updates one the client side without any additional work around templating and business logic. Obviously, there are ways to write the same page and end up with a smaller bundle size, but size is only one dimension. Javascript SSR offers (arguably) less development time and less maintenance (as there's simply less code since you handle both the same way) at the expense of other things, such as bundle size etc. As with any other tradeoff, you can't only look at one parameter and say a thing is good or bad, you need to look at the whole package and figure out whether it makes sense in the given context or not.
- codethief 4y ago
  I fully agree and would add: Component-oriented frameworks like React/Angular/Vue/… give you the ability to easily test your components individually (in the sense of unit tests or integration tests or manual tests / storybooks). Most classic templating languages for the backend don't offer anything similar and doing that would also be quite challenging: Most of the time the backend controller rendering/populating a given template is deeply entwined with business logic and database calls – good luck separating those concerns after the fact.
throwaway4good 4y ago
As the client gets more computing power relative to the server, you would want to harness that. Hence more programming is moving client side and JavaScript is the dominating language / platform there.
schwartzworld 4y ago
There are upsides to both approaches. I joined my company, which uses react, and I was productive within a few days because I know react well. Would I have the same easy onboarding experience in your hand rolled app? Maybe. Maybe not. What's your testing story like in your hand rolled app? Do you have test for your atoms, molecules and organisms? How well does your tooling support your code? Popping into a framework means you get to benefit from all the productivity tools that have been built around that framework. Rolling your own anything always means forgoing many conveniences to the developer and possibly the user. The vast majority of people who use the internet don't know what JavaScript is, and especially in the US, most have no reason to really care about bundle size. No company is going to optimize for the very small group of people who browse with JavaScript turned off. Instead companies want to optimize for speed of development, testability, stability, ease of onboarding, etc.
- BlueTemplar 4y ago
  Wouldn't companies doing government-related work have minimum accessibility requirements ? And wouldn't it be hard to deal with all of them (starting with the quite common eyesight problems, though I guess browser zoom is mostly JavaScript-compatible, and red/green color blindness) without ensuring that the core website functionality works without JavaScript ?
- pwdisswordfish9 4y ago
  > The vast majority of people who use the internet don't know what JavaScript is, and especially in the US, most have no reason to really care about bundle size. It's enough for them to know that https://twitter.com/POTUS https://twitter.com/POTUS loads in half a minute, while https://nitter.net/POTUS https://nitter.net/POTUS loads almost instantly. Despite both being the exact same content!
  - schwartzworld 4y ago
    I doubt that, for example, my parents would know that, or care. My wife definitely wouldn't. Honestly I use Twitter occasionally enough that I've never even considered going to Nitter.
throwaway0asd 4y ago
The business reason is to simplify candidate selection to a narrow common criteria and never invest in training. Developers are typically viewed as a disloyal disposable commodity. From a business perspective developers are a cost center, not a revenue generator. Financially that reasoning makes sense but economically it’s stupid because you will end up with the same shitty uncompetitive product as everyone else. The developer counter argument is to just raise salaries, but over that past 2 years salaries have exploded and yet businesses have doubled down on this idea of prioritizing candidate selection and no training. To your point about code quality I agree. I have an OS frontend written in JavaScript that fully loads (completes page render with state restoration) in under 200ms according to Chrome’s performance tool. The code is about 340kb unminified. You won’t that with React.
- rozenmd 4y ago
  > From a business perspective developers are a cost center, not a revenue generator. If you work at a company where the software you write isn't what generates revenue, you're going to have a bad time. There are plenty of companies where developers are the profit centre.
  - ehnto 4y ago
    Agreed, it is unfortunate because there is some cool prolems to solve in places where software is the cost centre but it has never been worth it. In my experience, the irony is that places where software is a cost centre often run really inefficiently from a software developmemt point of view. So it's more costly and less funded, it can be difficult to pull even the simplest projects off in that environment. I am sure there are places that run well though, you just have to have the right people up the chain.
  - Existenceblinks 4y ago
    I had seen a lot of devrels meme pre-covid, now they seem to come back.
- tomxor 4y ago
  > Developers are typically viewed as a disloyal disposable commodity [...] Financially that reasoning makes sense but economically it’s stupid because you will end up with the same shitty uncompetitive product as everyone else. Which has always been my answer to over aggressive management strategies for "replaceable devs": If your product is fundamentally software, it will be as replaceable and disposable as your developers; Show some commitment instead and you will get it in return from worthwhile devs.
lousken 4y ago
I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another. Like you have drupal with bunch of modules, it's slow as hell so you put redis caching. It's faster but not as fast, so you add varnish on top, so you don't even have to touch the php code unless you make a change. But then you've never solved the problem, you just hide it two layers deep. And same with javascript - 85% of sites are visit would work perfectly fine without any javascript. Loading would've been instant, and you don't even need ajax if you can spit html document fast enough - the browser makes it seamless anyways. But no, instead, we do animations and slow down the time to interaction because it's fine sitting on 1Gbit connection waiting for your slow backend part that's not cacheable. JS isn't bad, it just feels like people think it can solve anything while not seeing issues it adds.
- Existenceblinks 4y ago
  Yeah, an html attribute on <head> or <body> for not having full page reload would make a big impact.
  - linkdd 4y ago
    Like htmx[0]'s boost attribute? I've been building a webapp with Python/Django and HTMX, it works like a charm. [0] - https://htmx.org https://htmx.org
    - Existenceblinks 4y ago
      Sorry, I mean it should be in html spec.
- cutler 4y ago
  I find Hotwire/Turbo/Stimulus in Rails to be a perfect low-JS approach.
- mbirth 4y ago
  That JavaScript for loading contents and images is probably an effect of Google's changes a few years ago where it was all about the load time of the main page. So to rise up a few steps on the Google results page, people turned to serving empty pages with a small JavaScript (which finished loading fast - so bonus points from Google) which then starts pulling in the actual content.
speedgoose 4y ago
It is the present. We try to maximise the features and reduce the cost. For example, no one develops apps in assembly by hand anymore, it’s not productive. 130kB minified is nothing unless you make an app for people in Africa or very remote parts of the world. It is cached and is loads instantly on most connections. Check the network speeds of your users, it’s very likely more than fast enough to load a 130kB file once. https://en.m.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds https://en.m.wikipedia.org/wiki/List_of_countries_by_Interne...
- Existenceblinks 4y ago
  There is a javascript size usage graph yearly .. I don't have a link bookmarked but it's getting insane. Note that 130kB is without starting writing any application.
  - speedgoose 4y ago
    Yes no one cares about the JavaScript bundle size until it becomes a problem.
    - 6510 4y ago
      I prefer not to create problems for myself.
      - speedgoose 4y ago
        Sure, but it’s more challenging to keep the bundle size very low for no reasons if you want to use modern tooling and work in a team. It’s fine for your personal hobby website, but people at work shouldn’t waste times and create problems to avoid a small and rare problem.
  - randomtwiddler 4y ago
    The amount of friction a designer gets for adding several multi MB images to a page, in every organization I've worked for, is very little. 2 MB minified, compressed, ball of js is nothing. I've even seen companies accidentally put their debug builds in production (>15MB js ball) with without noticing or getting complaints. I'm much more sensitive to page weight than most, and every sizable dev shop should have someone who is. But even I realize that current business reality is it didn't matter nearly as much as sensitive tech people think.
throwaway0x7E6 4y ago
CSR rendering is fundamentally great. when done right, it enables complete separation of concerns between the frontend and the backend, and it will vastly outperform the SSR approach in terms of performance >react-dom is 130kB the goal of these tools is not building performant applications. the goal is enabling barely skilled laborers to churn out disposable shit as quickly and cheaply as possible >I'm on twitter reading web stuff do yourself a favor and don't.
- ratww 4y ago
  Exactly. And if one really needs a slimmer version of React, there's always Preact [1] which is 3k-4k gzipped and has pretty much the same API. Of course, in real life the 130k of React is far from a problem. The React code is (more often than not) dwarfed by the application code itself. [1] http://preactjs.com http://preactjs.com
fuzzy2 4y ago
Though we had that discussion recently, I will again point out that, from how I see it, the term "SSR" does not include/refer to classic server-side applications like PHP, Django, ASP, whatever. Instead, it is used specifically to refer to single-page applications, rendered on the server. Nothing else. If you search for SSR, you will not find PHP, Django, ASP.
- paulryanrogers 4y ago
  Which is funny because I recall SSR was how one referred to non-SPA websites. Anyway, the new term seems to be server side generated SSG.
jcpst 4y ago
I’m kinda done with the JS-heavy frontends. I started my career as a nodejs developer, and spent a lot of time in SPAs in the backbone/angularjs days. The current template at my work for creating a new typescript/react UI is ridiculously heavy (to me). I’m working on a new project that is using F#/Giraffe, with the Giraffe view engine. It’s using htmx to update content without a full page reload. I love it. It’s been the most fun I’ve had developing a web app in quite a while.
- Existenceblinks 4y ago
  True, start innovation with javascript will not lead us to anywhere because the design is not going to be generic enough to form an innovative pattern that can be used everywhere. It's called "client-server" arch for reasons.
  - 6510 4y ago
    We could do client-client
deleted 4y ago
[deleted]
austinjp 4y ago
Fully agreed. Two aspects that I don't see acknowledged often enough: (1) Not everyone has fast internet. This is particularly the case in rural locations and developing nations. We're witnessing internet inequality and heavy websites are fuelling it. (2) Information transfer requires fuel and burning fuel is destroying our habitat. It might seem trivial to shave kB off download sizes, but the cumulative effect of large sites doing this should be acknowledged and encouraged. My reaction to this ridiculous situation: Use Preact instead of React -- I'm planning to switch to Svelte next -- and using minimal dependencies and writing my own minimalist implementations where feasible. I need to get better at this. Use code-splitting and lazy loading to keep gzipped download under 100k for all content per "page". Avoid web fonts, images, tracking, 3rd party crap, cookies, advertising, etc etc etc. I'm lucky enough to be in a position where nobody is telling me to put this stuff in. Tree-shake, minify, compress (brotli if possible). Sure, it takes processing power to decompress at the other end, but my suspicion is overall compression wins. Happy to be proven wrong. User-test everything on a throttled connection at 3G speeds. Or "poor 3G" or whatever the browser dev tools have. This is subjective, of course, but gives me a good sense of user experience. It's not a perfect recipe, but downloading megs of crap for a web page is totally unacceptable. (Obviously all the above side-steps the "no JS" perspective.)
- Existenceblinks 4y ago
  Yep, anything else works, they are mostly sub 10kB view lib. It's fascinating that the current situation is widely acceptable.
- cutler 4y ago
  Solid.js may change all this.
  - eyelidlessness 4y ago
    Solid is great, and its focus on performance definitely helps. But for now I think a couple of other tools are better positioned here, as they already focus on shipping less JS to the client in the first place. For instance Astro (“islands architecture”/“partial hydration”; it supports Solid islands however!) and Qwik (“resumability”/on demand loading of interactive JS as it’s needed). In a lot of cases, just shipping less JS in the first place is going to perform better for resource constrained usage. Solid is currently more oriented towards fully interactive SPA use cases, but they do have partial hydration (or something like it) on the roadmap.
recursivedoubts 4y ago
there is a growing reaction against the JS-everywhere situation, using hypermedia & HTML over the wire rather than JSON data APIs I am calling these applications Hypermedia Driven Applications or Hypermedia Oriented Libraries: https://htmx.org/essays/hypermedia-driven-applications/ https://htmx.org/essays/hypermedia-driven-applications/ libs like unpoly, hotwire or my own htmx are all hypermedia oriented, recentering HTML and hypermedia as the core application architecture for your app some other related essays: https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/a-response-to-rich-harris/ https://htmx.org/essays/a-response-to-rich-harris/ the really nice thing about the hypermedia approach is that it takes pressure off adopting JS/TS on the backend, since you no longer have a massive front end codebase already in JS/TS and it can be hard to justify having two different languages, models, etc. With hypermedia, you don't have this situation. I jokingly call this "stack" the HOWL stack: Hypermedia On Whatever you'd Like.
Spooky23 4y ago
There’s a lot of discussion about developers and business drivers. But remember things like React and Angular hsve been around for a decade or maybe a little more. At that time flash was on the road to sunset (but still a thing - YouTube was flash then), and mobile devices were still in hyper growth mode. Browser makers (well Google and Apple) were investing alot of resources into making JavaScript more performant. In my mind, it’s a no brainer. You want to deliver rich client experiences without proprietary hooks like Flash and Silverlight. The most heavily resources engineering orgs on the planet are focused on making JS fast… the smart strategic bet bet is to bet on them!
yen223 4y ago
The obvious reason is that Javascript is the only language that runs on most browsers (outside of Webassembly, which has its own limitations). If you want to do anything interesting on web browsers, you will have to deal with Javascript. A more interesting question is, why is Javascript the language that all browsers support? Go back 20 years, and it wasn't actually obvious that Javascript would beat out Flash, or Java applets, or even VBScript to be the main way to get interactivity on websites.
- hollowturtle 4y ago
  wasn’t obvious? I’m not sure, thanks god flash was killed, it was a security nightmare. java applets were a heavyweight punch in the face and vbscript… well is was vbscript. not even mentioning accessibility issues of the aforementioned. with javascript the open web won luckily for us
- physicles 4y ago
  I just had a terrifying vision of the alternate universe where VBScript became the lingua franca of the web. JavaScript isn’t perfect, but standardizing on VBScript would’ve been a catastrophic mistake.
spiffytech 4y ago
I keep using JavaScript on the back-end because my projects all need rich front-ends and switching between + keeping my skills fresh in two separate languages is an awful lot of friction. I anticipate that the WASM ecosystem will mature enough that non-JS front-ends will become standard fare, and then I'll be delighted to pick a back-end language where stack traces actually include lines for code I wrote.
ericfrazier 4y ago
My vanilla JS app is way smaller than your fat app. JS doesn't automatically mean massive frameworks and libraries. Just write vanilla from-scratch JS like I do and life is fun and happy.
- bitwize 4y ago
  DOM manipulation in vanilla JS is an enormous pain in the ass. You need a framework, or at least something like jQuery, to be productive,
  - winrid 4y ago
    You think? FastComments doesn't use any DOM manipulation frameworks.
  - rishav_sharan 4y ago
    Umm no?! Maybe 20 years ago. But it's trivial today
rektide 4y ago
> Is it just me that interpret this situation as "suck", or this is the future First, there's room for everyone. Plenty of other trchnologies have are & will happen. But JS has by far the biggest, most boisterous & complete web ecosystem. By far. And a huge amount of the ecosystem works just as well front end, back end, and thanks to AssemblyScript, both at once (portability: a huge advantage). As for "just me" / "suck"... other people also turn up their noses. But largely these are legacy preconceptions. JS didnt used to have robust serverside stories (altough I did write some JScript a long long time ago...), didnt have fast runtimes, didnt have a package ecosystem, and so yeah JS didnt fit. But it's grown evolved & gotten fast. Much of NodeJS's history stems directly from Ryan Dahl comparing python web framework's performance,... and finding them wanting, thinking he could do better. With a performant async server, with Isaacs developing npm packages, things quikcly took off. Some poeple dont like JS the language. I have less clear ways to refute this, since it's almost entirely ill defined bias & personal opinion: you cant really argue with someome who says "i dont like bananas" & thats about as far as these discussions tend to go. JS ticks all the boxes for a great & capable way to write server side code. It's still the way to write front end code (although wasm Component Model (nee interface-types) is finslly happening & will make other languages much more viable). > when I look at react-dom it's 130kB minified which sounds CRAZY to me As for react-dom, well, it's magically good stuff. It's worth it. Having immediate mode style rendering, having deep deep control over the front end, but not having to swizzle dom: it's a huge accelerant. There's preact & other "lite" takes that work similarly. I suspect react-dom might tree shake & get smaller for many deployments: bundlephobia can mever detect or understand how much code you will end up not shipping. Also, this only really should affect first load & occasional library updates. clapping: it. just. doesnt. matter.
- Existenceblinks 4y ago
  react-dom is pretty much a sole purpose, there is no subpackage or its form of plugin. So shaking out unused functions isn't doing much since it's supposed to be * imported anyway.
DantesKite 4y ago
There's probably multiple factors at play, but one small factor I'd like to introduce is how there's way more tutorials for learning Javascript than say Rust.
joshxyz 4y ago
Actually the delight of it is most of our developer tools now are powered with go-based and rust-based binaries that speed up our iteration processes. For example, esbuild, typesense, etc.
stuu99 4y ago
d--b 4y ago
You don’t have to like it. I do a lot of data science in C#, and absolutely loathe Python. I am not the only one who thinks that the ubiquity of Python sucks but I am certainly in the minority. I’ve stopped caring.
- mm007emko 4y ago
  So do I. But ... at home for my own projects I use language and tools I like (Common Lisp, Clojure...) At work I use whatever I get paid for. I recently left Java job in favour of a Python one because they paid me more. You know, Python hackers hacked together something then left and they realized they need software engineers, not hackers. Python is not a bad language (compared to JavaScript). Python interpreter is a piece of shite and the culture and common practicies is what sucks the most. People praise NumPy, Pandas, Flask etc. because they don't know anything else. Anything better. At least they don't have to pay for this.
- perfopt 4y ago
  I dislike Python too. But I use it because I have to - a lot of the stuff at work is in Python.
nathants 4y ago
everything is fine. i’ve gone full spa[1]. i don’t think i could go back. my starter project is here[2]. backend is go on lambda. frontend is clojurescript with react and mui, compiled down to a single html file with js inlined, and pre-gzipped. lambda zip contains two files: - ./main - ./index.html.gzip the backend returns the index for any route not beginning with /api/. websockets and http ferry information between frontend and backend. s3 and dynamo persist data. ops are easy. sdlc is fast. frontend runs local and instantly reloads. backend reloads in 1s. if you have bad upload bandwidth, do backend builds on an ec2 relay for $5/month! or just tolerate 10-20s backend reloads depending on your bandwidth. sure the index is a bit heavy, but if it’s not annoying to use on a phone over cellular, it’s probably fine. have most react devs seen the regeant[3] interface that clojurescript devs use with react? it’s so simple and hasn’t changed in a decade! i start all my projects this way now, and am so happy. i can’t imagine a better workflow. 1. https://gocljs.nathants.com https://gocljs.nathants.com 2. https://github.com/nathants/new-gocljs https://github.com/nathants/new-gocljs 3. https://reagent-project.github.io/ https://reagent-project.github.io/
aristofun 4y ago
1. Only JS is already in the browsers. 2. JS is simple. These are the big killer features and selling points for it's crazy adoption. But fortunately with the raise of TypeScript, which solved many of JS original traumas and made it team-scalable, it's not that of a big deal. In the end it's not about "trying-to-be-innovation", it's about money. Yes, it may be much faster and more appropriate to run some code on Go or Java. But often the difference in salaries and time to market (see selling points above) can't justify that decision. I personally witnessed the benefits of migrating from Scala to Nodejs in a big company, and I'll definitely vote for Nodejs next time in similar conditions.
MauroIksem 4y ago
Look at .Net Blazor for a non JavaScript solution.
perfopt 4y ago
What did you write your SPA app in if you dont mind my asking. Web apps and "full-stack" is not my area. Based on what I have read online I was under the impression that it is all Javascript and ver had a motivation to learn it. I would love to know how to create a web app - user interface to back end server code - without node.js, React, Angular etc
- Existenceblinks 4y ago
  All you need is a tiny view lib like lit-html/uhtml, and event dipatcher (DOM element can do that, or use bare EventTarget), now you get a MVC pattern loop; event fired -> state changed (+ optional effect) -> re-render.
nokya 4y ago
Simple: ads and personal data collection. The more developers get convinced they need JavaScript everywhere, the more these companies benefit from accrued data collection opportunities.
phil_kahrl 4y ago
Been doing web development for 25 years, I am currently learning Rust in hope that I can compile to Web Assembly and build SPAs that way. The JavaScript ecosystem is a mess of module systems, type systems, layers upon layers of libraries and build tools and building a web app that is actually maintainable, consistent and extensible is difficult to impossible. We need better tooling than what is currently considered standard.

OhNoNotAgain_99 4y ago

java / javascrip is a hell its starts as fun until you do it a few years. there is a wow factor in all web tech its best to choose something stable and less wow, stick to proven reliable maintainable and proper coding design.

ale_jacques 4y ago

Yeah, that sucks. So much that there are people building tools to avoid that approach. Take a look at these: - https://htms.org https://htms.org - https://unpoly.com https://unpoly.com - https://hotwired.dev https://hotwired.dev

lordofgibbons 4y ago
I think you meant https://htmx.org https://htmx.org Reading over the Hotwired homepage, I honestly thought it was a funny parody like http://vanilla-js.com http://vanilla-js.com Turns out it's an actual framework!

crummy 4y ago

I think this is largely because people are writing JS on the frontend, and it's easier to do SSR with the code you've already got, i.e. render JS on the backend too. That said there is a movement for a more flexible style, e.g. https://htmx.org/ https://htmx.org/

TacticalCoder 4y ago
> I think this is largely because people are writing JS on the frontend, and it's easier to do SSR with the code you've already got That and those writing JS on the frontend are, among all the devs out there, those the more likely to be working on SSR pages.
- ratww 4y ago
  Correct. Most backend engineers today do only the APIs to be consumed by the frontend. And there always was some sort of a separation in the industry: I remember when in some enterprisey places there was the strange role of "webdesigner" or some other (often incorrect) term that was half-designer half-programmer that only took care of HTML/CSS. Javascript was used very sparsely. There were several frameworks whose whole spiel was to allow people not to write HTML/CSS/JS. Anyone doing both the backend and the HTML/CSS part was considered a bit of a unicorn, even back then. For a lot of self-taught people doing "everything" was the norm, but in the industry it wasn't. Then came Bootstrap etc and sorta equalised everything. Then came Angular and React and we needed a name for people doing the HTML/CSS/JS work. When rendering on the server became a focus again, the responsibility of writing the markup once again fell on people able to do HTML/CSS. Which means frontend developers. Which means JS.
IshKebab 4y ago
Yeah and there also just aren't any good server side component libraries as far as I can tell - everyone is still just using fairly dumb templating engines like Handlebars and the like. At least as far as I can tell.

john_the_writer 4y ago

Rails is sort of fighting against this. It's trying to hide or remove as much JS as it can, with http over the wire. Still some JS, but not visible to the dev (unless they go after it)

d_sc 4y ago
Phoenix as well with LiveController. It’s impressive what can be built with minimal JS while being pretty responsive and snappy.

lewisjoe 4y ago

I am a front-end developer and a Javascript veteran. While I do hate the "hate" against JS, even I think using JS on the server for rendering to HTML is a terrible idea. It doesn't scale, it isn't natural; it's just convenient and taxes the end users. My solution for that is to liberate UI programming out of a single language, using WASM as the abstraction layer. For more information https://github.com/joelewis/kwasm https://github.com/joelewis/kwasm

quickthrower2 4y ago
I think I get why people like it. (I am starting to like it and am falling down the NextJS Tailwind SSR rabbithole) React is a decent framework conceptually and more importantly it has become a defacto standard for UI development in JS. On top of that the sheer amount of React support in terms of components, tooling and learning resources is immense. NextJS says “use what you already know and use on the backend (React), and not only that we will make it seemless to use the exact same code to render an initial paint for time to render/seo as you do for live updates, and we will chuck in static site generation for free”. Tailwind is another thing that seems really really odd, until you use it and then it seems brilliant. In a nutshell it is css classes like “m-1” for a small margin. It would be awful for a handcrafted static site, but it works great with React because it plays well with componentizing code. If skeptical read their site where they address the obvious reasons for being skeptical.
- fendy3002 4y ago
  The thing with react SSR (or SPA) is it's easier to manage layout, styles and shared components since it's all react, as opposed to html / template rendering and using react / others in places / pages where it's needed.
  - cersa8 4y ago
    I love that even my email templates are now just tsx files and rendered on the server with ReactDOMServer.renderToString(). No more context switching, everything is TypeScript / React and refactoring is an absolute joy.

5350-uiop-1130 4y ago

it's cheaper to run your app on the client than the server i guess. the reason why i have 3 tabs open using 3gb of ram.

deleted 4y ago
[deleted]

oxff 4y ago

Economical reasons come into play with software engineering.

Existenceblinks 4y ago
Does that mean abstraction leak from inside out? (No, not outside in)
- m0llusk 4y ago
  Easy to find javascript programmers for common tasks.

towaway15463 4y ago

For me at least its due to JavaScript having more mindshare so it’s easier to hire people to work on both the front and backend if they’re both written in JS.

Existenceblinks 4y ago
Literally break the mantra "the right tools for the job". Now it's everything is a nail.
- dismalpedigree 4y ago
  Nailed it!

FlyingAvatar 4y ago

The term "Server Side Rendering" generally refers to client-side frameworks which have been adapted to server-side. These have been nearly entirely JavaScript for obvious reasons. Frameworks that generate HTML on the server side have been around a long time, but are mostly not considered in this category. I would say though there are a decent number of modern ones in the "static site generator" category that exist in many languages. It makes sense to me that in the current iteration of web tech that the client code and the server code be mostly in JavaScript since it allows for a single code base between the front and backend. There is definitely hope for other languages in this space though as WebAssembly gains more traction. As for the bundle size of an app, it's not too surprising that a bespoke app would be smaller than a modest framework. Choosing a framework will always be a trade-off of size, complexity and whatever features the framework offers. I think wether you see it as "suck" depends on how much you love or hate JavaScript and how tolerant you are to using modestly large frameworks. Mostly, I see the modern crop of JS frameworks as a breath of fresh air compared to what precedes them, though the complexity of what is imported when running an `npm install` is enough to give me pause and a wish for something more minimal.

Existenceblinks 4y ago
It's "client-server" architecture for reasons though. Client and server mean to have completely different roles, architecture, languages. However, browsers just happened to support one language. There are also protocols between that. I don't hate javascript as I write it too, but I also write many other languages. And I also think more of the web generally.
- fuzzy2 4y ago
  That’s not quite the right way to put it. Client and Server have different roles, yes. That does not mean they have to be written using different languages. JavaScript on the server (in Node or Deno) is perfectly fine and scales reasonably well. If we take a step back from the most well-known client-server system (the World Wide Web) and look at other examples, we’ll find that client and server are often developed together, in a single language and similar architecture.

neoberg 4y ago

To your second question about the app size vs. framework/library sizes: Frameworks and libraries provide generalised solutions to some common problems. In react and react-dom's case it's defining a ui in a declarative and more or less performant(wihtout making the dev think too much about it) way. The downside is; it includes lots of things your app doesn't need but other apps do. The alternative is to roll your own but if your solution did all the things that the X framework did; then you'd end up with a similar size/complexity. You can build the features only needed by your app; but then I can't imagine the amount of engineering hours wasted for every apps custom framework. And nowadays ~110kb is not that big of an application really. It might be really complex in terms of concepts and what it does but current day apps are a lot bigger than that in terms of size. So the size of frameworks doesn't make that much of a difference in most cases. For example the app I'm working on in my job has a total bundle size of ~15mb minified excluding any third party code. This is just the code written and being actively used by us. We don't serve it all at once and load as needed but still.

Existenceblinks 4y ago
Solid.js is very small (sub 7-8kB IIRC), very similar to React.
- neoberg 4y ago
  Yes, and I think Solid and Svelte's approaches of moving complexity out of runtime and into build time will be the most popular one very soon. But this also comes with its downsides. It complicates the build process, obviously. Debugging is harder since what you code is not what is being run at all. And they usually come with some catches like "if you use this javascript thing, your reactivity will break" kinda stuff - at least for now, but I think it can and will be solved. The gist is; there are options and there are tradeoffs.
  - Existenceblinks 4y ago
    That's the only aspect of complaining. Size is one thing, it's also javascript for everything.

seydor 4y ago

Dunno. But i think JS has actively harmed software development in the past 10 years. It's a bad language, designed and patched hastily that does not work well with humans nor machines. It took 10 years to allow having some form of synchronicity with promises, and that's just disguised callback hell. Callback depth is an inherent human limitation, because our working memory is very limited , so I consider JS a language that s unfit for humans and unfit for big projects. Silicon valley adopted JS probably because of ease of access to cheap developers. Pity there is not a serious competitor from another Valley because i think they could beat them with superior performance in just about anything.

Crabber 4y ago
I think the problem is that javascript has stopped being one language of many and has become the language. There are hundreds of thousands of developers now who only know javascript. They have no perception of the parts of javascript that are badly designed because they don't know any other language. They think that computers taking 500ms to render a webpage is just how slow computers are because that's how it is with javascript. They think desktop applications that use 400MB of memory on startup are normal. People no longer weigh up the pros and cons of javascript and decide it is the best option for a certain project. Javascript is all they know, and it shapes their entire view of programming.
- AlchemistCamp 4y ago
  The kinds of devs who don’t regularly learn new languages are generally the ones you don’t want to hire.
  - herbst 4y ago
    Learning new languages is a different thing than crunching into the next JavaScript fud.
    - AlchemistCamp 4y ago
      The great thing about learning more languages is that you tend to gain new skills to take back to your old projects. This is especially true for languages meaningfully different than those you know. The same can be true of frameworks, databases and other tools.

jrockway 4y ago

I have learned all the frontend frameworks (though my React is pretty shitty) and have come to the conclusion that I much prefer just rendering HTML with html/template. The thing that led me to using the SSA style initially was that it seemed easy to write a backend and then bolt on a frontend. But there isn't actually a good transport layer for that, and the API for your web app and the API for API users usually end up being quite different. I think that GraphQL is intending to be the transport layer that just works (and since it's a graph you can query, theoretically means you don't have to write an API for your web app, teach your web app how to incrementally request things, cache things, invalidate that cache, etc.). I have found that ... it's not that great. The Go libraries for a server are terrible. There are no debugging tools. You send gigabytes of JSON for no reason. My personal favorite API is gRPC-Web, but I guess browsers never added the hooks necessary for bidi streaming, and the "tree shaken" protos + gRPC-Web runtime are HUGE, so I've decided it's not worth being excited about anymore. I typically stick grpc-gateway in front of my gRPC services and get normal RESTful JSON. And then I'm at square one where there isn't any magic in React to make that particularly useful. Anyway, yeah... just printing out HTML. Not that bad. Use fly.io and put the server close to your user and they won't even notice that it's slightly higher latency than caching everything in your SPA. And it sure is easy to debug when something goes wrong.

Existenceblinks 4y ago
The tricky part of edge compute though is write operation and where the data store is.
eurasiantiger 4y ago
Never roll your own GraphQL server on core libraries. There are existing implementations with good practices and debugging tools.

lawn 4y ago

I personally think the future is adding live functionality to the server, like how Phoenix does with LiveView.

Existenceblinks 4y ago
I used Liveview before (on very early version), now I use PhoenixChannel and javascript, it's great balance.
- nagasadhu 4y ago
  Same here. Mixing ui and data logic layer was not pretty. Alpine js didn't cut it for me.
  - Existenceblinks 4y ago
    Also there is a transformation on js before handing diffs to Morphdom. There was no "replace the whole thing" without having to perform recursive diffs back then, not sure if it has now.
chrismorgan 4y ago
The rather massive weakness of that approach is that it requires a functioning internet connection to do anything, and is badly affected by latency. If you lived on the other side of the world from the server and had a sometimes-unreliable or -unavailable internet connection, you would not sing LiveView’s praises so loudly.
- sfusato 4y ago
  You should be using LiveView only for things that would require a server trip anyway. For client side interactions, use a client side JS library (like Alpine [1] if Phoenix.LiveView.JS [2] is not enough) [1] https://alpinejs.dev/ https://alpinejs.dev/ [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...

Etheryte 4y ago

One of the core propositions of Javascript SSR is that you can write everything in the same way. If you have your data at compile-time, great, it can get prerendered and bundled. If not, it can be rendered on the client, the code you use it the same. You can share the logic for both, same components, same layouts, same business logic etc. You can have initial data rendered on the server and then live updates one the client side without any additional work around templating and business logic. Obviously, there are ways to write the same page and end up with a smaller bundle size, but size is only one dimension. Javascript SSR offers (arguably) less development time and less maintenance (as there's simply less code since you handle both the same way) at the expense of other things, such as bundle size etc. As with any other tradeoff, you can't only look at one parameter and say a thing is good or bad, you need to look at the whole package and figure out whether it makes sense in the given context or not.

codethief 4y ago
I fully agree and would add: Component-oriented frameworks like React/Angular/Vue/… give you the ability to easily test your components individually (in the sense of unit tests or integration tests or manual tests / storybooks). Most classic templating languages for the backend don't offer anything similar and doing that would also be quite challenging: Most of the time the backend controller rendering/populating a given template is deeply entwined with business logic and database calls – good luck separating those concerns after the fact.

throwaway4good 4y ago

As the client gets more computing power relative to the server, you would want to harness that. Hence more programming is moving client side and JavaScript is the dominating language / platform there.

schwartzworld 4y ago

There are upsides to both approaches. I joined my company, which uses react, and I was productive within a few days because I know react well. Would I have the same easy onboarding experience in your hand rolled app? Maybe. Maybe not. What's your testing story like in your hand rolled app? Do you have test for your atoms, molecules and organisms? How well does your tooling support your code? Popping into a framework means you get to benefit from all the productivity tools that have been built around that framework. Rolling your own anything always means forgoing many conveniences to the developer and possibly the user. The vast majority of people who use the internet don't know what JavaScript is, and especially in the US, most have no reason to really care about bundle size. No company is going to optimize for the very small group of people who browse with JavaScript turned off. Instead companies want to optimize for speed of development, testability, stability, ease of onboarding, etc.

BlueTemplar 4y ago
Wouldn't companies doing government-related work have minimum accessibility requirements ? And wouldn't it be hard to deal with all of them (starting with the quite common eyesight problems, though I guess browser zoom is mostly JavaScript-compatible, and red/green color blindness) without ensuring that the core website functionality works without JavaScript ?
pwdisswordfish9 4y ago
> The vast majority of people who use the internet don't know what JavaScript is, and especially in the US, most have no reason to really care about bundle size. It's enough for them to know that https://twitter.com/POTUS https://twitter.com/POTUS loads in half a minute, while https://nitter.net/POTUS https://nitter.net/POTUS loads almost instantly. Despite both being the exact same content!
- schwartzworld 4y ago
  I doubt that, for example, my parents would know that, or care. My wife definitely wouldn't. Honestly I use Twitter occasionally enough that I've never even considered going to Nitter.

throwaway0asd 4y ago

The business reason is to simplify candidate selection to a narrow common criteria and never invest in training. Developers are typically viewed as a disloyal disposable commodity. From a business perspective developers are a cost center, not a revenue generator. Financially that reasoning makes sense but economically it’s stupid because you will end up with the same shitty uncompetitive product as everyone else. The developer counter argument is to just raise salaries, but over that past 2 years salaries have exploded and yet businesses have doubled down on this idea of prioritizing candidate selection and no training. To your point about code quality I agree. I have an OS frontend written in JavaScript that fully loads (completes page render with state restoration) in under 200ms according to Chrome’s performance tool. The code is about 340kb unminified. You won’t that with React.

rozenmd 4y ago
> From a business perspective developers are a cost center, not a revenue generator. If you work at a company where the software you write isn't what generates revenue, you're going to have a bad time. There are plenty of companies where developers are the profit centre.
- ehnto 4y ago
  Agreed, it is unfortunate because there is some cool prolems to solve in places where software is the cost centre but it has never been worth it. In my experience, the irony is that places where software is a cost centre often run really inefficiently from a software developmemt point of view. So it's more costly and less funded, it can be difficult to pull even the simplest projects off in that environment. I am sure there are places that run well though, you just have to have the right people up the chain.
- Existenceblinks 4y ago
  I had seen a lot of devrels meme pre-covid, now they seem to come back.
tomxor 4y ago
> Developers are typically viewed as a disloyal disposable commodity [...] Financially that reasoning makes sense but economically it’s stupid because you will end up with the same shitty uncompetitive product as everyone else. Which has always been my answer to over aggressive management strategies for "replaceable devs": If your product is fundamentally software, it will be as replaceable and disposable as your developers; Show some commitment instead and you will get it in return from worthwhile devs.

lousken 4y ago

I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another. Like you have drupal with bunch of modules, it's slow as hell so you put redis caching. It's faster but not as fast, so you add varnish on top, so you don't even have to touch the php code unless you make a change. But then you've never solved the problem, you just hide it two layers deep. And same with javascript - 85% of sites are visit would work perfectly fine without any javascript. Loading would've been instant, and you don't even need ajax if you can spit html document fast enough - the browser makes it seamless anyways. But no, instead, we do animations and slow down the time to interaction because it's fine sitting on 1Gbit connection waiting for your slow backend part that's not cacheable. JS isn't bad, it just feels like people think it can solve anything while not seeing issues it adds.

Existenceblinks 4y ago
Yeah, an html attribute on <head> or <body> for not having full page reload would make a big impact.
- linkdd 4y ago
  Like htmx[0]'s boost attribute? I've been building a webapp with Python/Django and HTMX, it works like a charm. [0] - https://htmx.org https://htmx.org
  - Existenceblinks 4y ago
    Sorry, I mean it should be in html spec.
cutler 4y ago
I find Hotwire/Turbo/Stimulus in Rails to be a perfect low-JS approach.
mbirth 4y ago
That JavaScript for loading contents and images is probably an effect of Google's changes a few years ago where it was all about the load time of the main page. So to rise up a few steps on the Google results page, people turned to serving empty pages with a small JavaScript (which finished loading fast - so bonus points from Google) which then starts pulling in the actual content.

speedgoose 4y ago

It is the present. We try to maximise the features and reduce the cost. For example, no one develops apps in assembly by hand anymore, it’s not productive. 130kB minified is nothing unless you make an app for people in Africa or very remote parts of the world. It is cached and is loads instantly on most connections. Check the network speeds of your users, it’s very likely more than fast enough to load a 130kB file once. https://en.m.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds https://en.m.wikipedia.org/wiki/List_of_countries_by_Interne...

Existenceblinks 4y ago
There is a javascript size usage graph yearly .. I don't have a link bookmarked but it's getting insane. Note that 130kB is without starting writing any application.
- speedgoose 4y ago
  Yes no one cares about the JavaScript bundle size until it becomes a problem.
  - 6510 4y ago
    I prefer not to create problems for myself.
    - speedgoose 4y ago
      Sure, but it’s more challenging to keep the bundle size very low for no reasons if you want to use modern tooling and work in a team. It’s fine for your personal hobby website, but people at work shouldn’t waste times and create problems to avoid a small and rare problem.
- randomtwiddler 4y ago
  The amount of friction a designer gets for adding several multi MB images to a page, in every organization I've worked for, is very little. 2 MB minified, compressed, ball of js is nothing. I've even seen companies accidentally put their debug builds in production (>15MB js ball) with without noticing or getting complaints. I'm much more sensitive to page weight than most, and every sizable dev shop should have someone who is. But even I realize that current business reality is it didn't matter nearly as much as sensitive tech people think.

throwaway0x7E6 4y ago

CSR rendering is fundamentally great. when done right, it enables complete separation of concerns between the frontend and the backend, and it will vastly outperform the SSR approach in terms of performance >react-dom is 130kB the goal of these tools is not building performant applications. the goal is enabling barely skilled laborers to churn out disposable shit as quickly and cheaply as possible >I'm on twitter reading web stuff do yourself a favor and don't.

ratww 4y ago
Exactly. And if one really needs a slimmer version of React, there's always Preact [1] which is 3k-4k gzipped and has pretty much the same API. Of course, in real life the 130k of React is far from a problem. The React code is (more often than not) dwarfed by the application code itself. [1] http://preactjs.com http://preactjs.com

fuzzy2 4y ago

Though we had that discussion recently, I will again point out that, from how I see it, the term "SSR" does not include/refer to classic server-side applications like PHP, Django, ASP, whatever. Instead, it is used specifically to refer to single-page applications, rendered on the server. Nothing else. If you search for SSR, you will not find PHP, Django, ASP.

paulryanrogers 4y ago
Which is funny because I recall SSR was how one referred to non-SPA websites. Anyway, the new term seems to be server side generated SSG.

jcpst 4y ago

I’m kinda done with the JS-heavy frontends. I started my career as a nodejs developer, and spent a lot of time in SPAs in the backbone/angularjs days. The current template at my work for creating a new typescript/react UI is ridiculously heavy (to me). I’m working on a new project that is using F#/Giraffe, with the Giraffe view engine. It’s using htmx to update content without a full page reload. I love it. It’s been the most fun I’ve had developing a web app in quite a while.

Existenceblinks 4y ago
True, start innovation with javascript will not lead us to anywhere because the design is not going to be generic enough to form an innovative pattern that can be used everywhere. It's called "client-server" arch for reasons.
- 6510 4y ago
  We could do client-client

deleted 4y ago

[deleted]

austinjp 4y ago

Fully agreed. Two aspects that I don't see acknowledged often enough: (1) Not everyone has fast internet. This is particularly the case in rural locations and developing nations. We're witnessing internet inequality and heavy websites are fuelling it. (2) Information transfer requires fuel and burning fuel is destroying our habitat. It might seem trivial to shave kB off download sizes, but the cumulative effect of large sites doing this should be acknowledged and encouraged. My reaction to this ridiculous situation: Use Preact instead of React -- I'm planning to switch to Svelte next -- and using minimal dependencies and writing my own minimalist implementations where feasible. I need to get better at this. Use code-splitting and lazy loading to keep gzipped download under 100k for all content per "page". Avoid web fonts, images, tracking, 3rd party crap, cookies, advertising, etc etc etc. I'm lucky enough to be in a position where nobody is telling me to put this stuff in. Tree-shake, minify, compress (brotli if possible). Sure, it takes processing power to decompress at the other end, but my suspicion is overall compression wins. Happy to be proven wrong. User-test everything on a throttled connection at 3G speeds. Or "poor 3G" or whatever the browser dev tools have. This is subjective, of course, but gives me a good sense of user experience. It's not a perfect recipe, but downloading megs of crap for a web page is totally unacceptable. (Obviously all the above side-steps the "no JS" perspective.)

Existenceblinks 4y ago
Yep, anything else works, they are mostly sub 10kB view lib. It's fascinating that the current situation is widely acceptable.
cutler 4y ago
Solid.js may change all this.
- eyelidlessness 4y ago
  Solid is great, and its focus on performance definitely helps. But for now I think a couple of other tools are better positioned here, as they already focus on shipping less JS to the client in the first place. For instance Astro (“islands architecture”/“partial hydration”; it supports Solid islands however!) and Qwik (“resumability”/on demand loading of interactive JS as it’s needed). In a lot of cases, just shipping less JS in the first place is going to perform better for resource constrained usage. Solid is currently more oriented towards fully interactive SPA use cases, but they do have partial hydration (or something like it) on the roadmap.

recursivedoubts 4y ago

there is a growing reaction against the JS-everywhere situation, using hypermedia & HTML over the wire rather than JSON data APIs I am calling these applications Hypermedia Driven Applications or Hypermedia Oriented Libraries: https://htmx.org/essays/hypermedia-driven-applications/ https://htmx.org/essays/hypermedia-driven-applications/ libs like unpoly, hotwire or my own htmx are all hypermedia oriented, recentering HTML and hypermedia as the core application architecture for your app some other related essays: https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/spa-alternative/ https://htmx.org/essays/a-response-to-rich-harris/ https://htmx.org/essays/a-response-to-rich-harris/ the really nice thing about the hypermedia approach is that it takes pressure off adopting JS/TS on the backend, since you no longer have a massive front end codebase already in JS/TS and it can be hard to justify having two different languages, models, etc. With hypermedia, you don't have this situation. I jokingly call this "stack" the HOWL stack: Hypermedia On Whatever you'd Like.

Spooky23 4y ago

There’s a lot of discussion about developers and business drivers. But remember things like React and Angular hsve been around for a decade or maybe a little more. At that time flash was on the road to sunset (but still a thing - YouTube was flash then), and mobile devices were still in hyper growth mode. Browser makers (well Google and Apple) were investing alot of resources into making JavaScript more performant. In my mind, it’s a no brainer. You want to deliver rich client experiences without proprietary hooks like Flash and Silverlight. The most heavily resources engineering orgs on the planet are focused on making JS fast… the smart strategic bet bet is to bet on them!

yen223 4y ago

The obvious reason is that Javascript is the only language that runs on most browsers (outside of Webassembly, which has its own limitations). If you want to do anything interesting on web browsers, you will have to deal with Javascript. A more interesting question is, why is Javascript the language that all browsers support? Go back 20 years, and it wasn't actually obvious that Javascript would beat out Flash, or Java applets, or even VBScript to be the main way to get interactivity on websites.

hollowturtle 4y ago
wasn’t obvious? I’m not sure, thanks god flash was killed, it was a security nightmare. java applets were a heavyweight punch in the face and vbscript… well is was vbscript. not even mentioning accessibility issues of the aforementioned. with javascript the open web won luckily for us
physicles 4y ago
I just had a terrifying vision of the alternate universe where VBScript became the lingua franca of the web. JavaScript isn’t perfect, but standardizing on VBScript would’ve been a catastrophic mistake.

spiffytech 4y ago

I keep using JavaScript on the back-end because my projects all need rich front-ends and switching between + keeping my skills fresh in two separate languages is an awful lot of friction. I anticipate that the WASM ecosystem will mature enough that non-JS front-ends will become standard fare, and then I'll be delighted to pick a back-end language where stack traces actually include lines for code I wrote.

ericfrazier 4y ago

My vanilla JS app is way smaller than your fat app. JS doesn't automatically mean massive frameworks and libraries. Just write vanilla from-scratch JS like I do and life is fun and happy.

bitwize 4y ago
DOM manipulation in vanilla JS is an enormous pain in the ass. You need a framework, or at least something like jQuery, to be productive,
- winrid 4y ago
  You think? FastComments doesn't use any DOM manipulation frameworks.
- rishav_sharan 4y ago
  Umm no?! Maybe 20 years ago. But it's trivial today

rektide 4y ago

> Is it just me that interpret this situation as "suck", or this is the future First, there's room for everyone. Plenty of other trchnologies have are & will happen. But JS has by far the biggest, most boisterous & complete web ecosystem. By far. And a huge amount of the ecosystem works just as well front end, back end, and thanks to AssemblyScript, both at once (portability: a huge advantage). As for "just me" / "suck"... other people also turn up their noses. But largely these are legacy preconceptions. JS didnt used to have robust serverside stories (altough I did write some JScript a long long time ago...), didnt have fast runtimes, didnt have a package ecosystem, and so yeah JS didnt fit. But it's grown evolved & gotten fast. Much of NodeJS's history stems directly from Ryan Dahl comparing python web framework's performance,... and finding them wanting, thinking he could do better. With a performant async server, with Isaacs developing npm packages, things quikcly took off. Some poeple dont like JS the language. I have less clear ways to refute this, since it's almost entirely ill defined bias & personal opinion: you cant really argue with someome who says "i dont like bananas" & thats about as far as these discussions tend to go. JS ticks all the boxes for a great & capable way to write server side code. It's still the way to write front end code (although wasm Component Model (nee interface-types) is finslly happening & will make other languages much more viable). > when I look at react-dom it's 130kB minified which sounds CRAZY to me As for react-dom, well, it's magically good stuff. It's worth it. Having immediate mode style rendering, having deep deep control over the front end, but not having to swizzle dom: it's a huge accelerant. There's preact & other "lite" takes that work similarly. I suspect react-dom might tree shake & get smaller for many deployments: bundlephobia can mever detect or understand how much code you will end up not shipping. Also, this only really should affect first load & occasional library updates. clapping: it. just. doesnt. matter.

Existenceblinks 4y ago
react-dom is pretty much a sole purpose, there is no subpackage or its form of plugin. So shaking out unused functions isn't doing much since it's supposed to be * imported anyway.

DantesKite 4y ago

There's probably multiple factors at play, but one small factor I'd like to introduce is how there's way more tutorials for learning Javascript than say Rust.

joshxyz 4y ago

Actually the delight of it is most of our developer tools now are powered with go-based and rust-based binaries that speed up our iteration processes. For example, esbuild, typesense, etc.

stuu99 4y ago

d--b 4y ago

You don’t have to like it. I do a lot of data science in C#, and absolutely loathe Python. I am not the only one who thinks that the ubiquity of Python sucks but I am certainly in the minority. I’ve stopped caring.

mm007emko 4y ago
So do I. But ... at home for my own projects I use language and tools I like (Common Lisp, Clojure...) At work I use whatever I get paid for. I recently left Java job in favour of a Python one because they paid me more. You know, Python hackers hacked together something then left and they realized they need software engineers, not hackers. Python is not a bad language (compared to JavaScript). Python interpreter is a piece of shite and the culture and common practicies is what sucks the most. People praise NumPy, Pandas, Flask etc. because they don't know anything else. Anything better. At least they don't have to pay for this.
perfopt 4y ago
I dislike Python too. But I use it because I have to - a lot of the stuff at work is in Python.

nathants 4y ago

everything is fine. i’ve gone full spa[1]. i don’t think i could go back. my starter project is here[2]. backend is go on lambda. frontend is clojurescript with react and mui, compiled down to a single html file with js inlined, and pre-gzipped. lambda zip contains two files: - ./main - ./index.html.gzip the backend returns the index for any route not beginning with /api/. websockets and http ferry information between frontend and backend. s3 and dynamo persist data. ops are easy. sdlc is fast. frontend runs local and instantly reloads. backend reloads in 1s. if you have bad upload bandwidth, do backend builds on an ec2 relay for $5/month! or just tolerate 10-20s backend reloads depending on your bandwidth. sure the index is a bit heavy, but if it’s not annoying to use on a phone over cellular, it’s probably fine. have most react devs seen the regeant[3] interface that clojurescript devs use with react? it’s so simple and hasn’t changed in a decade! i start all my projects this way now, and am so happy. i can’t imagine a better workflow. 1. https://gocljs.nathants.com https://gocljs.nathants.com 2. https://github.com/nathants/new-gocljs https://github.com/nathants/new-gocljs 3. https://reagent-project.github.io/ https://reagent-project.github.io/

aristofun 4y ago

1. Only JS is already in the browsers. 2. JS is simple. These are the big killer features and selling points for it's crazy adoption. But fortunately with the raise of TypeScript, which solved many of JS original traumas and made it team-scalable, it's not that of a big deal. In the end it's not about "trying-to-be-innovation", it's about money. Yes, it may be much faster and more appropriate to run some code on Go or Java. But often the difference in salaries and time to market (see selling points above) can't justify that decision. I personally witnessed the benefits of migrating from Scala to Nodejs in a big company, and I'll definitely vote for Nodejs next time in similar conditions.

MauroIksem 4y ago

Look at .Net Blazor for a non JavaScript solution.

perfopt 4y ago

What did you write your SPA app in if you dont mind my asking. Web apps and "full-stack" is not my area. Based on what I have read online I was under the impression that it is all Javascript and ver had a motivation to learn it. I would love to know how to create a web app - user interface to back end server code - without node.js, React, Angular etc

Existenceblinks 4y ago
All you need is a tiny view lib like lit-html/uhtml, and event dipatcher (DOM element can do that, or use bare EventTarget), now you get a MVC pattern loop; event fired -> state changed (+ optional effect) -> re-render.

nokya 4y ago

Simple: ads and personal data collection. The more developers get convinced they need JavaScript everywhere, the more these companies benefit from accrued data collection opportunities.

phil_kahrl 4y ago

Been doing web development for 25 years, I am currently learning Rust in hope that I can compile to Web Assembly and build SPAs that way. The JavaScript ecosystem is a mess of module systems, type systems, layers upon layers of libraries and build tools and building a web app that is actually maintainable, consistent and extensible is difficult to impossible. We need better tooling than what is currently considered standard.