Website requirements about entropic HOT 98 OPEN

In my experience, any project that requires more than the most simple frontend will see large DX benefits when using an SPA over simpler template rendering. If the frontend were only required for signup/login/auth, I think an argument could be made in favor of a templating language. However, since it also aims to create package search/detail/statistics interfaces, I believe the SPA approach becomes more appealing.

I foresee the following elements requiring a non-negligible amount of client-side scripting:

• search autocompletion
• package description markdown rendering
• interactive UI (tabs, form autocomplete/validation, routing, etc)

If those features aren't necessary and can be avoided, then an SPA may be overkill. However, as soon as you want to work on one of them, you'll have to write client-side JS, which will lead to some sort of client-side dependency bundling/processing to optimize in production, so I believe that maintenance complexity will naturally arise one way or another - may as well take advantage of the DX boosts associated with an SPA:

• better separation of concerns (you can't tightly couple your server logic and frontend when they're split into two separate projects)
• hot code reloading for faster design iteration
• better end-user experience (only a single initial page load, no page flashes when changing routes)
• easy access to more complex build tools (static typing, CSS-in-JS, minification, asset optimization, etc)
• the web client can make use of the same REST routes that the CLI client uses, so more streamlined experience between the two
• assets can be cached client-side and don't need to be regenerated on every request like with a templating engine

The biggest downside of an SPA is definitely the added complexity, but I personally believe that cost is worthwhile and will lead to a better product long-term. I'm interested to see what others have to say - I'll press the pause button on #102 until this discussion progresses further.

from entropic.

