[HN Gopher] Ask HN: Why the web lately is all about JavaScript?
___________________________________________________________________
Ask HN: Why the web lately is all about JavaScript?
I read 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 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?
Author : Existenceblinks
Score : 73 points
Date : 2022-05-28 10:10 UTC (12 hours ago)
| ale_jacques wrote:
| Yeah, that sucks. So much that there are people building tools to
| avoid that approach. Take a look at these:
|
| - https://htms.org - https://unpoly.com - https://hotwired.dev
| lordofgibbons wrote:
| I think you meant https://htmx.org
|
| Reading over the Hotwired homepage, I honestly thought it was a
| funny parody like http://vanilla-js.com Turns out it's an
| actual framework!
| joshxyz wrote:
| 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.
| throwaway0asd wrote:
| 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.
| rich_sasha wrote:
| Agree 100% though also sadly, I wonder if in practice website
| quality matters. Consumers are used to laggy shitty UIs and
| assume the problem is their 8-month old hardware.
|
| Of course eventually poor products are unusable, but I wonder
| if position on the barely-usable-to-snappy generates much
| revenue differentiation.
| rozenmd wrote:
| > 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 wrote:
| 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 wrote:
| I had seen a lot of devrels meme pre-covid, now they seem to
| come back.
| tomxor wrote:
| > 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.
| KyeRussell wrote:
| I mean, you can't close your eyes and spit anywhere on HN
| without someone chastising someone else for sticking with the
| same company for more than two years. Disposable developer
| culture is perpetuated by all sides.
| justbaker wrote:
| I absolutely hate it, why do that?
| brador wrote:
| Moving can double or triple your paycheck overnight. If
| you're not learning, networking, or growing, fire your
| employer.
| Spivak wrote:
| Right but the reason for that culture is because businesses
| refuse to give competitive raises. I actually tried to stay
| with my last company but after my two year mark I was way
| more valuable than my current salary. I told my manager
| that, they agreed, said they wanted to keep me and asked
| for a number. I said what would have been a 60% raise and
| they literally laughed in my face. So I quit and in a month
| I got a 100% raise. Like it's not like I had some inflated
| ego, over the next 6 months my entire team except for the
| guy on a work visa did the same thing.
| Existenceblinks wrote:
| 340kb is quite impressive for an OS, it seems browser/web has a
| lot of great apis that are underused.
| Cederfjard wrote:
| > Financially that reasoning makes sense but economically it's
| stupid
|
| What's the distinction you're making here? To me it looks like
| you're contradicting yourself, but I'm happy to admit I might
| be ignorant.
| edzillion wrote:
| They mean short term financial gains vs long term economic
| success
| brador wrote:
| The solution is to separate creators from maintainers. You
| don't pay your janitors the same as your architects. The
| way we get there - standardization.
| skrtskrt wrote:
| An interesting thought - it is so much easier to learn to
| contribute good code to an area you're unfamiliar with
| when the codebase is already beautifully designed.
|
| It's a teaching tool in itself. You can essentially hire
| a janitor and make them an architect when everything just
| makes sense already and guides them in the right
| direction.
| crummy wrote:
| 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/
| IshKebab wrote:
| 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.
| TacticalCoder wrote:
| > 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 wrote:
| 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.
| lousken wrote:
| 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.
| mbirth wrote:
| 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.
| rektide wrote:
| > _i feel like many people completely forgot about how simple
| and fast apps can be_
|
| Most web apps dont have pretenses of being simple. They want to
| use tools that have room for growth, that have deep
| capabilities.
|
| And they want to use the really good tools & libraries &
| technologies that will be used on more complex efforts.
| Specializing in being lightweight, narrowing the scope of your
| skills & capabilities is less attractive than getting good at
| something that works & ideally will also be fast in all cases.
|
| I think it's good to reflect nack to 2014, when React was
| coming out, & think of what rapid development looked like. Hand
| manipulating dom trees, course grained re-rendering by setting
| el.innerHTML,... React and the virtual dom were a huge huge
| performance win. Some up-front load price, but an amazing boon
| to rapid rapid developmemt, grossly reducing the scope of
| concerns one had to think about in webdev, & massively speeding
| up rendering/updates at the same time.
|
| React isnt the smallest but holy shit it propelled us into a
| massively massively faster world. Where development is just so
| stinking much faster/easier, where there are so mamy less bugs
| & memory leaks. Thanks react.
|
| So why focus on a niche, special purpose skill set? Why go back
| to hard mode? Is a 30kB preact bundle actually any kind of
| problem? Is a 100kB react bundle really a problem?
|
| > _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 javascript we can often run the same code on the
| backend, & store & cache our documents or if it's light weight
| enough just render it (with already started/initialized
| workers). Hence: server side rendering (ssr).
|
| SSR is very prevalent, actively supported out of the box in
| newer JS libraries/frameworks like Next. React has had support
| for "hydrating" a SSR page on the front end for a while, but
| required some investmemt & didnt just work out of the box.
|
| Im very mixed here, about performance in general. On the one
| hand I want us chasing technical excellence, being fast. But I
| also see two things, one, that waiting for a second isnt the
| worst. Second, a huge amount of the slowness is ads and
| trackers, is shitty other people prpolems that businesses just
| accept, and developers at a company dont get much say in. Why
| would we spend iterations dropping load times from 2s to 0.4s
| when the damned trackers are still gonna make the site take 5s
| to load anyways?
| Existenceblinks wrote:
| Yeah, an html attribute on <head> or <body> for not having full
| page reload would make a big impact.
| linkdd wrote:
| 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
| Existenceblinks wrote:
| Sorry, I mean it should be in html spec.
| cutler wrote:
| I find Hotwire/Turbo/Stimulus in Rails to be a perfect low-JS
| approach.
| john_the_writer wrote:
| 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 wrote:
| Phoenix as well with LiveController. It's impressive what can
| be built with minimal JS while being pretty responsive and
| snappy.
| yen223 wrote:
| 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.
| lewisjoe wrote:
| 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
| quickthrower2 wrote:
| 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 wrote:
| 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.
| recursivedoubts wrote:
| 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/
|
| 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/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.
| mouzogu wrote:
| 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.
| oxff wrote:
| Economical reasons come into play with software engineering.
| Existenceblinks wrote:
| Does that mean abstraction leak from inside out? (No, not
| outside in)
| speedgoose wrote:
| 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_Interne...
| 6510 wrote:
| You not just count the js framework. All parts of a website
| contribute to the bloat. Things get exponentially slower for
| each thing added.
|
| I will for example "excessively" test how many images in what
| resolution I can get away with. Is my json to big? Can I use a
| custom font? Do I need to start the "infinite" scrolling
| fiasco? In what order are things loaded? Are we requesting a
| html document that when parsed has us request a js file? Is its
| execution delayed by the dom state? Then it parses out html?
| And then that html requests media that loads lazy?
|
| If I would find myself there the 130 kb (and its overhead)
| would persistently bother me. When I get to it it will get
| ripped out and replaced with inline vanilla js.
|
| It's not just that I want my application to be snappy and
| appear instantly. I also want to see instant results when
| testing it. There is no build time. It doesn't exist.
| xigoi wrote:
| Are you implying that it's okay for a web app to be unusable by
| people in remote areas unless it's specifically designed for
| them?
| Existenceblinks wrote:
| 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.
| randomtwiddler wrote:
| 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.
| speedgoose wrote:
| Yes no one cares about the JavaScript bundle size until it
| becomes a problem.
| 6510 wrote:
| I prefer not to create problems for myself.
| towaway15463 wrote:
| 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 wrote:
| Literally break the mantra "the right tools for the job". Now
| it's everything is a nail.
| dismalpedigree wrote:
| Nailed it!
| Spooky23 wrote:
| 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!
| FlyingAvatar wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Existenceblinks wrote:
| The point is javascript-only obsession/perspective.
| Javascript should be fine as well as other languages.
| throwaway0x7E6 wrote:
| 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 wrote:
| 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
| spiffytech wrote:
| 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.
| neoberg wrote:
| 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 wrote:
| Solid.js is very small (sub 7-8kB IIRC), very similar to React.
| neoberg wrote:
| 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 wrote:
| That's the only aspect of complaining. Size is one thing,
| it's also javascript for everything.
| fuzzy2 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| We could do client-client
| [deleted]
| austinjp wrote:
| 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.)
| FrenchDevRemote wrote:
| >(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.
|
| No. This is cached if the devs aren't incompetent, the lion's
| share of information transfer is video streaming, not large JS
| files.
| seydor wrote:
| > This is particularly the case in rural locations and
| developing nations.
|
| Also in a conference / the train / the beach / driving / any
| crowded place / in space
| Existenceblinks wrote:
| Yep, anything else works, they are mostly sub 10kB view lib.
| It's fascinating that the current situation is widely
| acceptable.
| cutler wrote:
| Solid.js may change all this.
| eyelidlessness wrote:
| 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.
| rektide wrote:
| > _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._
| seydor wrote:
| 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 wrote:
| 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 wrote:
| The kinds of devs who don't regularly learn new languages are
| generally the ones you don't want to hire.
| jrockway wrote:
| 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.
| eurasiantiger wrote:
| Never roll your own GraphQL server on core libraries. There are
| existing implementations with good practices and debugging
| tools.
| Existenceblinks wrote:
| The tricky part of edge compute though is write operation and
| where the data store is.
| lawn wrote:
| I personally think the future is adding live functionality to the
| server, like how Phoenix does with LiveView.
| chrismorgan wrote:
| 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 wrote:
| 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/
|
| [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.
| htm...
| chrismorgan wrote:
| The problem is that LiveView forces synchronous operation,
| whereas a significant fraction of things that would require
| a server trip anyway could actually be done asynchronously
| --that is, as far as the UI is concerned, they actually
| _don't_ require a server trip; not immediately, anyway, and
| the UI should only care about the immediate.
|
| When you control server interactions on the client side,
| you can do things like optimistic editing, where the UI
| assumes the action will succeed and then does it in the
| background, and then handles the exceptional case where
| something goes wrong, most likely by returning you to a
| form; or things like queuing actions up when there's no
| internet connection, and performing them when you get a
| connection again.
|
| I want to emphasise again the importance of latency. I live
| in Australia. Most of the web is _much_ slower in Australia
| than it is in the USA, not because of bandwidth, but
| because of _latency_.
|
| The LiveView approach is _convenient_ , but it's
| technically not a good solution for most applications. It's
| excellent for things like chat systems where being bound to
| synchronous operation and requiring a network connection to
| do things isn't an issue, but I honestly don't think it's
| the best solution (technically, again; socially it may be)
| for much else.
| Existenceblinks wrote:
| I used Liveview before (on very early version), now I use
| PhoenixChannel and javascript, it's great balance.
| nagasadhu wrote:
| Same here. Mixing ui and data logic layer was not pretty.
| Alpine js didn't cut it for me.
| Etheryte wrote:
| 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 wrote:
| 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.
| OhNoNotAgain_99 wrote:
| 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.
| DantesKite wrote:
| 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.
| throwaway4good wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| loads in half a minute, while https://nitter.net/POTUS loads
| almost instantly. Despite both being the exact same content!
| ericfrazier wrote:
| 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 wrote:
| 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 wrote:
| You think? FastComments doesn't use any DOM manipulation
| frameworks.
___________________________________________________________________
(page generated 2022-05-28 23:02 UTC)