[HN Gopher] New React docs pretend SPAs don't exist anymore
___________________________________________________________________
New React docs pretend SPAs don't exist anymore
Author : matijash
Score : 170 points
Date : 2023-03-17 19:41 UTC (2 days ago)
(HTM) web link (wasp-lang.dev)
(TXT) w3m dump (wasp-lang.dev)
| ofrzeta wrote:
| Those marketing pieces are becoming a bit tedious to decypher for
| me. The real message is not something about React SPAs but
| something about Wasp? Just tell me this thing about Wasp and
| don't distract me with something about React.
| fabian2k wrote:
| As far as I understand you can use these frameworks to write SPAs
| as well. I have no idea how well supported that use case is in
| the end.
|
| I find the idea that you want to handle data fetching and routing
| in a framework to be reasonably convincing. There are advantages
| here, and it's easy to get into a bit of a mess if you just fetch
| data in each component.
|
| The part that has stopped me from looking at the frameworks until
| now is that they add a lot of parts I don't need, and the
| documentation seems to be focused on the SSR part. And then there
| are React server side components, which is another new concept I
| need to understand. Maybe the frameworks are a good fit for my
| SPA use cases, but it'll take quite a bit of time to find out if
| that is true.
| jameshart wrote:
| Basically if you do a static export from next.js and ignore
| routing, you get a react SPA.
|
| You can do the same in Gatsby, but it's probably a waste of
| time.
|
| But...
|
| With an index.html file containing a
| createRoot(document.getElementById('root')).render(<MyApp/>)
| call, and parcel or vite or webpack, you can produce much the
| same thing.
|
| Possible that next.js will give you easier access to some more
| interesting ways to split your JS bundle up - but also possible
| it will fight you if you continue to insist on not taking
| advantage of SSR.
| leerob wrote:
| If you roll your own with a bundler, you will also need to
| integrate a router. Next.js is providing a routing layer for
| you. If you want to stick with a static/SPA the entire time,
| that's fine. You don't have to use SSR unless you need it.
|
| https://nextjs.org/docs/advanced-features/static-html-export
| synergy20 wrote:
| sveltekit is the same, ssr first, i am so sad react now becomes
| ssr first too, i am forced back to vue,which still has a CSR SPA
| first, add ssr if you need it approach.
|
| no i dont need ssr at all, internal tools,dashboards,embedded
| devices,etc etc have nothing to do with ssr,nothing at all
| weird-eye-issue wrote:
| You can use NextJS to build a SPA so the entire premise is
| invalid.
| Xeoncross wrote:
| I'm still waiting for preact.js + htmx.org mashup. It probably
| exists somewhere, maybe
| https://docs.astro.build/en/concepts/islands/ or something.
|
| I just want a quick way to throw some react hooks or web
| components into a dom element using a library that is less than
| 1,000 lines of code.
| BiteCode_dev wrote:
| Why do I hear so much about htmx and so little about unpolly,
| which seems everything htmx promise but with additional high
| level primitives for the common task?
| omnimus wrote:
| Unpoly dev is german nobody cares about abd doesnt go on
| podcasts vs htmx author is american that does marketing well.
| Same goes for alpine js where the author is "famous" dev.
|
| Pretty typical with open source projects tbh. Many of them
| win thanks to marketing more than anything else.
| diordiderot wrote:
| Also Htmx got picked up early by the Django community
| BiteCode_dev wrote:
| Don't why you have been downvoted, while there are famous
| dev outside of the US, american identity and marketting
| does sell better than the german one.
| omnimus wrote:
| Its also easier to be comfortable on a english podcast
| when you are a native speaker.
|
| Plus i think US devs understand how important marketing
| is more than anybody else.
| omnimus wrote:
| Sorry but thats not a good combo.
|
| htmx is literally html extension. it is aimed at adding
| interaction to static html. Preact/react are completely
| opposite approach to that.
| Xeoncross wrote:
| I probably didn't explain it well enough.
|
| Preact is the tiny alternative to React (I still think preact
| could be smaller if they only focused on hooks).
|
| I htmx is too bloated, while it's much smaller than the React
| codebase - I want the tiny, <1k loc alternative that
| literally just makes working forms and href links into
| dynamic fetch() responses and maybe adds additional support
| for auto-refresh from websockets or SSE.
| dmix wrote:
| A lot of people still mix jQuery and React in the same parent
| project. Mostly just via legacy support when using existing
| serverside frameworks but still sometimes having the fallback
| easy DOM/event stuff is just easier when you need to get it
| done (keeping the HTML/views isolated from each other of
| course so you don't mix concepts). It doesn't sound pretty
| but they can serve dual purposes. I don't know enough about
| HTMX on how it would work implementation wise though and what
| type of setup.
| omnimus wrote:
| I am sure you can do something with it...
|
| But htmx is all about replacing server rendered html with
| server rendered html partials. I would like to see what
| reacts vdom does when you keep ploping some partials into
| DOM it thinks it controls.
| dmix wrote:
| Yeah they'd have to be isolated from each other if that's
| the case. Which would defeat the value if it's a small
| project starting from scratch with a limited scope
| frontend-wise (which htmx typically implies whenever I've
| seen it used or mentioned).
| NerdiOrg wrote:
| What is the difference between html partials and scoped
| components?
| bryik wrote:
| I don't think that's a fair characterization of the "Start a New
| React Project" page [0]. Next.js is the first option listed and
| is described as a way to "create React apps of any size--from a
| mostly static blog to a complex dynamic application."
|
| This reads to me like "Next.js can do SPAs (like CRA) plus static
| sites and SSR". Next.js' site even says "The core of Next.js has
| been designed to enable starting as a static site (or _Single-
| Page Application_ )" [1].
|
| 0 - https://react.dev/learn/start-a-new-react-project
|
| 1 - https://nextjs.org/docs/advanced-features/static-html-export
| leerob wrote:
| Your understanding is correct - Next.js can do static sites,
| SPAs, SSR - all of them.
|
| We (just today) updated the Next.js docs linked based on
| feedback around this to make it more clear. Hopefully this
| helps, let me know if you have other feedback.
| jameshart wrote:
| "The core of Next.js has been designed to enable starting as a
| static site" is a little contradicted by the fact static export
| is considered an 'advanced feature' though.
|
| That said, I'm not sure why running `next export` is considered
| 'advanced'.
| leerob wrote:
| I'd say this is documentation organization "debt" - there's a
| bunch of "advanced" features that aren't that advanced. We're
| aware and fixing with the new docs ->
| https://beta.nextjs.org/
| klysm wrote:
| The part about this that bothers me is it not being
| documented well is in vercels financial interest
| freedomben wrote:
| This is what has made me hesitant to really invest deeply
| in Next.js. It's just too familiar where some open source
| project starts. Later it attempts to monetize. Some
| feature in open source makes it so new monetization thing
| (usually cloud functionality) isn't needed, so those
| feature(s) get downplayed, neglected, and eventually
| deprecated, often with self-fulfilled
| prophecy/declaration of "nobody is using those" (because
| they were engineered that way, but that inconvenient part
| is never mentioned and rarely acknowledged). It's one
| thing not to invest in unprofitable features (that's
| understandable for a for-profit company), but making them
| difficult or more obscure to use is often a part of this
| pattern.
|
| I'm not saying Next.js is doing that with static export,
| but I'm not sure they aren't either. It fits the pattern
| too well. I'm still suspicious about how the Image
| implementation (which nearly every website needs) breaks
| `export` and the only solution is "roll your own image
| handler." I'm not sure if that fits into the
| understandable lack off investment or the intentional
| difficult/obscure.
| leerob wrote:
| We've made quite a few improvements to the static export
| with the new App Router, including support Server
| Components, Route Handlers, i18n routes, and more.
| Definitely still being invested in. My comment about
| documentation debt is that the entire information
| architecture of the Next.js docs needed some work. It's
| being fixed and will be stable soon.
|
| You can read more about how to use Image Optimization
| with a static export in the new docs:
| https://beta.nextjs.org/docs/configuring/static-export.
| There's a full example there with Cloudinary, but you
| could use any service you want.
| darepublic wrote:
| I only use next.js in the static context.
| eric-burel wrote:
| next export, the feature that produces a "true" SPA out of a
| Next.js app, has been under-developed for along time. However
| the very newest developments in Next 13 seems to fix that,
| making Next.js truly versatile
| leerob wrote:
| New docs are a work-in-progress here:
| https://beta.nextjs.org/docs/configuring/static-export
| synergy20 wrote:
| Vercel's next.js and sveltekit are both SSR first because
| that's its business needs, which has nothing to do with
| mine(CSR only case), and Vercel is actively pushing the SSR-
| can-do-it-all in the open source space, I feel it is very much
| short-sighted.
|
| Just use vuejs which is the only one truly never forces SSR on
| you if you do not want to have anything to do with it.
| chambers wrote:
| Speaking as an engineering manager, vercel's approach seems
| to cater to the last market where overengineering and
| complexity were status symbols that middle management was
| happy to pay for. When the headcount was free, there weren't
| many questions from upper management why basic UIs required
| so much heavy lifting by (overly) experienced engineers.
|
| In the new market, there will be much more scrutiny on costs
| and the complexity that creates it. The prospect of hiring a
| "React Engineer" with 7+ years of experience to build a
| cookie cutter UI, will be just as questionable as forcing the
| front end and backend to use the same technology and
| framework governed by one single vendor.
|
| I predict vercel will have a rough time.
| Rauchg wrote:
| Interestingly, I have the exact opposite bet: "SPAs were a
| zero interest rate phenomenon". Putting the burden of
| compute on clients, and shipping slower apps for the sake
| of DX and convenience. Customer-first wins.
|
| Looking forward to see how this plays out.
| zarzavat wrote:
| SPAs are faster than SSR because you can choose whether
| to incur network latency or not.
|
| For example, let's consider a site with two pages. In the
| SSR case, if I click the link to page 2, then I have to
| wait a whole network roundtrip for the page to appear.
|
| In the SPA case you can decide when you want to load the
| content for page 2: with page 1 (if it's a small amount
| of content), if the user scrolls to a certain point, ...
| it's completely up to you. You can cleverly hide the
| latency so that when the user does navigate to page 2,
| it's instant.
| JeremyBanks wrote:
| [dead]
| pjmlp wrote:
| Nope, you do a bit of DHTML to update the only section
| that matters.
| tqkxzugoaupvwqr wrote:
| MPAs can do the same trick. Use JavaScript to add a <link
| rel=prefetch> element to prefetch a URL. Or just serve
| your server-side rendered page with this element included
| to prefetch the next page. When the user navigates to the
| next page, it's instantly shown.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Attributes...
| Rauchg wrote:
| I actually strongly advocate for: SSR and server is the
| absolute best default[1], and Next.js gives you tremendous
| flexibility on where to place your compute[2], including
| skipping SSR altogether[3], with the best-in-class static
| export that can actually at least put _some_ content in your
| HTML instead of a blank page[4]
|
| [1] https://rauchg.com/2014/7-principles-of-rich-web-
| application...
|
| [2] https://twitter.com/rauchg/status/1637136013083684864
|
| [3]
| https://twitter.com/timneutkens/status/1636693508223270912
|
| [4]
| https://twitter.com/dan_abramov/status/1636827365677383700
| randomopining wrote:
| Isn't it going to get to a point where servers and avg
| connections are so fast that server side rendering makes sense
| again?
| klysm wrote:
| Probably not because applications will bloat to take up the
| bandwidth
| dwaltrip wrote:
| Interesting that CRA isn't mentioned anymore.
|
| Someone opened an issue to discuss this:
|
| https://github.com/facebook/create-react-app/issues/13072
| throw_m239339 wrote:
| Starting a "new react project" should be basically creating an
| HTML file, and adding a script tag linking to React the JS
| library. Why are these developers always trying to obfuscate
| everything with tons and tons of layers of indirection all the
| time? You don't need to "bundle" anything and certainly not use
| some server just to add Javascript to a page (unless it's a
| matter of CSP of course) and you should certainly not have to
| rely on nodejs or cli tool X,Y,Z...
|
| Somehow the JS/Node dev community managed to re-invent JEE web
| profile, and is very close to re-invent Glassfish as well at that
| point, but worse because it didn't learn anything from Java
| enterprise... this madness needs to stop.
| jameshart wrote:
| You can actually still do this, and it is kind of a shame it's
| not documented on react.dev
|
| You need to pull in react, plus Babel standalone, and then you
| can use <script type="text/jsx"> tags, which means you can
| bootstrap react components onto your page. But you are going to
| be basically running a compiler in your user's web browser.
| That's fine if you want to run that way, but Babel has docs
| that explain why you probably shouldn't
| (https://babeljs.io/docs/babel-standalone#when-not-to-use-
| bab...).
|
| All you need is these two scripts: <script
| crossorigin
| src="https://unpkg.com/@babel/standalone/babel.js"></script>
| <script crossorigin src="https://unpkg.com/react@18/umd/react.d
| evelopment.js"></script>
|
| [Edit - also need ReactDOM, sorry: <script
| crossorigin src="https://unpkg.com/react-dom@18/umd/react-
| dom.development.js"></script>
|
| ]
|
| I think it would help if more react tutorials started from
| here, because it shows _why_ you need a build process.
|
| Here, as a JSFiddle: the React 'Hello World' they don't want
| you to see: https://jsfiddle.net/smLa1bco/
| rk06 wrote:
| Because react is not developed with that usecase in mind. And
| it is not recommended for production anyway.
|
| If you really need to use html with script tag, go with
| Vue/alpine
| super256 wrote:
| I honestly find this way more intuitive than JEE profiles.
|
| It just makes sense when you take react as what it is: a
| library. Now, if you want amenities like a router you need to
| build it yourself or use something existing. 99.9% of people
| want this, so why not point them into the right direction?
| KRAKRISMOTT wrote:
| Because it's slow. Hard to do treeshaking if everything is in
| random dependencies that need to be downloaded at runtime. You
| also get a flash of white if you don't pre-render your sites.
| alex_sf wrote:
| Because they _need_ cool tool A, utility library B, theme C,
| and then helper library D because B doesn't work quite right.
| leros wrote:
| I just want to say, as a developer that just wants to get stuff
| done, I'm so annoyed by frameworks needing a meta framework, etc,
| etc. I want something as simple as CRA to be enough.
| super256 wrote:
| React is a library, not a framework, so you usually need
| something on top.
| jameshart wrote:
| CRA has never been merely 'enough'. CRA started at 'too much'
| and started adding features from there.
| andrewstuart wrote:
| I don't want server side react.
|
| It's disappointing to me they've gone so hard on server side.
|
| It feels like Facebook use it server side so they've lost
| interest in being purely client side.
| NerdiOrg wrote:
| Nobody is forcing you to use all the capabilities. You can
| still use it for client-side only if you want, but the
| efficiency of having both is perfect for me personally and our
| company.
| synergy20 wrote:
| frontend is already complex enough, there are many use cases
| do not need SSR at all, React used to be SPA first, now is
| SSR first(just like svelte), which means lots of unnecessary
| stuff to understand for SPA programmers. I came from vue-
| svelte-react, now Vue is the only one still does true SPA(SSR
| is opt-in), so, I am back to Vue and hope it won't change to
| SSR-first like the rest.
|
| React is owned by Meta which cares more about SSR, similar to
| Svelte. Vue is not owned by any single company, that seems
| like a huge huge plus now.
| nextaccountic wrote:
| > now Vue is the only one still does true SPA(SSR is opt-
| in),
|
| With next.js, SSR is opt-in too
| MartijnHols wrote:
| For most React apps, SSG is by far the best option. With
| Next.js it's easy to do and takes less effort than a client-
| side app with a separate backend. SSR React was a PITA
| initially 2-3 years ago, but it, libraries and the frameworks
| have come a long way.
| AgentME wrote:
| This comment thread is a little funny because every single HN
| thread outside of this one rants super aggressively about
| webpages that don't show any content before JS loads, but this
| thread has managed to collect the opposite group together for
| once because React's docs have updated to stop actively
| recommending tools that force that problem to happen.
| timcobb wrote:
| This is the most interesting observation here
| notfed wrote:
| It's almost as if the community has a diversity of opinions.
| never_inline wrote:
| But only few comments contain nuance that I come to this site
| to read.
| seydor wrote:
| my observation is that the community (here) has converging
| opinions, but the groupthink changes over time. At some point
| it seemed SPA was all the rage, now there is a reactionary
| wave
| hamilyon2 wrote:
| This is not unusual for HN. I noticed that the bashing and
| praising Unix come in similar proportions.
|
| If the publication criticises Unix, it's comment section lokks
| like Unix fans have the loudest voice. The other day,
| commenting on other publication, virtues of Unix have been
| forgotten, and the comment thread praises some alternative.
| Waterluvian wrote:
| I noticed that too. It's a humble reminder to us that Hacker
| News isn't one entity. It's many people with different
| opinions, taking turns deciding when they want to be heard.
| tzs wrote:
| I'd like to see a browser extension or something similar for
| HN that would let one add tags to user names, and display
| those tags next to user names on comments and submissions.
|
| I often see someone take a pro-X position in some discussion
| and have a vague recollection that I've seen them take an
| anti-X position in some other discussion but it would be too
| much work to go digging through their comment history to
| check that.
|
| For example, people who argue we need to ban cars in cities
| and suburbs because they are dangerous for kids playing in
| the street but who argue against every proposal to protect
| kids from online dangers saying that it should entirely be
| the parent's responsibility to control where their kids go.
|
| Or people whose strong criticisms of most police procedure go
| completely out the window when the discussion involves some
| kind of crime that they personally have been a victim of and
| there they argue for more surveillance and easier warrant
| requirements.
|
| My guess is that a lot of cases it is just good old fashioned
| self-centered thinking. But some probably have some good
| justification for the seeming contradiction which could lead
| to some interesting and insightful discussion.
| doubled112 wrote:
| It would be fun to see if some people change over time from
| one to the other, or flip flop back and forth.
|
| I'm sure there are some of my opinions do both. Some topics
| are complicated.
| arthurcolle wrote:
| Yeah there was something like this for reddit. Maybe part
| of Reddit Enhancement Suite? Probably would be relatively
| easy to port that functionality for HN, or other sites with
| users.
| [deleted]
| edgyquant wrote:
| It can be true that SPAs are overused and that people think of
| react as an SPA framework.
| say_it_as_it_is wrote:
| >Next.js is a great framework, and its rise in popularity is due
| in a large part to the return of SEO optimization via Server-
| Side-Rendering (SSR) within the collective developer conscience.
|
| I stopped reading here because the article may have been made by
| ChatGPT
| d_runs_far wrote:
| Here's my realm: We have a react based "framework" that in the
| end is zipped up and delivered as a SCORM package to be embedded
| in a Learning Management System. We use React Router to manage
| navigation.
|
| After a quick scan of the Next docs, all references to routing
| seem to tie back to server side which is a non starter, as the
| SCORM is standalone HTML/CSS/JS/Media - that we happen to
| embellish at run time with some api calls.
|
| This is a case where the pure SPA with no server side is the only
| way to go; seems like a real pain to go against the default state
| of Next. Am I wrong and am just missing something? Again, been
| occasionally looking at next and the like over the past while,
| but never had time to really dig into into it.
| robertoandred wrote:
| Next doesn't need a server, you can export to a fully static
| package. The dynamic server-side features obviously won't
| apply, but it otherwise works great.
| chrisacky wrote:
| Do you have an example of the SCORM? I'd love to see how you've
| structured it? (What's your LMS that you use?)
| BiteCode_dev wrote:
| So after graphql, micro services, nosql and serverless, the SPA +
| "libs not framework" crowd join the "woooops!" club.
|
| Ignoring the noise is really becoming a key skill to survive as a
| programmer.
| robertoandred wrote:
| I don't think you understand what any of those terms mean.
| eurasiantiger wrote:
| What are you on about? GraphQL is absolutely essential in
| enterprise systems.
| roflyear wrote:
| In my experience it's the poorly implemented abstractions on
| top of your ORM of choice that make graphql a bad time. It
| itself is really a great way to do things imo
| eurasiantiger wrote:
| Yes, exactly. The typical issue is devs not grokking the
| mental model of GraphQL and instead just creating more and
| more extra queries, essentially resolving data piece by
| piece in the frontend instead of leveraging GraphQL types
| and adding types, fields and field resolvers as needed so
| that the frontend can do one query to get all the data it
| needs.
|
| No wonder it feels like a clunky extra glue layer if it's
| being used as one.
| claytongulick wrote:
| Some of us learned these lessons in the SOAP/WSDL/XML-RPC
| days, and learned to embrace the principles of REST to a
| avoid exactly those issues.
|
| I looked at graphql and saw a return to the horror of
| DoSomethingBecauseItsMondayAndDueTomorrow() type API
| methods.
|
| Hundreds or thousands of them that accumulate like cruft
| over time, and no one can delete anything because you
| have no idea what it'll break.
|
| I stick with well designed and well planned REST APIs.
|
| It's not a panacea, but it helps.
| pjmlp wrote:
| Did we? Hello gRPC, Web sockets and language specific
| SDKs for REST APIs, as no one actually uses REST as
| designed.
| roflyear wrote:
| > and no one can delete anything because you have no idea
| what it'll break.
|
| This is a problem with GraphQL, but you can monitor if
| anyone is requesting that data.
|
| Major benefit with GraphQL is you can ask for the data
| you need and just the data you need. So you don't have 30
| different API endpoints that really return the same data,
| just smaller chucks. Or maybe you just need the IDs...
| etc.
|
| GraphQL is also efficient here, not executing the code
| for the data you don't need - which is really useful.
|
| It depends if you're in that situation or not, or what
| parts of your domain are in those situations.
|
| I don't think "GraphQL everywhere" is sane.
| claytongulick wrote:
| > Major benefit with GraphQL is you can ask for the data
| you need and just the data you need. So you don't have 30
| different API endpoints that really return the same data,
| just smaller chucks. Or maybe you just need the IDs...
| etc.
|
| Most sane REST-like implementations also support this,
| typically with query string modifiers like a "fields"
| param or similar.
|
| A lot of them also support deep relationships this way
| too.
|
| For example, the Directus REST API is completely feature
| compatible with the GraphQL API.
| dmix wrote:
| SPAs, microservices, nosql (Redis), and serverless are all
| still alive and well, they just aren't a hammer for all
| problems like (some) people treated them originally. Nerds
| getting overexcited about new tech is an old story and it will
| continue to happen indefinitely as much as we like to smug post
| about it.
|
| IDK about GraphQL since I've not used it but I've read lots of
| stuff recently about frameworks/ORMs working to better support
| this type of thing more directly/natively.
| BiteCode_dev wrote:
| That's exactly my point.
| dmix wrote:
| Your comment sounds a bit dismissive though. They all
| provide plenty value individually. A lot of this stuff
| needs to be used IRL for the community to understand the
| limits and there will always be junior devs and cowboys
| willing to risk it.
|
| Plus not all of it is merely overexcitement/immaturity
| either, small companies and small dev teams often try to
| keep their toolsets small and eventually end up
| pigeonholing stuff into tech that doesn't fit, until they
| get time/resources to do it properly. Some things are more
| obvious in retrospect.
|
| The vast majority of the software world is still pretty
| conservative when you look beyond HN and Twitter.
| simplotek wrote:
| > That's exactly my point.
|
| In your own, exactly what point did you tried to make?
| Complaining that x and y technology users joined the
| "whoops" crowd when those technologies are in fact well
| established and proved to be effective if not nearly
| optimal in some applications, what do you perceive as
| "whoops"?
|
| Frankly, it didn't seemed you had a point to make other
| than parroting cliches.
| roflyear wrote:
| Graphql is only awful once you introduce abstractions. By
| itself it's really a great idea and works well.
| jameshart wrote:
| Being too eager to dismiss a technology and move on is just as
| much of a bandwagon-jump as being too eager to adopt it in the
| first place.
|
| The Gartner Hype Cycle[1] has both a 'peak of inflated
| expectations' and a 'trough of disillusionment'.
|
| The thing a lot of tech cynics fail to spot is that _both of
| them are wrong about the long term value of the technology_.
|
| The 'plateau of productivity' awaits, where graphql, nosql,
| serverless, and SPAs will join every other technology, finding
| productive use in their appropriate niche.
|
| [1] https://en.wikipedia.org/wiki/Gartner_hype_cycle
| datavirtue wrote:
| I have to agree. I ignored tailwindcss for far too long. Pry
| it from my cold dead fingers.
| 6510 wrote:
| > The 'plateau of productivity' awaits, where graphql, nosql,
| serverless, and SPAs will join every other technology,
| finding productive use in their appropriate niche.
|
| I keep thinking of the tower of babel.
|
| > God was concerned that humans had blasphemed by building
| the tower to avoid a second flood so God brought into
| existence multiple languages. Thus, humans were divided into
| linguistic groups, unable to understand one another.
|
| see? Now you can be wrong with the rest of us :)
| alex_sf wrote:
| Honestly, the signal is just to avoid whatever full-time JS
| developers are getting into.
| mock-possum wrote:
| Get ready to have a lot of trouble finding work as a js dev
| if you're not into whatever full time js devs are getting
| into.
| alex_sf wrote:
| I'm totally fine with that.
| datavirtue wrote:
| Winner!
| MartijnHols wrote:
| The signal is to avoid new technologies with marketing
| engines behind them for at least a few years. And anyone who
| is gullible enough to believe them, which are more likely the
| new people learning to code and yelling about the new shiny
| libraries they found than full time developers that are
| actually productive rather than bored.
| colechristensen wrote:
| What should I use to create a new SPA for a new project these
| days?
| CSDude wrote:
| All our application lives behind an authentication except login
| pages. I still cannot grasp how would I use Nextjs in only SPA
| mode. Not everything needs to be SSR, I don't want to spare
| resources, just want to deploy it to S3, put cloudfront infront
| of it, let 404 requests return index.html and I can use the URLs
| without #.
|
| SSR should not be a must the docs should reflect that. There is
| no way I'm paying Vercel 20$ per user for our simple use case or
| I'm hosting a VM to render pages. I don't care about the
| improvements SSR would bring in the price of cost, deployment
| complexity, or any other complexity. Affecting React docs like
| this to push for SSR does not feel safe to me. I'm happy with my
| Vite based React TS project.
| synergy20 wrote:
| cant agree more, vercel likes ssr,and it now owns nextjs and
| svelte,then it forces ssr on the community,it is basically
| leveraging open source for its own business needs solely, which
| will not last long if they keep doing this down the road.
| disappointed.
| leerob wrote:
| You can use Next.js in SPA mode - you don't have to use SSR.
| Here are the current docs (https://nextjs.org/docs/advanced-
| features/static-html-export) and we're working on an improved
| version for the new App Router
| (https://beta.nextjs.org/docs/configuring/static-export)
| based on community feedback. With this export, can you deploy
| anywhere you prefer.
| dzogchen wrote:
| If you want the control and low overhead of Vite but don't want
| to implement everything a framework gives you, vite-plugin-ssr
| might be interesting for you.
|
| It is basically Next.js as a do-one-thing-well Vite plugin (its
| slogan).
|
| https://vite-plugin-ssr.com/
| dmix wrote:
| That looks perfect for what I was looking for on a side
| project. I hope they don't end up bloating up over the years
| via endless user demands and turn into another Next.js. More
| like a Sinatra vs Rails.
| floydnoel wrote:
| Thanks for sharing this! Comments like yours are why I love HN
| comments. Despite all the arguments and negativity, I managed
| to find a useful comment which is directly applicable to my
| current needs!
|
| I have been trying out Vite on my latest small project and was
| wondering if I should enable pre-rendering or perhaps alter the
| build process. I have markdown files which form some pages,
| currently they are imported and this causes the *.md files to
| be fetched when navigating to that page. It's mostly fine but
| it wouldn't be the best for blog SEO. So thanks again for
| giving me another option to look at, it may be just the right
| thing!
| moritzwarhier wrote:
| Yes, for apps that are not hosted publicly or that are not mainly
| "websites" - what's wrong with just using react + react-router?
| So I agree that this is an oversight.
|
| Also, there surely are plenty of non-public web-apps in the B2B
| segment which run in the browser behind a login or on private
| networks, where SSR is basically unneeded (also, electron and the
| like)?
|
| But:
|
| for a public web site or commercial web app, I find the take from
| the first screenshot pretty nuanced.
|
| It is easy to underestimate the complexity of building your own
| React SSR- or SSG-framework.
|
| I recently tried out vite-plugin-ssr, which kind of does that, in
| a way that's agnostic to the frontend framework/library.
|
| Can recommend it for people who want neither SPA without SSR nor
| one of the established React frameworks.
|
| But for people who want to build a full, public-facing website
| with SSR (which is kind of a requirement for SEO), with minimal
| friction, I think the recommendation from the docs is absolutely
| correct, no?
|
| Plain react for single components in otherwise non-React website,
| full-stack framework if you build the whole site/app in React.
| ralusek wrote:
| There are a myriad of reasons why I prefer SPA to server rendered
| content for most applications. The main exception is if I have a
| public facing, unauthenticated application that I need indexed,
| I'll go for SSR.
|
| Off the top of my head, here are benefits to SPA:
|
| - I can just serve a few static files from a CDN. Every user gets
| the same client.
|
| - Most requests made by the application are actually smaller. I'm
| just loading the data I need, rather than the data, markup and
| styling.
|
| - It's an actual client application talking to a data API. It's
| the same API the rest of my client applications are talking to,
| be it a mobile API, native, CLI, etc.
|
| - It's a much easier mental model. Interactivity without having
| to give consideration to whether or not it will disrupt whether
| it can be rendered. I build my application like a realtime
| application and just make requests for the data I need when I
| need it
|
| - I don't have to think about exposing backend secrets, or trying
| to do things I'm mistakenly assuming to necessarily run in one
| environment or the other
|
| - I can be much more explicit about loading and caching data when
| I would like to
|
| Even most of the cons of a SPA can be ameliorated. The biggest
| con is a larger up front load, but that can be mitigated by code
| splitting and lazy loading. The fact that it's a handful of
| static files means that the application is basically cached, too.
| And SPAs are for applications, not websites. Most people using
| SPAs want the application experience to be optimal, not
| necessarily their initial first time load. They want small
| requests, interactivity, live feedback. This is all possible with
| SSR, but nowhere near as simple.
| naikus wrote:
| Totally agree! Plus if you use PWA, you get some benefits of an
| installable apps (not on all platforms though) but the support
| is alright on iOS too (more features are supported than before)
| I built a small demo app with 3 views (each loading lazily when
| first requested or loading in background using service worker)
| with view transitions, back button and scroll position
| retention. (built for mobile devices but works on desktops too)
| https://stage-starter.netlify.app
| weird-eye-issue wrote:
| You get all these benefits using something like NextJS's static
| site exports which I'm using right now on Cloudflare Pages
| (it's built-in). Works perfect for a SPA plus you get the SEO
| benefits. Only downside is we had to use query param for URLs
| instead of path-based params but it works the same in the code
| qudat wrote:
| Bravo, I agree with all your points.
|
| React frameworks are mostly hype in order to justify using a
| particular PaaS. They've hired all the influencers and using it
| to their advantage.
|
| There definitely are good reasons to use SSR and these
| frameworks, but a fully interactive web app that acts like a
| desktop app isn't one of them.
|
| All of that to say I have no issues with it and react is still
| awesome. It's a view _library_ and works great for its
| relatively restrained API. Most of the new features are opt-in
| and I don't really touch them (besides hooks).
| matijash wrote:
| this is a really good summary, thanks!
| exabrial wrote:
| We've switched to JSF with Primefaces and a lighter weight
| BootStrap component toolkit for internal apps.
|
| Server Side Component Frameworks are probably peak developer
| productivity, at the small cost that they are not infinitely
| flexible.
|
| Seems like a worthwhile tradeoff when building internal apps or
| database driven apps.
| riidom wrote:
| Wasp is a pretty interesting project. Actually waiting until they
| are not react-only (if that will ever happen).
| matijash wrote:
| glad you find it interesting! the plan is to support more
| frameworks/langs moving forward. The poly-frontend option might
| be even fairly easier to introduce since Wasp is doing more
| stuff closer to the server.
| lastangryman wrote:
| Obligatory "front end is a mess" comment. I taught at a bootcamp
| for 6 months, it was a great experience but when we moved on to
| react after vanilla JS the amount of incidental complexity was a
| huge step up, even with create-react-app. Now they push people
| towards adding a server side framework at the same time, right
| off the bat? I think there's a real danger with new engineers
| entering the industry that they have no chance to develop a
| proper mental model of the underlying tech stack the way so many
| libraries, frameworks, packages, bundlers are thrown together
| just to get something working. You think the docs should just
| start with using plain React, and then branch off in to SPA Vs
| SSR later.
| devwastaken wrote:
| React is for Facebook problems. Facebook is not concerned with
| "new engineers" at this time, nor have they ever really. Big
| tech contributes the least to education and pays little in
| taxes.
| fooster wrote:
| React of course was free.
| charcircuit wrote:
| This article makes the mistake of thinking SPA and SSR are
| mutually exclusive or opposites.
|
| SNR benefits SPAs too.
| apatheticonion wrote:
| Integrating React into an MPA is quite awkward, surprised this is
| the target audience for it.
|
| I love the potential of web development but of recent, it's been
| infected by hype-marketing and blog-engineering.
|
| I get that it's become very accessible to write web applications
| and that's good for the growth of the platform - but it almost
| feels like this accessibility has led it to squander its
| potential in pursuit of unsophisticated and unambitious
| objectives.
|
| Web developers today are distracted by premature over-
| optimisations (ignoring effective low effort optimisations) and
| language+platform features that are a great, but kinda useless
| from a project development standpoint
| (time/money/complexity/collaborative capacity cost).
|
| As a result, platform developers are distracted implementing
| features that don't innovate the platform - so we sit and wait
| for the truly groundbreaking things that never come because we
| gotta discuss the pipe operator, or adding types to the
| JavaScript language specification.
|
| Meanwhile projects that can't wait for the platform to evolve
| flood us with Electron apps that everyone hate.
|
| I have hope, kinda...
| NerdiOrg wrote:
| I think the author is mistaken. You can build a PWA, SPA in
| Next.js and it's even easier than not using it.
|
| I feel like the author is just confused that they're not
| specifically focusing on SPA because whether anyone wants to
| admit or not, enterprise companies aren't asking for SPA, or
| mobile apps, they're asking for headless, static websites. It
| makes sense that React would respond to those market demands.
| mmis1000 wrote:
| Yes, it's likely react recommend don't do it because to met
| feature set everyone expect to 'include by default' from bare
| `react` package today takes way too much effort.
|
| Routing, styling, layout system, animation, data fetching, form
| validation, i18n, SSR(server side rendering), SSG(static site
| generation). More and more are expected today. And react by its
| default offer non of them. And neither react pick a default set
| that will work by default if you just add them. (Vue or Angular
| either promote a default set of these or include them by
| itself, that's a big different with react.)
|
| And integration of library that do these also takes much more
| time than it used to be because the feature set grows. (Let
| alone debug why one of combinations didn't work)
|
| Promoting a working default set (A.k.a frameworks) will likely
| minimize the hassle people need to fight with to get some react
| app up on the production.
|
| Really, no employer cares about whether you use a react
| framework or do everything from scratch. If the website isn't
| online and do what they need. You simply does nothing.
| deepsun wrote:
| I don't understand the fuss about SSR, wasn't that default way of
| doing websites 10+ years ago, before AJAX? E.g. Apache Struts has
| all of that Router logic since like 15 years ago, completely
| server-side.
| meotimdihia wrote:
| SSR solves the problem: "the content does not render before
| your browser download JS."
| deepsun wrote:
| Sorry what JS? With aforementioned Apache Struts there's no
| need for JS to render anything.
|
| But if one wishes, JS can be added, of course (e.g. for DHTML
| stuff). To avoid render blocking there are "defer" and
| "async" attributes.
| noisem4ker wrote:
| To clarify: it's a CSR problem to solve, not Struts'
| (which, as you say, is not subject to).
|
| To answer your original question in a pragmatic way: people
| used to JS tooling, libraries, frameworks obviously want to
| continue using these, not revert to Struts. Plus, modern
| tooling facilitates mixing SSR and CSR, and switching
| between them as needed.
| meotimdihia wrote:
| I have 8 years of PHP experience. Let me explain to you.
| While you can build a static website with Apache Struts or
| PHP, you must add javascript if you want to build complex
| sites anyway, for example: Facebook, Twitter, Tiktok,... In
| the past, everyone used jQuery, but jQuery and ajax can't
| build complex sites. You will end up with too many Ajax +
| dynamic elements + bad practices and can't maintain them if
| you use jQuery.
|
| Finally, you'll end up using React for easy to maintain.
| And you'll have to wait to load React + related packages =>
| it is slow for initial render => and SSR solved the
| problem.
|
| Also, you just need a single team to build a complex
| application while using React instead of backend + frontend
| as traditionally.
| phendrenad2 wrote:
| It sometimes seems like every web framework is run by people who
| see a minor problem and completely change their project to solve
| it. Flash back to 2014 when Rails made Turbolinks on by default,
| and broke everyone's SPAs. Flash back to Angular rewriting in
| Dart because "it's the future" (it wasn't). Flash back to React
| replacing the perfectly-fine functional components with hooks
| (because Vue did it).
|
| And now React is throwing away its backend-agnosticism because
| they want to hold your hand and make sure you don't fail at SEO
| and blame React.
| mmis1000 wrote:
| > Flash back to React replacing the perfectly-fine functional
| components with hooks (because Vue did it).
|
| I think the timeline went wrong. React did it first, vue did it
| latter.
| ecf wrote:
| Hype driven developers/marketers believe the only type of
| websites that exists are those which need indexable content for
| SEO purposes. More news at 11
| weird-eye-issue wrote:
| SEO is an important part of marketing for a lot of companies.
| It's not hype, it's just regular marketing
| [deleted]
| PaulHoule wrote:
| If you need SSR to support an SPA it calls into question why you
| need an SPA at all.
| python999 wrote:
| My requirements are 99% SPA and 1% SEO
| [deleted]
| 88913527 wrote:
| I don't understand the pivot back to SSR. Tearing down and
| standing up the entire DOM and page memory between navigations is
| just unnecessary work. Little things like maintaining scroll
| position in the page's navigation bar meaningfully improve
| usability and are only achievable with a SPA-based approach. This
| doesn't discount the challenges of building SPAs: bundle sizes,
| performance, etc. can be concerns if not managed. That's true of
| any application.
| layer8 wrote:
| > Little things like maintaining scroll position in the page's
| navigation bar [...] are only achievable with a SPA-based
| approach.
|
| That's not true. I wrote non-SPA web applications in the mid-
| aughts that maintained scroll position throughout server
| roundtrips, using JavaScript and storing the current scroll
| position in hidden fields upon submit. Even multiple scroll
| positions for nested panes. It also adjusted the saved scroll
| positions correctly when new elements were added to or removed
| from the page during the server roundtrip. This was
| encapsulated in a server-side HTML rendering framework.
| tshaddox wrote:
| I think you might be using the term "SSR" in a non-standard
| way. In the context of JavaScript apps, SSR refers to an
| initial pre-rendering of the HTML of a SPA page on the first
| browser page load. Subsequent navigations in that same browser
| tab would render on the client just like an SPA that doesn't
| have SSR.
|
| You might be talking about what the JavaScript community has
| started to call "MPA," which doesn't seem to have converged on
| a clear meaning but seems to usually imply that some or all
| page navigations do involve a trip to the web server and an
| HTML response.
| youngtaff wrote:
| SSR isn't actually rendering though... it's generation of
| markup just like PHP does... sure sometimes it contains data
| to rehydrate the page just like early .Net components used to
|
| The various JS frameworks seem to have taken a concept that
| was common and tried to rebrand it which just adds more
| confusion
| tshaddox wrote:
| In React I think it's pretty fair to call it server-side
| rendering, to distinguish it from the usual client-side
| React render which manipulates the DOM. It's just like
| that, except it renders to a string that can be returned in
| an HTML response (or streams:
| https://react.dev/reference/react-
| dom/server/renderToString#...).
|
| It might be a little clearer now to call it "pre-
| rendering," to distinguish it from React server components
| which also run on the server but which are quite distinct
| from SSRing client components.
| jameshart wrote:
| Fullstack react frameworks aren't purely SSR - they're
| isomorphic JS apps, which can render an initial page load
| serverside, then use clientside routing, suspense, serverside
| components, and clientside rehydration to progressively update
| the DOM without a full page refresh.
|
| They are basically delivered as SPAs, with an integrated,
| isomorphic backend-for-frontend service embedded in the origin
| server.
|
| They just don't feel like SPAs, because they have a multipage
| (routing) framework, and isomorphic rendering means those paths
| can be directly loaded from the server - while any subsequent
| navigation just updates your UI clientside.
|
| In the case of static conteent-based sites, that SSR can even
| be done ahead of time, as a static built-time render, and the
| pieces of data needed to load different pieces of content into
| the SPA ('pages') get dumped out as static JSON resources.
| That's what Gatsby offers particularly as its specialty versus
| next.js.
| eurasiantiger wrote:
| Next.js can also do Gatsby-like static generation, but also
| update those generated pages if the content changes in the
| backend. They call it incremental static regeneration (ISR).
| jameshart wrote:
| Yeah, there's a ton of overlap between what different tools
| _can_ do. Gatsby is just more centered on those usecases.
| cooperadymas wrote:
| Since when have SPAs figured out maintaining scroll position?
| That's not my experience at all.
| seandoe wrote:
| What is going to change the scroll position on a state or
| "page" change? It's not that they figured it out, it's just
| the nature of a single page.
| cooperadymas wrote:
| Er, lots apparently. Just now I was searching through posts
| on a Facebook event to find more details. I thought I
| finally found what I was looking for buried a few months
| deep and clicked it. It was the wrong item so I clicked
| back and Facebook scrolled me to the top of the event page
| again.
|
| This is a common occurrence for me on Facebook on both
| mobile and desktop. It happens sometimes in Gmail too. I'm
| certain I could find a half dozen other examples given five
| minutes to go test.
|
| Meanwhile HN happily preserves scroll position perfectly.
| quickthrower2 wrote:
| Modern SSR is for the first page load. After this all
| navigation and interaction is AJAX.
| ZhadruOmjar wrote:
| Bored software engineers just want to keep making changes
| rather than moving to a new problem space.
| knome wrote:
| the biggest problem with SPAs is none of the devs making them
| seem to remember how nice it was to open different pages of a
| site in different tabs. it's all horribly phone/tablet centric.
| middle-clicking doesn't even pop links in new tabs because they
| break basic browser features. you're lucky if you can even tell
| what's a real link and what's just going to rearrange your
| current page.
| tshaddox wrote:
| This only happens now with an SPA due to laughable
| incompetence or deliberate disregard. You have to go out of
| your way to not use whatever Link component or similar tool
| provided by your SPA library/framework of choice. Any team
| that incompetent or negligent would be just as likely to
| break link behavior even if they aren't using an SPA.
|
| I'm surprised the criticism is still ubiquitous: it's either
| 5+ years out of date or some people run into these terrible
| sites a lot for some reason.
| astura wrote:
| These criticisms are still ubiquitous because these sites
| are still ubiquitous.
|
| For example, less than 2 years ago someone did a "Show HN"
| of a Shopify front end they launched for their wife that
| was literally almost entirely nonfunctional. Not
| exaggerating.
|
| https://news.ycombinator.com/item?id=27182932
| tshaddox wrote:
| Has that page changed a lot since then? Every link out of
| a dozen or so that I quickly checked were all real <a>
| tags that worked fine with middle- and right-clicking. I
| couldn't reproduce the back button behavior in your
| complaint either.
| astura wrote:
| Yeah, Looks like the store has been fixed.
| kitsunesoba wrote:
| Find in Page is another common casualty, and frustratingly
| it's not always re-implemented by the SPA.
|
| I think a lot of the ire against SPAs and other flavors of JS
| heavy pages would dissipate if devs made a point of trying to
| not unnecessarily break browser features and when breakage is
| unavoidable, furnishing replacements for the broken features
| that are as good as or better than the originals.
| madeofpalk wrote:
| I don't understand this. All the popular/used routing
| frameworks by default support "open link in new tab" (render
| <a href="..." />, and listen to onClick to do SPA
| transition). Developer have to deviate from the easy and
| commonly documented way of doing things to break this. Any
| website that doesn't do this is fundamentally broken and
| built by teams that deliberately disregarded this behaviour.
| danaris wrote:
| I don't know which sites use what particular frameworks and
| paradigms (and I don't recall offhand which sites I've had
| these problems with), but I frequently have problems with
| sites that will, when I command-click on a link (standard
| shortcut to open in new tab on Mac), either open the page
| in the new tab _and_ change the current tab to it, or just
| completely ignore my expressed desire and only change the
| current tab.
|
| "But all the frameworks _support_ doing the good thing! But
| only people who are _bad_ at it make bad UX! "--well, it's
| still happening. No amount of contempt for the people doing
| it changes that.
| wincy wrote:
| And even big sites built by well paid engineers that should
| know better (I'm looking at you Microsoft Azure!) have these
| issues! Sometimes middle click works. Sometimes it doesn't.
| Sometimes right click open in new tab works. It's so damned
| annoying.
| tshaddox wrote:
| This often has little or nothing to do with SPAs though.
| Quoted tweets on Twitter on twitter.com, for example, can't
| be right- or middle-clicked for...absolutely no good
| reason. They just don't render an <a>. Yet twitter.com is
| an SPA, and the little "30m" time indicator on a tweet is a
| fully working <a> that can be right- and middle-clicked and
| also does a client navigation when clicked normally.
| barrongineer wrote:
| Typically with SSR, only the initial load is server rendered.
| Subsequent navigations are client rendered.
| jonplackett wrote:
| I think to sway the only benefit of Next.js is DEO is
| underselling how useful it is.
|
| Sure SEO is important for most people anyway, but having multiple
| pages that load instantly rather than having to wait for a server
| call is also pretty handy. Plus auth working better.
|
| I don't see why next wouldn't be the default and react now the
| outlier.
| NerdiOrg wrote:
| Agreed, this is how our team uses it. We hire React devs and
| teach them Next.js day 1 and essentially their React experience
| is helpful but Next is the main focus for the devs.
| robertoandred wrote:
| I don't think the author understands what a SPA is.
| seattle_spring wrote:
| Nor most of the commenters here. SSR on page load doesn't mean
| it's not a SPA from that point forward. Done right, pages will
| render appropriately either on the server or on the client with
| the same code.
| jollyllama wrote:
| So they're trying to corrupt the meaning of "framework" to mean
| only "full stack framework"
| matijash wrote:
| yeah in a way. react gets closer to being synonymous with
| next/remix rather than viewed as a separate, standalone
| library.
| canadiantim wrote:
| too much commitment for me
| nvln wrote:
| Does anyone else feel that the complexity of the full-stack
| frameworks is getting untenable?
|
| 1. There is a significant gap between dev and production
| environments. (See #2 why this is critical)
|
| 2. The production build times are super high
|
| 3. ES modules are great, but the JS ecosystem being a bundle of
| small libraries, getting them all to play nice is hard.
|
| 4. I occasionally get X is included twice errors that are painful
| to track and debug
|
| 5. There are frequent instances where I find out that the very
| problem I had has been solved by someone, but they don't know how
| or why. They remove a, b, c then it works. They add it back, it
| still continues to work.
|
| What happened to KISS?
| danlugo92 wrote:
| I develop in react and follow KISS and I don't have any
| problems whatsoever.
|
| Some libraries can be a pain in React Native however, but React
| web has been smooth sailling for me (following KISS and MVVC).
| mythrwy wrote:
| Ya but for many cases there is a simpler way with less moving
| pieces.
|
| React just isn't KISS by nature, or maybe it is KISS for a
| certain style of problems but not others.
|
| It takes too long and has too many steps to do simple things.
| If all you are doing is simple things using React isn't KISS.
|
| Here's a tinfoil hat crazy conspiracy theory: Facebook
| released React and promoted it's uptake to slow down any
| possible competition's development cycle. (I don't _actually_
| believe this of course, but sometimes I do kind wonder).
| nvln wrote:
| Yes, using just the FE part is still joyful (Svelte, React
| etc). It's the move towards full-stack (Next, SvelteKit etc)
| that I'm slightly complaining about. My complaint is also
| limited to how complex the build process is in combination
| with other aspects of the fast moving TS/JS ecosystem.
| matijash wrote:
| that's what our goal with wasp[0] is - to abstract the common
| patterns that keep reappearing and condense them to a
| configuration choice, while still leaving hatches to write your
| own code. Still have a way to go (in Beta atm) but I think we
| managed to demonstrate the basic principle in some instances.
|
| [0]https://wasp-lang.dev/
| fendy3002 wrote:
| If we're talking about react framework (NextJs), then it's the
| KISS part. Everything is kept simple as react components.
| Single way to define styles / class, and single way to maintain
| components: react components.
|
| Using MPA with htmx and only use react on occasional necessity
| seems better or optimized, but it comes with one limitation:
| sometimes it's hard to replicate the non-react component /
| styles in react. Using NextJs removes that limitation.
| kypro wrote:
| > What happened to KISS?
|
| Engineers have to over-engineer to look smart.
|
| Back when I first started working as a software engineer no one
| gave a crap about good code or best practises. Back then it
| wasn't uncommon for there to be a few dudes maintaining the
| website of a large household name business with almost no
| oversight. I remember it being common for someone entirely
| untechnical to come over to dev desk and ask for some feature,
| then you'd find the easiest and quickest way to get that thing
| live.
|
| Skip to today and we have entire engineering teams with
| hierarchies, specialities, and accountability - and this is
| true even in smaller companies.
|
| So imagine you're the lead frontend guy at some company... Are
| you honestly going to say, "well the site's requirements are
| kinda simple, so we can probably just build it in HTML and
| vanilla JS"?
|
| There was a period several years ago where frontend guys
| writing HTML/CSS and some JQuery were lesser regarded than Java
| and C# devs. It's why I always pitched myself as a backend guy
| who knew HTML & JS. But then we got Node, React and
| TypeScript... Now frontends are so complicated that if you want
| someone with enough experience to understand how any of it
| works you need to pay them a decent salary for their knowledge.
| root_axis wrote:
| Have you considered the possibility that people aren't as
| stupid as you think and that these tools actually solve real
| problems?
| [deleted]
| nvln wrote:
| What part of my comment suggests that I think people are
| stupid?
|
| ---
|
| Tools can solve important problems "and" increase the
| complexity to point where they create other problems which
| makes the trade-off untenable.
| root_axis wrote:
| > _What part of my comment suggests that I think people are
| stupid?_
|
| This part:
|
| > _What happened to KISS?_
| neon_electro wrote:
| https://en.wikipedia.org/wiki/KISS_principle
|
| Right on that page is an example of "Keep it Simple"
| without the "Stupid". A charitable reading of parent's
| comment wouldn't have thought the commenter was labeling
| anyone stupid with the appeal to keep things simple.
| root_axis wrote:
| You can deliberately exclude the word "Stupid" from the
| expression, but that doesn't change what is being said.
|
| > _Whatever happened to KIS(S)?_
|
| Interesting question, I wonder how the entire ecosystem
| forgot this one simple trick? What is it about their
| brains that causes them to create all these solutions
| that are apparently worse than the problem?
| cxr wrote:
| > ES modules are great, but the JS ecosystem being a bundle of
| small libraries, getting them all to play nice is hard.
|
| Please say "NPM" (and not "JS") when that's what you're talking
| about.
| poyu wrote:
| Makes you really wonder why they're doing this to themselves.
| Use whatever is most suitable. I try to use as less JS as
| possible.
| gepardi wrote:
| What do you typically use?
| duncan-donuts wrote:
| Late last year I listened to talk on nextjs and I was floored
| by its design. I still can't get over that the JS community has
| embraced file system routing and server rendered stuff. I
| honestly think I'm taking crazy pills because I could have
| replaced "nextjs" with "PHP" in most places and it would still
| make sense.
|
| I have been in software for about a decade and I think I'm
| experiencing my first complete cycle of "what's new is old".
| leerob wrote:
| There are similarities to PHP - and I think that's a great
| thing! I like to think of Next.js as the best parts of PHP /
| Rails with the powerful UI engine of React. Especially with
| the new App Router, where you can fetch code inside
| components like `await db.query()` and soon easily
| insert/update/delete from the same file as well.
|
| https://beta.nextjs.org/docs/data-fetching/fundamentals
| matijash wrote:
| that's one thing I've been thinking about a lot lately and
| I think it is confusing for many - that both
| Next/Nuxt/Remix and Rails have a title of a "full stack"
| framework while they are pretty different in reality.
|
| Next/Nuxt are coming from the frontend origins and are
| strongest there, while Rails/Django are coming from the
| backend and focus on db ORM / data model story via
| ActiveRecord etc.
|
| I understand the etymology of terminology, but I think
| we'll probably come up with better names in the future.
| E.g. Remix briefly called themselves "center-stack" which I
| found interesting and think makes sense.
|
| I'll keep investigating and probably whip up a blog post
| about it.
| Dylan16807 wrote:
| Well, when I hear people complain about PHP it's not about
| the routing or the idea of server-side rendering.
| mmis1000 wrote:
| The ancient php idea of mix data fetching and rendering
| instead of wait until everything done for least `TTFB`(Time
| to first byte) is still hard to do for a lot of js
| framework today. You generally need to add tons of hack to
| the framework so you can print your site header before
| fetch and print the article body completely. (Which a phper
| will ask you "why you don't just print it?").
|
| React and vue has add limited streaming rendering support
| recently, but they are still very limited and you need to
| met some constraint to actually use it.
|
| It's really something `old is new today`.
| Dylan16807 wrote:
| "You can't do this old thing, except barely and with
| great difficulty" sounds like it's close to the opposite
| of "old is new" to me?
| robertoandred wrote:
| Php doesn't equal file system routing. Look at Wordpress.
| lawkwok wrote:
| It's funny to think there was a time when using JS vs JQuery
| was the biggest division among devs. Now just using JS is
| considered the baseline and React is the new framework that
| people jump to when it isn't always necessary.
___________________________________________________________________
(page generated 2023-03-19 23:03 UTC)