I was kind of anticipating this whole discussion about what technologies to use and not knowing what was necessary right now that’s why my PR (#103) was really just about the most simple HTML/CSS site possible right now so that at least some information about the project could exist in a website.

Being a frontend developer myself and having worked with all the popular frameworks, in large and small apps, client side only SPAs and server rendered SPAs and having managed all sorts of complexity, I’ve also went with a super simple approach for my own personal website (using eleventy+nunjucks) because I really didn’t need more, and I think a similar approach could work here, similar to what Chris described:

• Start small, build just some static pages
• Using a templating system like nunjucks (which is mostly some templating to display data and some conditionals and loops) doesn’t lock you in too much
• First bits of javascript based on the needs described above are probably small enough that they don’t even need to be bundled
• If you do need to start bundling, you can do so with the most basic webpack/parcel build, just to put some files together
• If there’s a need to go the SPA (or SSR SPA) route after that there shouldn’t be too much lock in and it should be straightforward to migrate

TL;DR: start with something simple, add tooling as necessary.

from entropic.

An update: there's some infrastructural work ahead of this that has to get done (it's plodding along in #135). Specifically, we need to separate the storage layer from the registry, and the website from the registry. This unblocks work on the website and allows us to get underway with #141. This'll have the affect of actually making the website displayed on www.entropic.dev controlled by the website service!

Once this work is ready, our next steps with the website will be a lot more concrete & we can start picking rendering approaches and frameworks.

from entropic.

First bits of javascript based on the needs described above are probably small enough that they don’t even need to be bundled

I don't think that's true since we'll need a client-side markdown rendering library (and whatever dependencies it brings with it). Granted, we could render/cache project READMEs server-side, but then that introduces a non-negligible overhead at scale and I feel like one of the benefits of this project is that it's usable by anyone, no need to drive up the hosting costs. Same for server-side rendering, at scale it will require higher container compute time and will more quickly require higher hosting tiers, while an SPA can be thrown behind a Cloudflare proxy and forgotten about.

If there’s a need to go the SPA (or SSR SPA) route after that there shouldn’t be too much lock in and it should be straightforward to migrate

I think this project is straightforward enough to know now whether or not this will ever be required; the project's scope is pretty well defined, and there are existing alternatives like NPM to use as a case study (NPM does use an SPA). While I appreciate the desire to start small and work your way up, why not go ahead and plan for the future now? If we go with templated SSR now and then 6 months or a year later want to switch, all of the template code will have been wasted since it won't be able to translate to SPA land.

Additionally, SPAs will allow for a more useful PR diffing experience since changes to the frontend UI will never touch the backend files, and vice versa. It will be clear from filename alone whether changes were made to the visual presentation or to the business logic, and contributors that only want to participate in one won't have to slog through the other.

From the points already provided I think it's fair to say that:

• SSR templating => easier maintainability, worse user experience
• SPA => tougher maintainability, better user experience

In my mind, better UX should always win out.

from entropic.

The feature set is not defined (that's on me, sorry!) This is not an exhaustive list & I will do a more complete writeup elsewhere as soon as I get some time!

• The hierarchy of values for the website are: we want the server to be easy to set up and maintain, easy to use, and easy to develop, in that order.
  • By "maintain", I mean: imagine someone outside the JS community being asked to set up an Entropic instance, or to fix an Entropic that's throwing errors.
• Entropic instances may live inside your network, so network latency concerns are a bit different than the average website.
• Markdown is pre-rendered on publish. It is stored at rest as HTML suitable for inlining. (Storage is cheaper than CPU cycles.)
• We don't have search. Federated search is going to be a different beast than centralized search. (Think Napster/Kazaa/Limewire/Bittorrent, not Google.) It might not be a thing that individual Entropic instances support!
• We want i18n support. My experience with rich client apps has been that you end up having to generate multiple different asset bundles for each target locale (or else do some kind of code-splitting.)
• We want to have good a11y.
• The server component of the website will have privileged access to an internal backing storage API that frontend code will not.
• We currently only supply the following functionality:
  • receive CLI login session
  • Redirect to GitHub OAuth
  • Receive GitHub OAuth response
  • Sign up for new user
  • Display token list
  • Create new token
  • Homepage (currently served by nginx as flat html)
• We wish to supply, roughly:
  • A paginated list of all packages on the instance
  • Package detail pages with:
    • A readme
    • links to dependencies,
    • links to (local) dependent packages.
    • No download counts (Content addressable store precludes this.)
    • No external dependent packages (we don't know who depends on this package elsewhere!)
  • List of namespaces of which you are a member.
  • List of outstanding namespace membership invites for your user.
  • For each namespace of which you are a member, a settings page:
    • List of extant maintainership invites.
    • (Long term) Ability to invite a member to a namespace.
    • List of current members.
    • List of packages maintained by this namespace.
      • (Long term) ability to invite a maintainer to a package.
      • (Long term) ability to remove a maintainer from a package
      • (Long term) ability to "yank" a package or package version
    • List of packages originally published by this namespace.
      • (Long term) ability to remove a maintainer from a package
  • (Long term) Create a new namespace

from entropic.

I'm biased in favor of gatsby but gatsby will be great for this. You don't have to run a server because everything is static hosted so it's going to be pretty cheap. Api calls can be cloud functions as they can scale pretty heavily.

For the packages pages itself it's probably to best to go for full client side for now as gatsby doesn't have incremental build support yet which means we have to rebuild all pages.

I don't mind guiding/writing a bunch of the website in gatsby if that's the direction you want to go.

from entropic.

Speaking as a total newbie outsider who literally got into coding within the past year, has no authority over this project, merely interest, and who does happen to have React experience (as do a lot of new devs -- face it, it's the latest trend which means it's everywhere), that template literal basically just looks like React code I've written and seen written, and writing with it wouldn't make me any more comfortable. I'd just look confusedly at you and ask why I am writing React without writing React.

It matters little but I agree with superhawk610. To manage a project that will become of considerable size, like this one, you will have a framework. You are merely choosing whether you are writing it yourself or using someone else's. The need to have a repeatable, reliable, battle-tested code on every line of a large site is what makes frameworks happen, it's what made Bootstrap happen, it's what made NPM themselves choose Hapi and then React. Entropic is not going to be a small project if it becomes even slightly successful. I may be new, but I can see patterns. If it becomes successful, even if it is decentralized, there will be x100 iterations of its success, and that is not small.

If you want to provide options for people, then just make sure the API is easy to query from multiple kinds of sites (which might mean no GraphQL) and let there be multiple possible sites constructed using that API. That way, anyone can use their preferred templating framework to write their own entropic registry frontend.

from entropic.

Thanks, there ya go!

from entropic.

I haven't seen Next.js (https://github.com/zeit/next.js/) mentioned yet. I've spent the last 13 months working with it in anger to power Vogue Fashion Shows for multiple countries. Looking at @chrisdickinson' feature set, it can do all these things. I've worked personally on SEO, Internationalisation, accessibility and analytics with it. It has been painful at times, but I have a much better understanding of how it works now.

Saying that, I am very much on team "do a bit of vanilla css with an HTML and see how it goes" with @trodrigues.

Really really keen to help out here.

from entropic.

It kinda sounds like most people are saying the same thing in different words.

• We like out-of-the-box solutions, building your own framework would be a disaster
• SSR seems like a good idea, but we want the slick experience of working in a SPA
• We shouldn't use some giant kitchen-sink solution

Which to me sounds like Gatsby or Next.

from entropic.

FWIW (coming from a recovering FED), SSR with only minimal client-side JS would make things a lot easier for folks who like to browse with JS off or use alternative browsers (including text-mode browsers). And you could get a lot of the DX benefits with SSR by using something like Next.

from entropic.

I'd like to raise a few questions before jumping into the SPA vs SSR debate:

• How do SPA's deal with search engine indexing? Is it a goal to optimize it to "compete" with npm?
• How do SPA's deal with minimal browsers?
• What is defined "good UX"? What is considered the main use-case of the registry?
  It's important to ask, because depending on the answer SSR or SPA can be the better user experience (imho). I don't mind that an mail application client takes a while to load in the browser, because I might "live" in it for a while, once it's loaded. I do mind slow loading speeds when browsing content (let's say Medium). So it's important to understand where entropic would fall onto this spectrum.
• Is DX valued more or less, compared to UX? And how bad/good are both sides?
• What is more valuable when thinking about server-side (cost) vs client-side time (perf)?

from entropic.

SEO is not only about meta tags. Content is the most important thing for SEO.

Huh, TIL. If this is the case then you're right, client-side markdown rendering probably isn't an option.

I do think there's a stronger argument to be made for a more barebones server-rendered approach, but I will say that I don't think going from templated SSR -> SPA is any easier than the alternative. I think it's a difficult transition both ways since any client-side stuff you've written in a non-React/Vue/Angular environment isn't really transferable to an environment with a framework and vice versa.

I've seen multiple people mention that adding a frontend framework like React will increase complexity, but I would argue it doesn't raise the bar for entry, it just requires a different skillset. Client-side UI interactions without a frontend framework like React introduce their own set of problems that are inherently solved when using a UI framework.

I guess I'm moving my vote from a dedicated SPA to a server-rendered SPA, ala Next or Gatsby. Best of both worlds 😄

from entropic.

@workingjubilee @superhawk610 Thank you, that was exactly what I was trying to convey. If we're to use a framework, we might as well use a well-known one that's gonna be mostly-failproof.

from entropic.

(I apparently wasn't very clear. I do not want to use the JS templating literal approach. I wanted to show one extreme of the spectrum. That wasn't the greatest of ides, sorry for the confusion)

from entropic.

Next.js is written exactly how you'd write an app using create-react-app (for the most part). There is some structure that's different, and some different concepts. There's getInitialProps that fires before componentDidMount. There's a server, there's pages. I'm not sure why there's an assumption you can't share code, you do :) Would really recommend taking a read first.

https://nextjs.org/learn/basics/getting-started

Server-rendered by default
Automatic code splitting for faster page loads
Simple client-side routing (page based)
Webpack-based dev environment which supports Hot Module Replacement (HMR)
Able to implement with Express or any other Node.js HTTP server
Customizable with your own Babel and Webpack configurations

I am more than happy with Gatsby or something completely different, or just a HTML page. I just want everyone to have all the info 👼

from entropic.

To jump in with some Gatsby info:

Gatsby generates all possible routes ahead of time as HTML files, essentially sacrificing disk space for response time.

This is true. Gatsby will generate all pages at build time. The cost is disk space, which I'd argue is dirt cheap compared to scaling servers.

Gatsby has a proof-of-concept of incremental builds working, which would eliminate the need to rebuild every page — instead we'll just regenerate the pages that the updated data/files touch. This is coming, but not here yet. @KyleAMathews may be able to shed additional light on how and when this will work.

Gatsby can also handle client-only routes for data that doesn't need to be built ahead of time.

Another potential benefit of Gatsby could be security: all files are static and there's no server available by default. That means that an attacker can deface static assets, but there's no attack vector through the generated app to the server or underlying databases. (This, of course, doesn't apply to any client-side calls, but that's going to be true with any client-side code.)

To my mind the trade-off is that Next provides convenience through realtime SSR at the expense of additional devops complexity and overhead; Gatsby provides painless devops at the expense of rebuild lag.

from entropic.

"would be more likely familiar to newcomers" does not say anywhere in that sentence that Vue isn't accessible. Nor does it say Vue is harder.

It's evident you love Vue, and that's excellent! It's not as well known with beginners which is what I believe the above sentence was saying. Let's keep it chill pals 🌱

from entropic.

From the points already provided I think it's fair to say that:

• SSR templating => easier maintainability, worse user experience
• SPA => tougher maintainability, better user experience

Just my two-penny worth, but I would also lean towards a more user-centric approach. This project will likely appeal to a wide range of frontend developers and designers alike, and the appearance and feel of tools can impact heavily on how or even if they are adopted.

from entropic.

If we're using React, then Next.js (SSR React) or Preact (React, but smol) would be better choices then rocking up with a create-react-app everything and the kitchen sink.

from entropic.

I like Svelte's focus on compilation (transpilation?), but I'm not sure that should be the first step forward. I say this from a place of ignorance, but does Svelte have enough of a user base that we can be sure people will comfortable contributing? At least with a popular framework out the gate, we'll know there's a higher likelihood of developers capable of jumping in.

from entropic.

Firebase auth is probably overkill since entropic isn't using any other firebase features like firestore (everything's already set up to use self-hosted Redis/Postgres instances). The server-side logic for handling registration/login is already there, we just need a way to:

