roughcoder

https://archive.ph/20221120120719/https://www.reuters.com/bu...

agreed no default is mentioned but you can declare with `await chromeless.viewport(1024, 800)`

Can not recommend www.datadoghq.com enough, cheep and a load of integrations.

This could be debated, atomic components within a framework built for a purpose can still be responsive.

Responsive or adaptive should be choice made at the start of projects and then ideally followed through till the end.

We choose responsive and made atomic components so it can work, but... it has to be in the thought process from design to implementation, the same can be said about adaptive.

Source: Our UI is complex, large, responsive and serves 3 million users and won awards.

If you support ES6/ES7 in your build cycle then we are big fans of the spread operator which can be used instead of _.default, Object.assign. For example:

    case 'CHANGE_LOCATION':
      return {
         ...state,
         location: action.location
      }

For a simple app your code works fine. You will have trouble when it scales.

We have migrated a load of model logic from Angular to redux and redux saga, once you get your head around a nice structure then its a dream.

I created a gist for you to check out [1]. Maybe also check out the concept of Redux Ducks [2]. I now find our code easy to read, share and test - unlike our massive Angular app.

Also as somebody else comments, you should make sure the only way you talk to your store is through a reducer dispatcher.

Regarding component states, find some reading on components v containers [3] - we even have 2 separate folders for the different types. Once mastered and implemented, most components are small and again easy to test.

[1] https://gist.github.com/anonymous/a20f603f9922742bd3cea7a08c...

[2] https://github.com/erikras/ducks-modular-redux

[3] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

I rarely comment for the amount of hours spent parusing HN but this is one to many shoddy node bashes.

I take a pragmateic approach to this (maybe its cause im now predominantly a JS developer).

It does feel like every man and his dog want to build a website and putting together some resemblance of a webpage with HTML, CSS and JS (and maybe a one click install) is not actually a steep learning curve for the majority.

From experience of interviewing I know this is the start of a lot of Front End/Node Developer careers, this is cool, but i think it also mean the quality of JS developer is across a spectrum is more weighted to lower side, most having none or very little knowledge of patterns or "production" level coding. Because of these the JS world is full or gists, blog articles and NPM packages at a similar lower level of quality. Something very easy to bash.

I also feel there are developers from other languages that try Node and fall into patterns that rubbish articles say, panic cause it wrong and bash publicly Node.

For example....

- Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today.

Yes, as cool as it is that you can pass a function (with context) around between another function for hours, some people sadly use it wrong. Promises, Async, Generators, Redux Saga all solve these issues.

- Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript.

Yep, I been using JS in many forms, including coffeescript for 15 years, it lacks static typing, you either love it or hate - its not a hindrance. I love using ES7 over coffeescript now.

- NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline.

Yep this public package manager has some rubbish in it and yep people "could" screw you over with package versions.

Putting the correct version numbers in your package.json and having your own NPM repo like Nexus get rid of these issues.

- The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck.

I can say, after doing this for 17 years - I love Webpack.(Finally my folder structure of a website is poetry, and my CSS has all the right browser prefixes when required). Tools like webpack, gulp and grunt help with this. Yep it can go crazy, but for me it really does not take that long to setup tooling to the exact what i want.

- A community with the attention span of a goldfish

Yeah probably, but can not actually see why this effects me.

- Scaling is a pain in the ass.

What?

- I've found that most people who think Node.js is a good platform lack experience.

I have 17 year experience from Perl, Python, C#,Java, ASP, Ruby, PHP and more. I have worked for one of the big tech companies. I dont lack experience, Node JS comments like yours do though.

- If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning literally anything other than Node.js. For a HTTP server, try Python+Flask, Ruby+Sinatra, Go+Gorilla,Gin,Goji,etc., Scala+Akka-HTTP, Java+Dropwizard, C#+Nancy, C+libonion, ...

If any good programmer does not choose the right tools for a job then your not good. Node does not solve everything.

I have had a Sinclair, Amstrad and Pi 1 - in fact I had my first experience of programming on my Sinclair when I was 8 years old. Now make a living out of it. Will be getting a Pi 3 and finally get around to making my connected house.

Link to blog post https://blogs.windows.com/windowsexperience/2016/01/04/windo...

Link to TJ blog post on nodejs.org http://blog.nodejs.org/2015/05/08/next-chapter/

If it was not for the need to have a fallback for IE9 I would be using flexbox as standard, its a great feature with deals with so many of the common page layout issues, including vertical align.

Bootstrap is quite web focused still so I guess it will come when support for IE9 is not expected.

Though if you are doing an mobile/tablet only solution I would probably use flexbox only now. As long as you keep to the 2012 spec, you should be ok.

http://caniuse.com/#feat=flexbox

Bring on the death of IE9!!

Its bigger then li's it about an overall approach. In this use case, yes maybe its an overkill but in some cases its not and allows for quite a bit of flexibility to use the same styles across multiple element types.

I guess it's come about from trying to be more semantic within the documents.

Declaring Headings with classes is a good example as well.

    h1,
    .h1{
       font-size:20px;
    }

    h2,
    .h2{
       font-size:18px;
    }    

Another few other common ones are

    strong,
    .strong{
        font-weight:600;
    }

    small,
    .small{
        text-size:10px;
    }

It also does not really go against inheritance, themes like .collection-alt can still work.

Sometimes its an overkill and I don't always do it, but in some cases (heavily responsive sites) it has worked really well. Its also easier to work in a team with one approach, rather then just doing it for headings etc why not take the principle/standard across all styles.

It used to be the case and I think still is for a large case of mobile/tablet devices to just set font size on inputs to 16px.

I think with ios 8 this has changed.

How come with hear little or nothing about Apple having such a closed and restricted environment for iPhone. For example with payments having to go through them?