• receive and store an OAuth token client-side (replacing /www/login/providers/:provider/callback with a client-side route), or
• generate a corresponding entropic frontend token for the client to store that doesn't reveal the GitHub (or whatever provider) actual OAuth token and use that to authenticate any elevated request from the frontend, or
• make use of the existing session middleware and keep the OAuth implementation completely server-side (using cookies instead of Authentication: Bearer XXXX headers for elevated requests)

from entropic.

If we barely know the features we will need...we are in a very early state.

Yes and no - the project is young, but it is aiming to directly replace an existing product with years' of trial and error backing it. Entropic isn't aiming to reinvent the wheel, just to take an existing wheel (NPM) and change the way it is hosted and managed on a high level (at least, that's my understanding, please correct me if I'm wrong). As I listed earlier, I believe the featureset is already fairly well-defined:

• client-side markdown renderer
• client side form interactions (regex validation, checking for duplicate username before submissions, etc)
• client side UI interactions (tabbed panes, route transitions, loading states, etc)
• client-side asset caching

forget about decent indexing and SEO on SPA, compared to plain HTML or SSR.

SPA and SSR are not mutually exclusive. The only functionality exclusively available to an SSR is page-specific <meta> tags, and this can still be very easily accomplished by spinning up a very minimal SSR renderer (either using an existing solution like Gatsby/Next or even a simple Express server) to inject the relevant SEO info into the index.html before serving - this approach has the advantage of minimizing server-side work while still allowing for the richer UX of an SPA.

EDIT: I've added a PoC to my PR branch, you can check it out here.

Also, as @nilsnh suggests, do we want the website to be accesible for everyone or only for last-generation browsers? SPA's rely totally on JS which can easily end up with performance issues (so more complexity to deal with).

While they do rely on JS, SPAs also make quickly implementing and iterating on things like i18n and a11y much easier.

If we really don't know the amount of features yet

I've seen a few comments mention this line of logic, and I'm curious to hear more about your thought process - what aspects do you think are still left to decide on?

from entropic.

Markdown is pre-rendered on publish. It is stored at rest as HTML suitable for inlining. (Storage is cheaper than CPU cycles.)

Client side rendering is cheaper than both ;)

from entropic.

If you go the vanilla route you probably need some kind of template engine which will be a learning curve as well. You probably would look for something like https://www.11ty.io/ or go the SSR way with express & ejs but I wouldn't recommend it at all.

The benefit of the approach is that everyone can start without learning a framework and such but you'll have to create lots guidelines and rules to keep code consistent so I'm all for going into a framework route. Can be gatsby, nextjs, nuxtjs, angular, polymer, ...

from entropic.

Without using an existing framework like React, you have to define your own project-unique set of practices for any frontend code like how to use classnames, how to split files, how each script will be loaded, how code will be shared between routes, etc. That's arguably as much of a learning curve as picking up the basics of React, but it's non-transferable outside of the scope of this project, while knowledge of React is something that many devs already have and will continue to be relevant outside of the scope of this project. Going barebones isn't really lowering the bar of entry, it's just requiring project-specific onboarding instead of framework-specific, which is a net loss IMO.

from entropic.

@workingjubilee
I disagree with the first point, since I think view libraries like React and Vue are for more expressive than template languages (or the template literal example above), which is (imho) one of the reasons why SPA's became so popular.

I agree with the fact we should use existing frameworks and use those the fullest potential, because they are battle tested. It doesn't matter of it's a robust server- or client-side framework/tool. The most important thing to look out for (again imho) is how much effort it would take to move to something else if it's not working out.
It's important we are setting up for success during these many (small or not) iterations. So I think we really should go for something battle tested (in stead of rolling our own everything), but we should be wary of locking ourselves into it too much.

@varjmes
Agree 100%, if we decide to go for solution X (with X being something battle tested), then I agree we shouldn't go for a complete kitchen sink approach.

from entropic.

What are you people's thoughts on the Entropic ui being a SPA?

Personally I think it's a nay, purely due to SEO and I don't think the registry feels like Single Page App. I'm fine using a SPA if I'm going to spend a while in it and if it has powerful features. Think of Gmail.

I don't think the registry fills that purpose. If I think about what I do on a site like npm is usually:

1. Search package on npm
2. Read the docs
3. Check how alive it is
4. Close tab and npm install

It's more about content discovery rather than having an application which does an amazing thing.

I'd see a better use-case for an SPA when entropic would include a complicated dashboard for "managing things" purposes. But not for the site that should "replace" npm.

from entropic.

@varjmes I didn't realize you can also use the SPA term outside of client-side rendering, my bad.
Nevertheless, what I'm saying is that I think SSR is key and a purely client-side rendered SPA doesn't seem to fit entropic's usecase.

from entropic.

@varjmes right, but client data fetching and SSR are mutually exclusive, anything you do client-side won't be there for search engine crawlers and thus kinda defeats the purpose, right?

Sure! In this case I was correcting the assumption.

With SEO it isn't necessarily an all or nothing case with SSR/CSR, see https://medium.com/@benjburkholder/javascript-seo-server-side-rendering-vs-client-side-rendering-bc06b8ca2383 but getting decent SEO with CSR is not worth the effort when you can just go SSR.

from entropic.

Thanks to @superhawk610 that is here to share and stand my points and thoughts. :D

And I'm super amazed of the newcomer @workingjubilee thinking and comments. Congrats.

Yea, Nextjs might make more sense, because there will be tons of package pages. And even if they were gonna be only few hundreds it's impossible in Gatsby land - except re-running build, which gonna be insane.

from entropic.

If the goal is to avoid big name company products, Preact is also an option, and it works with Next. The lead maintainer is a Google employee, but I believe the project is independent. I like Vue, but React or React-alikes would likely be more familiar to newcomers.

I've been keeping an eye on Svelte and it seems really neat, but I would think that for most contributors coming in, that would be a blocker, at least unless/until it's up there with with the big players (React, Ember, Vue, Angular).

from entropic.

@workingjubilee

2: I think the options in the poll were taken from the most common suggestions in this issue thread.

3, 4, 5: Definitely! I don't think anyone thinks this poll is in any way binding, I think we're just trying to get a feel for what people are leaning towards, since the issue comments have gone on for a long while and it's hard to sum up everything that's happened.

9: I don't think a core maintainer being offline for a bit means folks need to stop contributing ideas! No one's trying to force a decision through, I think everyone here is just trying to figure out what might be best for this project.

@olingern

I somewhat agree, but right now there's a small but slowly growing bit of server-side rendered content already in the form of template strings, and I think one driving thing behind the discussion here is wanting to head that off and settle on a real, planned, and maintainable solution before we end up with lots of disorganized rendering hanging around.

Also regarding pre-rendering Markdown on package publish, I think there should be more discussion around whether that's ideal. That's trading off disk or s3 space and publish-time cycles for render-time cycles, and some of the debate in this thread has been about whether that's even the right thing to do.

from entropic.

every namespace getting its own Gatsby instance

There's support for prefixing, so a URL structure of /:namespace/* would allow for an instance-per-namespace setup. Gatsby themes would allow for all common code to be rolled up into a single shared package to avoid the need to duplicate code between instances.

Incremental builds in Gatsby aren't too far off, either, so in the near- to mid-term this issue will resolve itself upstream.

from entropic.

You raise good questions @venikx.

I'd like to raise a few questions before jumping into the SPA vs SSR debate:

* How do SPA's deal with search engine indexing? Is it a goal to optimize it to "compete" with npm?

According to Google they seem to be able to index SPAs decently since 2015. But Facebook doesn't parse JS (Could that be the same case for Twitter?).

* How do SPA's deal with minimal browsers?

SPA won't work in text mode browsers (I think?). If we're transpiling javascript we'll be able to support old browsers.

* What is defined "good UX"? What is considered the main use-case of the registry?

One way to define good user experience is that the site is as accessible as possible to the diverse Javascript ecosystem. Like, it should definitely be accessible by screen readers. It should be easy for newcomers to learn what it is and isn't. Likewise, it should be an effective site for more experienced users.

  It's important to ask, because depending on the answer SSR or SPA can be the better user experience (imho). I don't mind that an mail application client takes a while to load in the browser, because I might "live" in it for a while, once it's loaded. I do mind slow loading speeds when browsing content (let's say Medium). So it's important to understand where entropic would fall onto this spectrum.

* Is DX valued more or less, compared to UX? And how bad/good are both sides?

* What is more valuable when thinking about server-side (cost) vs client-side time (perf)?

All of this is just my five cents. 😸 Whatever we build should be maintainable for the future and as accessible as possible for screen readers, for newcomers and for experienced users. And we also need to consider localization. 💭

from entropic.

While they do rely on JS, SPAs also make quickly implementing and iterating on things like i18n and a11y much easier.

Thats not a given. That all boils down to how a project is structured and I sure have encountered SPAs which is close to impossible to develop on due to its complexity and poor structure.

SSR templating => easier maintainability, worse user experience
SPA => tougher maintainability, better user experience

These are not given facts either. There are tons of SPAs out there with horrible UX.

I would start out with a very basic SSR template based site and enrich with client side scripting for enhanced features and go from there. I would also add a service worker to cache all html which are fairly static and assets to reudce amount of hits to the server for these.

On a bit longer term I would honestly like to see usage of web components for the different features. It would be very nice if one where able to make ex search a reusable web component one used on the web site here but which also others could use to plug into their Vue, React, Svelte, etc app. From a project like this I would very much like to see reusable components which can be plugged into different frontend frameworks rather than going all in on Vue or React component.

from entropic.

I'm quite a fan of SPA so I'd naturally lean towards making one, but I really see two issues with what @chrisdickinson described if we were to use one: The maintainability for people setting up their own instance and the "private" API part that only the server code should be allowed to access, even though I don't think the latter should be too much of a problem. But again, the big pro of SPA is minimising the amount of work the server has to do by almost limiting it to API calls with the consequence of potentially breaking non-Javascript browsers. I think that starting to plan how we want the website to work now is a good approach, since being offered the choice of either tough maintenance or almost completely rewriting the website isn't that great.

from entropic.

@superhawk610

I think it's a difficult transition both ways since any client-side stuff you've written in a non-React/Vue/Angular environment isn't really transferable to an environment with a framework and vice versa.

Yes, you are right! It wouldn't be an easy task at all either. I was imagining this transition in a relatively early state (and in case of needing it).

I guess I'm moving my vote from a dedicated SPA to a server-rendered SPA, ala Next or Gatsby. Best of both worlds

Looks to me as a very feasible option as well! :)

from entropic.

Hi! Very definitely biased toward Gatsby here, but I wanted to put a few benefits on the table that I haven't seen called out:

1. The UX of Gatsby sites is set up to be stellar out of the box. New sites start with perfect scores on Lighthouse, etc., plus we do things like prefetching routes on JS-enabled pages (we skip this when data-saver is on or a slow connection is detected). This should cut down on yak shaving for deployment/QA since most of the current perf best practices are baked in, and new improvements will be handled upstream.
2. There's very little boilerplate to get started, which should help with getting contributors into working on the site vs. figuring out how to set up a dev environment.
3. If you choose MDX, the content editing experience doesn't need to require React or GraphQL knowledge for a significant number of common workflows, which should significantly decrease the barrier to entry for e.g. docs contributions.

If you're interested in exploring how Gatsby could work, I'm happy to help out!

from entropic.

/cc @marcysutton since some keywords that might interest you came up 😄 (a11y, gatsbyjs)

from entropic.

I think @wardpeet is right about coding guidelines, having to create them looks like a pain since you got to be going for something that isn't hard to comprehend, since having the project's "development community" understanding it alone contradicts the idea of "Any user should be able to try and fix it". The advantage of using a framework is that there's generally a solid documentation already and also the people using Entropic might already know those frameworks; Therefore, making the thing from scratch wouldn't reduce the learning curve of people getting to know the project imho.

from entropic.

There is no reason I could fathom why we would choose CSR over SSR, though always happy to be corrected 😊

from entropic.

I'm aligned with @zacanger. The main thing for me is making sure we choose something that doesn't make it hard for search engines (there are more search engines than google) to find and index the content. Both Next.js and Gatsby seem to do fine in that aspect.

from entropic.

@maxnordlund Totally understandable and I don't mean to pick on you or anything. I just tapped that part of your remark because I wanted to express how... patchy and unexpectable my knowledge of JavaScript is, as a newcomer. I could start writing (very basic) function components within the hour of being shown them because JSX is awesome and easy to read, and honestly so are template literals. They're both ES6. I know naught else, and the abyss of pre-2016 JS, with its mysterious $ and % signs everywhere, is closed to me. 🙈

from entropic.

I mentioned a concern with Gatsby earlier that was never addressed that I think may make Next superior - while Gatsby and Next both tout "server-rendered by default", they have pretty different models (someone please correct me if I'm wrong); Next spins up a Node server and renders each request on demand, while Gatsby generates all possible routes ahead of time as HTML files, essentially sacrificing disk space for response time.

While I really like Gatsby's approach, this means prerendering static HTML for each version of each package every time any package's info changes (again, someone correct me if this isn't the case). I know there's some active work now on incremental builds, so this may change, but at present this is the case.

Additionally, any data used to render a route is also stored in the static build directory, essentially doubling the disk footprint.

Next's model is a bit slower per-response but I think it's the only real option at this (potential) scale.

from entropic.

There must be a way to fallback to SSR if the client can't run JS, isn't there?

vercel/next.js#575 Answer: yes. Next.js correctly provides for the dynamic in question. Of course it does. It feels so obvious reading the code! https://github.com/zeit/next.js/blob/master/packages/next/client/link.js

If the client is running JS, preventDefault kicks in and the request is completed to the API instead, else (or on initial load) it is a "miss" that goes to hit the rendering server. Then the rendering server peels data off the API instead, renders the page, and throws it at the client.

from entropic.

I'd like to highlight a concern regarding the use of SPAs, and query those involved with this thread about it, specifically regarding React-based SPAs. I mean no disrespect at all to Gatsby or Next.js and their teams, but those platforms are based off of a framework controlled by a single corporate entity that gives permission to the community to use it.

As the spirit of Entropy is to specifically move away from a centralized company holding the majority of the cards, are we okay with the front-end going in the opposite direction? I don't mean to be pedantic or overly thematic here, but to my understanding, if Facebook drops React, with that move would go the majority of its technical development and support.

We do have other framework options that aren't centrally backed if we were to work on a SPA. I'd like to suggest Vue-based tools myself, as there are direct correlations to Gatsby and Next.js in Gridsome and Nuxt.js respectively. I grant that Gridsome may be a little too green for a project of this magnitude, but are we willing to consider Vue-based frameworks for the task?

from entropic.

If Facebook is going to closed source React, I'm 100% convinced there will be a hard fork and it will continue on as open-source. The community is just too big atm to stop progress instantly, when such event would occur.

Nevertheless, I think it would be unwise to not have an open mind about other frameworks, which solves similar problems. Personally I don't have any strong opinions about the frameworks, just about them solving the problems for entropic.
I guess an "extra" wink to getting rid of the "corporation" could be an argument to use Vue as it's (not yet) "owned" by one. If we take the road for Vue I would suggest Nuxt, seems similar to Nextjs.

Edit: Nicer wording

from entropic.

Done. Discourse discussion here.

from entropic.

phew, that's a long thread of framework debate.

just start with nunjuck, and vanilla js, css.

and add react later.

from entropic.

NPM does use an SPA

npm uses a SPA but it’s barely necessary and was more of a way for us to dog food common ways for our users to build a web application. (Also the entire site is SSR + rehydrated front end)

from entropic.

I agree with @trodrigues' approach. I think using SPA at this point is overkill. SPA is not a good solution for all use cases.

If we barely know the features we will need, why should the project be locked to SPA? This is anticipating the future and we are in a very early state.

SPA's are a great solution for high interactive web apps (like dashboards, for example). But SPA's are terrible for some very basic web features. For example, forget about decent indexing and SEO on SPA, compared to plain HTML or SSR.

Also, as @nilsnh suggests, do we want the website to be accesible for everyone or only for last-generation browsers? SPA's rely totally on JS which can easily end up with performance issues (so more complexity to deal with).

@chrisdickinson +1 to Tachyons!

from entropic.

@alexgarces I agree.
I'm a fan of SPA's, but that's because I mostly work on dashboards and I think that's an amazing case for SPA's, since there is a lot of user interaction.

If we really don't know the amount of features yet, I'd also opt for @trodrigues' approach. Start small, introduce more complexity when the benefits outweighs the trade-offs.

from entropic.

premature optimization is the root of all evil
Donald Knuth

Starting simple and grow slowly in complexity is the way to go for maintainability. The more frameworks/libraries you add the higher the bar of entry, as in order to contribute you need to learn more and more things.

I've done my fair share of frontend and backend, but it has been mostly backend the last couple of years. So I don't feel comfortable in React (or Vue), and if this project would use that I wouldn't want to contribute. On the other hand, I've written a lot of Postgres stuff over the years, which may come useful.

So, my two cents is to keep it as simple as possible, use the least amount of dependencies and for those that are needed chose the ones that are the easiest to learn. Nunjucks is decently simple to pick up, as long as you stay away from macros/call (and custom filter/functions).

from entropic.

Would love to help out with the website as well. I am too on team "basic HTML and CSS" like @varjmes and @trodrigues, but wouldn't mind having a Gatsby implementation either (@jlengstorf u pretty much sold me on it 😛). Either way, I would never pass up a chance to write some CSS no matter what form it takes ¯\_(ツ)_/¯

from entropic.

I'm team vanilla with @varjmes and @trodrigues , but whatever you choose to go with @chrisdickinson , feel free to tag me for some frontend issues (I'm one of those people who loves to work with CSS). Looking forward to hopefully contributing to this great thing!

from entropic.

You can do SEO with SPA, as long as you're SSRing. Add to that, Googlebots are about to or have already become ES6 capable and evergreen.

from entropic.

@venikx I agree that the SPA model is a bit at odds with the intended use of a package registry, but I still think the pros of a client-side JS framework (as far as design implementation/iteration) still justify it.

I may be biased from hanging around React Twitter too much but I think you're more approachable to devs when using a frontend framework than a templating language since it's much more declarative/abstracted.

from entropic.

@varjmes right, but client data fetching and SSR are mutually exclusive, anything you do client-side won't be there for search engine crawlers and thus kinda defeats the purpose, right?

from entropic.

Speaking to the Next team yesterday, they will be coming out with a feature that lets you decide which pages are SSR or CSR. You can also do CSR and no SSR already, apparently. But now I feel like I'm (not saying anyone else is) bikeshedding :)

the human tendency to devote a great deal of time to unimportant details while crucial matters go unattended

from entropic.

I know this thread is long but have we thought about svelte yet?

I like that it “gets out of the way” and the latest version is real nice...

from entropic.

I like Vue, but React or React-alikes would likely be more familiar to newcomers.

Let's go look at the number of Github stars on all of the projects under consideration. You're going to seriously argue that Vue isn't accessible enough? Arguing that Vue is somehow harder to pickup than React is an equally dubious assertion. There's probably a reason Vue ended up with more Github stars than React, in less time, and with millions of dollars less in marketing. That reason isn't that it provides a worse developer experience.

from entropic.

@zacanger I apologize for the snark.

Stack Overflow Developer survery 2019

I'll grant you that React is most loved by people that use it, and most desired by FEDs to add to their skillset, but Vue is second in both categories. After all of the different approaches that had been entertained here and given a fair shake, I guess I just felt Vue deserved better than a hand wave.

from entropic.

I feel like this discussion is jumping ahead of ourselves. We need a stable API first and then figure out how sessions will work on the site. As of #135 there are no JWT's for authentication so we will need to authorize access on the server for now.

Injecting React, Vue etc. for better interaction in the future ( I think ) would be a more pragmatic approach and put less pressure on having an API that is unchanging. Search engine indexing is also of concern.

Perhaps we can chat about a server side templating language / CSS framework as a next step after #135 merges?

Addendum:

Just some considerations from the requirements that @chrisdickinson posted:

Markdown is pre-rendered on publish. It is stored at rest as HTML suitable for inlining. (Storage is cheaper than CPU cycles.)

Injecting this and rendering after page load doesn't sound ideal. Sending this along from the server after retrieved from the database sounds more performant and better for search engine crawlers.

We want i18n support. My experience with rich client apps has been that you end up having to generate multiple different asset bundles for each target locale (or else do some kind of code-splitting.)

The website should look to what comes of #115.

from entropic.

@olingern I think starting a thread over there would be good!

from entropic.

@superhawk610 absolutely agree. SPAs may sound complex, but for me, they aren't and definitely worth all the features, pluses, minuses, and optimizations that they give - not only DX is bumped to the skies but also the UX.

Just to throw it here: Bet all-in on Gatsby, except maybe for the "internal" one which makes sense to be Next.js

from entropic.

Don't know if you'd want to lean on or trust Google to keep the service up, but firebase offers a nice way to add Github OAuth to your site without needing to create url routes.

This is my typical setup for it:

// helpers/firebase.js
import * as firebase from 'firebase/app'

import 'firebase/auth'
import 'firebase/firestore'

import config from '../config/firebase'

const provider = new firebase.auth.GoogleAuthProvider()

const app = !firebase.apps.length
  ? firebase.initializeApp(config)
  : firebase.app()

const db = firebase.firestore()

export { app, provider, db }

// pages/index.js

import { app } from '../helpers/firebase'
import { useAuthState } from 'react-firebase-hooks/auth'

const Page = () => {
  const [user, initialising, error] = useAuthState(app.auth())

  return (
    <Layout>
      <NavWithGithubAuthButton user={user} />
      {user ? <p>Signed In!</p> : <p>Not!</p>}
    </Layout>
  )
}

export default Page

from entropic.

Hi @chrisdickinson i would love to work on this part and contribute to the project !
And i most definetly agree with @superhawk610 !

from entropic.

I don't think it needs to be a debate of ssr vs csr. Rather think about maintenance and community. When I said gatsby, I still think it's a good approach as it can handle CSR and prebuild ssr. We also focus on a11y and speed. The downside is that people need to "learn" react & graphql.

you'll have to think about:

The hierarchy of values for the website are: we want the server to be easy to set up and maintain, easy to use, and easy to develop, in that order.

By "maintain", I mean: imagine someone outside the JS community being asked to set up an Entropic instance, or to fix an Entropic that's throwing errors.
Entropic instances may live inside your network, so network latency concerns are a bit different than the average website.

from entropic.

Thank you for enumerating the requirements @chrisdickinson. :)

The downside is that people need to "learn" react & graphql.

I agree on your main points @wardpeet. :) I just want to note that even React and GraphQL will provide some barriers to entry, especially if we add their conventions of usage on top of that. React or GraphQL could definitely be the right tools here, but people will have to learn them, not "learn".

So, should we try to arrive at some common consensus, or create some minimal Proof of Concept stacks and argue for them? 🤷‍♀

from entropic.

@lacaulac I'm also a big fan of SPA's! The developer experience when working with React and similar technologies is awesome. But being part myself of a failed SPA project some months ago made me much more critical about the SPA hype. Since then, I try to be more practical and minimalistic. And the only use cases I find for SPA's are dashboards and high interactive apps.

@chrisdickinson thanks for listing the requirements!

By "maintain", I mean: imagine someone outside the JS community being asked to set up an Entropic instance, or to fix an Entropic that's throwing errors.

This is a key reason to avoid using a big framework for now.

Markdown is pre-rendered on publish. It is stored at rest as HTML suitable for inlining. (Storage is cheaper than CPU cycles.)

I'm going to contradict myself but, after reading this requirement, I would also consider Next.js. I've worked with Next.js and it is great for this particular use case. You can switch between SSR and CSR, and export it as a static site. The downside about using it, again: you are locked to the complexity of React from the beginning.

@superhawk610

SPA and SSR are not mutually exclusive. The only functionality exclusively available to an SSR is page-specific tags, and this can still be very easily accomplished by spinning up a very minimal SSR renderer (either using an existing solution like Gatsby/Next or even a simple Express server) to inject the relevant SEO info into the index.html before serving - this approach has the advantage of minimizing server-side work while still allowing for the richer UX of an SPA.

You are totally right, SPA and SSR are not mutually exlusive. But why adding the complexity of SPA before you need it?

SEO is not only about meta tags. Content is the most important thing for SEO. And client side rendered content via JS is very very far from having a decent indexing.

@trygve-lie

These are not given facts either. There are tons of SPAs out there with horrible UX. I would start out with a very basic SSR template based site and enrich with client side scripting for enhanced features and go from there. I would also add a service worker to cache all html which are fairly static and assets to reudce amount of hits to the server for these.

Totally agree with this approach. It is so easy to quickly end up with a bloated front-end when working with SPAs. Also, it is much more easier to go from simple SSR templates to something more complex than viceversa.

from entropic.

@superhawk610 I don't know a lot about Server rendered SPAs but that seems to be a good solution.

from entropic.

Someone mentioned the need for regexp validation. You can actually do that in pure HTML nonwdays

Only allow lower case alpanumerical characters:
<input type="text" pattern="[a-z0-9]+" />

You can get a lot done with a sprinkle of JS:

<div>
<button type="button" class="copy">Copy to clipboard</button>
<input type="text" value="This will be compied" />
</div>

Array.prototype.forEach.call(document.querySelectorAll("button.copy"), function setupClickHandler(button) {
  button.addEventListener("click", copyToClipboard)
})

function copyToClipboard(event) {
  event.preventDefault()

  const input = event.target.nextElementSibling
  input.focus()
  input.setSelectionRange(0, input.value.length)
  document.execCommand("copy")
}

from entropic.

@jlengstorf from a bit of tinkering around, my initial concern is disk space. If I understand it correctly, you'll essentially end up with 3 copies of the entire dataset on disk at any given time:

• database set used by other entropic services required when generating routes at build time
• dataset spread between HTML files in prerendered build output
• dataset for data fetching in static directory in build output

We could store the actual package tarballs in a single location, but whatever package meta info (name, version, HTML rendering of description) would always exist in triplicate, right?

from entropic.

the people using Entropic might already know those frameworks

This is why I would like to avoid frameworks and stay as vanilla as possible. In order to cast the widest net you need to have the lowest bar of entry, right?

It's true that you need to learn a templating language, and choosing the easiest one is hard. After briefly searching for JS templating languages I think ejs is the simplest, followed by underscore.

export default function render({ title, body }) {
 return `
<html>
  <head><title>${ title }</title>
  <body>${ text }</body>
</html>
`
}

from entropic.

So, now that we're settled on using a known framework, the question is choosing between doing SSR or CSR and whether or not to use an SPA.

from entropic.

@superhawk610 I think one of the reasons why @varjmes mentioned Next.js is that you have DX from writing React on the server-side (so no templating). However, since you potentially can share some of the code with the client, you can decide to move parts of the logic which happened on the server the first time to the client and that part of the code would act like a regular client-side from then on.

Correct me if I'm wrong (never used Next.js).

from entropic.

Well, it's about how much we want to separate the display stuff from the "computed" stuff. I usually go with REST + CSR SPA so that I can really have a clean separation between the client and server.
@venikx That sounds pretty logical to me.

from entropic.

Not at all, @superhawk610. You would not need to generate a file for every package for every thing ever with Gatsby.

Because a Gatsby site hydrates into a React app after loading statically, Gatsby is not just for static sites. You can fetch data dynamically on the client, as needed, as you would with any other React app.

https://www.gatsbyjs.org/docs/client-data-fetching/

from entropic.

There must be a way to fallback to SSR if the client can't run JS, isn't there?

from entropic.

I agree with @superhawk610 about Next.js over Gatsby. Some things can be solved via static pages (documentation for example), but package pages have to be rendered dynamically on demand. I also find Next.js much more simple. It's just like React, but with an extra method for SSR (getInitialProps).

from entropic.

@Vickers if you could please tone down the aggressive attitude that would be fantastic. This is a place for friendly civilized chat, even if its about passionate topics like web frameworks. :)

from entropic.

I am with Vue, what i really like in Vue and don't see in React is the code architecture

What about making a poll ?

from entropic.

@avickers please don't misunderstand, I'm not saying I dislike Vue or think it's hard to learn. Vue is great, I really like Vue, and in some ways I think it's actually easier to pick up than React (especially the less fragmented ecosystem). It's just less widespread than React, at least for now (based on package download counts, Wappalyzer/BuiltWith stats, and GitHub's "Used By" count, not stars). That means that a new contributor to this project would probably be more likely to already be familiar with React than with Vue.

from entropic.

Both "Used By" and "Stars" are a bad metric to check the adoption rate and shouldn't really be used for the sake of arguments (imho). Both metrics have flaws. Stars displays "people like it" and used by only display adoption rate on Github (I believe?). Vue is big in Asia and I'm not sure how popular Github use is there.

Even if we decide to go with the Vue route, the fact it's supposed to be easier to pick up for beginners is an argument on it's own. React, Ember, Angular, whatever devs are able to pick it up fast and "new" frontend developers might have an easier time contributing (since it's supposed to be more approachable).

Can you do Github polls?

from entropic.

Can you do Github polls?

Any comment can be a poll. Just use the up/down vote emojis.

from entropic.

There's also this https://app.gh-polls.com/ for more complex polls

from entropic.

I disagree foundationally with this poll.

1. FPtP is intolerable because it seeks to choose a winner who can acquire the most first-choice votes, not necessarily the most tolerable compromise, which makes it ideal for irritating people (just ask Americans, hey?). Which of course this poll defaults to. Informational video on more regarding this: https://www.youtube.com/watch?v=s7tWHJfhiyo
2. Relatedly, this poll has been loaded with many similar choices, necessarily distributing votes awkwardly amongst them. But also see point 8.
3. Many of the questions that have led to discussing Gatsby vs Next vs Preact vs yes even Vue are merely economic, as they involve tradeoffs of HD size vs CPU, and while many things have pointed at a future involving 100 more copies of entropic being hosted, the people footing the first bill right now for https://entropic.dev/ are @chrisdickinson and @ceejbot afaict. The reality of their hosting plans will logically have as much of a vote, if not more than anything, right now, and those are mere calculations that will not bend to the will of democracy.
4. Further, the reality of the economics of hosting plans is something I believe the initial 2 founders of this project have thought about more than me, so I would prefer to hear their reasoning about this before anything else, even if they were not ALSO footing the bill for entropic.dev
5. Again, it's going to be a site they are hosting, so if the poll says one way and they say another (for whatever reason), this has been a sham poll. If we pressure them to accept regardless, it has been a double sham, for it has been a poll that has betrayed our intent to help them. And we can now no longer know what they would've said in the absence of the poll because we pushed on anyways!
6. In addition, there have been arguments regarding "vision" and library compatibility with that, and I would like to hear what they have to say about how much anything indeed has to do with this, because all I had when I came here was the 30 minute talk and noticing some interesting patterns about npm usage.
7. Related to that, it's worth considering that Node went from an open software project to being sponsored by Joyent to being sponsored by the Node Foundation (which is apparently, in 2019, merging to make the OpenJS foundation? huh).
8. Part of why I said I'm in favor of more complete rendering libraries generally is because the differences between React and Vue are really an ocean of breadth smaller than their similarities.
9. Maybe we should chill and settle down in light of #160

from entropic.

I somewhat agree, but right now there's a small but slowly growing bit of server-side rendered content already in the form of template strings

@zacanger Totally agree. The template strings aren't ideal and I wanted to suggest using a template engine. A few suggestions:

• https://github.com/mozilla/nunjucks
  • Mozilla project, still being maintained
• https://github.com/olado/doT
  • No deps, but last commit 2017
• https://github.com/pugjs/pug
  • Defacto templating language, good docs, battle tested

RE S3 storage:

That's a hard problem. It would be neat if we could push to S3 and serve as a static site and then iframe the package HTML via the packages s3 static site URL. This would push the loading off to the user's browser and S3 at the expense of an additional network request. I'll admit maybe not practical.

Perhaps it's worth opening a thread on discourse to chat pros / cons of storing HTML vs doing it at runtime?

from entropic.

Amazon S3 + Amazon CloudFront

from entropic.

@workingjubilee
1: True, but that’s not the intention of the vote, it’s by no way binding. It’s just to get a feel of what people here are thinking, because we all have so many opinions it’s hard to see a summary.
2: I just put in the options I read on this thread. You can vote on multiple options either way.
3: See 1
4: See 1
5: Again, see 1
6: I don’t see what this has to do with the poll?
7: See 6
8: See 6
9: Disagree, I don’t think we should stop discussions, because one of the core members is on holiday.

If it wasn’t clear enough: My intention of the poll was not to set something in stone, but to get an idea of what people think of doing right with the information we got about the requirements. It’s by no means binding, especially since there is not clear “winner”.

@olingern
If it comes down templating language, I would fine with a mature one, which is actively maintained. No preference there, since I don’t have experience with templating language, but that’s fine.

I disagree with the point the discussion is getting ahead of itself, since that was the part of why the issue was opened: templating language VS something like Nextjs.

from entropic.

Seeing the discussions about how dirt cheap storage is, I’m thinking maybe gatsby would be a super viable approach. I kinda brushed of gatsby, because I was thinking it would cost a lot due to amount routes we would need for all the packages.

But if storage scales better than cpu cycles, Gatsby becomes actually a super viable option + if anyone wants to run their own it’s straightfoward since it’s “just html”. Accessible, straightforward and a friendly community ready to help as seen in: #107 (comment)

I’m unsure how two things work with gatsby though:

• Authorizarion
• Publish to registry would require redeploy of the FE if I’m not mistaken

from entropic.

Gatsby doesn't yet support incremental builds. Sounds like they think they are getting close.

Obviously rebuilding 800k pages with every publish would be the most expensive approach in terms of CPU. Maybe there is some clever way to break it up, like every namespace getting its own Gatbsy instance, that would mitigate this problem?

from entropic.

every namespace getting its own Gatbsy instance

That actually would work, the only difficulty there would be dynamically creating instances on namespace creation. Tbh I think incremental builds would essentially do this.

I still really want Gatsby to work since it will only require a rebuild on package creation/update, while Next will rerender each page every time it’s requested, but until they support incremental I don’t think it’s really viable.

I wonder if there’s some happy medium we could hit using Next - have an Express server running to serve the app, but whenever a route is first requested, render it and cache the HTML to disk and then just serve that on subsequent requests? Then any time a package is updated, we just delete the cached copy as part of the update process and it will be regenerated on the next request. For efficiency, we could even perform the render/cache on package deploy/update, effectively having our own Gatsby-esque solution. Thoughts?

To address @venikx other question, Gatsby apps are just basic React SPAs once they’re rehydrated so you can use any existing auth solution however you normally would (request a token from the backend and then store it locally and use it to authenticate outgoing requests).

from entropic.

For your tech stack, I would certainly argue in favour for Vue JS with its SSR partner Nuxt JS.

It’s inspired by React’s use in Next, yet much simpler to get running with, easy HTML templating and CSS setup. I believe it to be a much more accessible setup that would welcome new contributors warmly.

In the spirit of this project, Vue (unlike React or Angular) is NOT back by a large company (Facebook and Google respectively). It was started by one person but is now a truly open source, community-led framework.

Lastly, if you wish to go with a CSS class based utility library I would recommend Tailwind over Tachyons.

That’s just my thoughts.

from entropic.

Keep it simple ... don't reinvent the wheel, and don't try and reach perfection on your first build.
Who really cares if its in Angular, React, Vue, or even Aurelia or Knockout or Jquery. I'd just say concentrate on being able to quickly refine based on your user behaviours is key at the start. Lets be honest an SPA feels slicker, but when your starting, just doing the simplest route to get something up is far better than creating some ultra complex Angular monster say.

Personally I'd build a simple prototype, throw up a super simple knockout.js based view model as it involves no build steps, I'd add in something like wasabi on a docker image to run AB tests and set up a load of goals, like completes a sign up form, links to the git hub repo. And start testing the users.

I'd add redirect functionality to attach tracking codes off URLs to segment the users and see where they are coming from to start measuring what is driving traffic, ie ads, talks, articles, social media etc.

If your doing a simple content only sire, then there are some decent headless cms systems like Crafter cms, or craft cms that take a few minutes to get up and running and then you get no major config or environment headaches.

Then build out from there, refine, refactor and renew

from entropic.

from entropic.

@Vickers we cannot remove you from this list -- you'll need to either use the mute thread link at the bottom of the email, or view the thread on github and click the unsubscribe button.

Sorry :(

from entropic.